Can an AI Agent Use Your Product, or Only Read About It?

TL;DR

Being readable by an agent and being usable by one are separate projects, and most teams have only done the first. Readable means an assistant can fetch, parse, quote and attribute you. Usable means it can authenticate as a specific user, call a tool, change state, and be refused when it should be. The second is mostly an authorization, identity and error-semantics problem rather than a model problem, and it is paced by how precisely you can say no, because a readability bug costs a citation while an authorization bug costs an incident. A usable tool surface needs five things: delegated identity that expresses which agent acts for which user in which scope, authorization enforced at the data layer rather than in the prompt, idempotency keys because agents retry on timeouts they misread, error messages that name the failing field so a model corrects instead of looping, and discovery through MCP and published agent skills. MCP is the transport and not the authorization model; treating it as one is the common mistake. A defensible sequence is read-only tools, then a published map, then one low-risk write behind human approval, then widening only where the audit log shows consistently correct behaviour. Nobody can currently quantify revenue arriving through agents, so the case for the early steps rests on them being cheap and useful to human integrations regardless.

Being readable by an agent and being usable by one are different projects, and almost every team has only done the first. Readable means an assistant can summarise and cite you. Usable means it can complete a task on your product on behalf of a named user, and be stopped when it should be.

The second one is mostly not a model problem. It is an authorization, identity and error-semantics problem, which is why it lands with engineering rather than marketing.

Want an agent to complete a real task against your product, with boundaries that hold?

Talk through the surface

Two different questions

	Readable	Usable
What the agent does	Fetches, parses, quotes, attributes	Authenticates, calls, changes state, reports back
Surface	HTML, Markdown mirror, llms.txt, JSON-LD	Tools with schemas, identity, permissions, audit
Failure	You are absent from the answer	Something happens that should not have
Cost of getting it wrong	Lost attention	Lost data, money or trust

That last row is the reason the second column takes longer. A readability bug costs you a citation. An authorization bug costs you an incident, so the work is paced by how confidently you can say no.

If the first column is not done yet, start there. Our guide to agent-readable websites covers it, and it is a fraction of the effort.

What "usable" actually requires

A tool surface an agent can operate needs five things, and the interesting ones are not the API.

Identity that is not the agent's. The agent acts for a user or a tenant. If your tokens cannot express "this agent, on behalf of this person, for this scope, until this time", every call is effectively an admin call.
Authorization at the data layer. Filtering in the prompt is not access control. The boundary belongs where the query runs, so a persuasive instruction cannot widen it.
Idempotency. Agents retry. They retry on timeouts they misread, and on partial responses they did not understand. Any state-changing call needs a key that makes the second attempt a no-op.
Error semantics a model can act on. A 400 that says "invalid request" produces a retry loop. One that says which field failed and what shape it wanted produces a corrected call. This is documentation as a control surface.
Discovery. Something has to tell the agent the tools exist, what they cost, and what they are for. That is what MCP and published agent skills do.

Where MCP fits, and where it does not

MCP gives you a standard way to expose tools and resources to a model, and it is the right transport. It is not an authorization model, and treating it as one is the most common mistake in this area. The protocol carries your decisions; it does not make them.

The design questions underneath it are the familiar ones. Which tenant is this call for. Which of that tenant's records may this scope see. Who approves a write. What gets logged so an incident can be reconstructed. We have written both halves up in detail: enterprise MCP authorization architecture for the multi-tenant reference design, and MCP security boundaries for why data-level enforcement is the only enforcement that holds.

Agent skills sit above the tools as the instruction layer: when to use which tool, what the house rules are, what never to do. Tools without skills get used wrongly; skills without tools are advice. We publish ours as static files with checksums, so anyone can read what our agents are told.

A staging that does not require faith

You do not need to believe agent traffic will be large to justify the first two steps, because they are cheap and they pay off for humans too.

Read-only tools first. Search, lookup, status. No writes, no approvals to design, and it exercises identity and rate limits under real conditions.
Publish the map. An MCP endpoint plus skills that describe the tools honestly, including what they will refuse.
One write, behind approval. Pick the least dangerous state change, add idempotency keys, and put a human confirmation in front of it. Log everything.
Widen by evidence. Remove the approval gate only for operations where the log shows the agent has been right consistently, and keep the gate everywhere else.

Steps one and two are a few days of work on a well-factored API and they are useful immediately, because the same schemas and error messages make your own integrations easier. Step three is where the real design work is.

The honest part

Nobody can tell you today how much revenue arrives through agents. Anyone quoting you a figure is guessing, and we are not going to guess for you.

What is defensible is the shape of the bet. The read-only surface is cheap, the standards are converging, and the work is not wasted if agent traffic stays small, because typed tools, real authorization boundaries and machine-legible errors are things a mature API should have anyway. What we would not do is rebuild a product around a channel that has not proven itself. Start with the part that is useful either way.

Frequently Asked Questions

What is the difference between an agent-readable and an agent-usable product?

Readable means an assistant can fetch, parse, quote and attribute your content. Usable means it can authenticate as a specific user, call a tool, change state and be refused when it should be. The first is a publishing problem, the second is an authorization and identity problem.

Is an MCP server enough to make a product agent-usable?

No. MCP is the transport for exposing tools and resources; it carries your authorization decisions rather than making them. Tenant scoping, data-level permissions, approval for writes and audit logging all have to exist behind it.

Why do agents need idempotency keys?

Because agents retry, including on timeouts they misread and partial responses they did not understand. Without a key that makes the second attempt a no-op, a retry becomes a duplicate order, message or charge.

Can we just expose our existing REST API?

Often, with two changes. Errors need to say which field failed and what was expected, so a model can correct itself instead of looping. And scopes need to express an agent acting on behalf of a user, rather than a single key with everything enabled.

Should agents be allowed to write to production?

Eventually, and narrowly. Start read-only, then put one low-risk write behind human approval with idempotency and full logging, and remove the gate only where the log shows a consistent record of correct behaviour.

Is it too early to invest in this?

For a full rebuild, yes. For read-only tools and published skills, no, because typed tools, real authorization boundaries and machine-legible errors improve your own integrations whether or not agent traffic grows.

Final thoughts

Readable is a publishing problem and it is nearly solved by generating clean copies and letting the right fetchers in. Usable is an engineering problem, and it is gated by how precisely you can say no.

Do the read-only surface because it pays off regardless. Then design the write path around identity, data-level authorization, idempotency and audit, and widen it on evidence rather than on optimism.