GridArray Editorial
When the agent is the user
A framework for teams whose product is a data layer, API, or tool surface, often with almost no UI, because the main user is an agent.
Direct answer
The contract is the product
When an agent is the caller, there is often no screen where a person reviews the result before it spreads. The experience is the contract: which records the tool may return, which action it may take, whose identity it acts under, and what evidence an operator can inspect afterward. A thin UI is not the gap. An ungoverned surface is. Production work starts by naming the real workflow that calls the surface, then making that path trustworthy enough to run. A data layer, API, or set of MCP tools can be the whole product. It still has to carry authority, permission, and an audit trail, or the agent user will treat duplicate records and stale documents as truth.
Framework
What an agent-facing surface has to carry
Use this split when the product is the data layer, the API, or the tools an agent calls. Keep the surface small. A successful tool call is not proof that the underlying records, permissions, or actions are safe.
1. Name the caller
The surface exists for a workflow, not for every possible agent. Write down who calls it, which business process depends on the result, and which failure would hurt that process. A pilot with a real caller can be production work. A protocol demo with no workflow behind it cannot. If you cannot name the caller, you are still exploring, and the contract will sprawl.
- One real caller and workflow are named
- The business dependency is explicit
- Demo-only tools stay off the production surface
2. Narrow the contract
Expose the reads and actions that workflow needs. A data layer that returns every nearby record, or an API that wraps an entire backend, gives the agent more ways to be wrong. Duplicate customers, old Slack exports, and PDFs nobody can search should be excluded or marked non-authoritative before they are returned. Breadth feels helpful in a demo and becomes the incident later.
- Required reads and writes are listed
- Duplicate and stale sources have an authority rule
- Tools that exist only because the backend already exposes them are rejected
3. Identity, permissions, and provenance
The agent user cannot inherit a shared admin credential and remain operable. Bind the call to an identity, limit what that identity can see and do, and attach provenance to every record or action so an operator can open the source. This is the part a human UI would have made visible. The contract has to do that work instead. Permissions that match the whole company, rather than the workflow, turn a useful tool into an uncontrolled reader.
- Identity is explicit for the caller and the tool
- Permissions match the workflow, not the whole estate
- Returned context and completed actions keep a source trail
4. Validation and operations
Validate inputs before irreversible actions. Log who called, what was returned or changed, and why the call was allowed. Add a way to replay or stop a bad path. Evaluation still matters: a fluent tool result drawn from the wrong customer record is a failed run. Operators need that evidence even when there is no product screen for them to watch the agent work.
- Unsafe or incomplete actions are blocked
- Audit logs capture the caller, the action, and the source
- Operators can inspect and contain a bad call
Diagnosis
Symptoms versus root causes
Symptoms
- The product has almost no UI because the user is an agent.
- Agents receive duplicate records or unsearchable documents as if they were truth.
- A shared credential can read or write more than the workflow needs.
Root causes
- Treating a successful tool call as a finished product.
- Exposing existing systems without an authority rule.
- Skipping identity, provenance, and validation because there is no screen to attach them to.
Implementation
How to apply this
Sit with the people who own the surface and the workflow that calls it. List the reads and actions already in production or in the serious pilot. Mark each contract item ready, at risk, or blocked. Engineer the blocked items on that path. Leave estate-wide cleanup and net-new product ideas outside the engagement. The same production system still needs execution, evaluation, and operator control once the contract is explicit.
- Name the workflow that already calls the surface.
- Write the contract for reads, actions, identity, and provenance.
- Reject broad tools and shared credentials.
- Connect the remaining gaps to evaluation and operator control.
Boundaries
Boundaries
- This guide assumes a real workflow already calls the surface, or a serious pilot does.
- It is not a brief for greenfield product ideation or a general application UI.
- Standalone MCP work without a workflow, and broad data cleanup, stay out of scope.