Tool Access Is Not Interaction Agreement

Your agent will tell you it bought a phone. No phone is coming.

Tuesday, 9:40 a.m. Your agent pings you: "Done. I bought the phone. 348,500 forints, arriving tomorrow."

Here is what actually happened. The agent found a phone that met every requirement you gave it. It went through checkout, got the payment authorized, and the charge was captured. Valid payment receipt. Then, milliseconds later, the merchant's order commit failed. Someone else took the last unit. The order was rolled back. A refund will arrive in three to five business days.

Every system behaved correctly. The commerce API served real inventory data. The payment protocol authorized, captured, and receipted exactly the amount you approved, cryptographically bound to that exact cart. The merchant's rollback was clean. There is no bug to file, no protocol violation to report, nobody to be angry at.

And your agent, reasonably, saw a valid payment receipt and reported success.

No phone is coming.

The failure doesn't live in any of the systems. It lives between them, in a layer nobody owns: the one that knows what you meant by "done."

The ladder we keep collapsing

We are wiring agents into everything right now. Commerce, calendars, payments, browsers. The standard move is to expose tools: here are the endpoints, here are the schemas, go. And because the agent can call the tool, we quietly assume a whole stack of things that were never established:

tool discovery
≠ permission
≠ shared understanding of what the operation means
≠ acceptable conditions
≠ verified outcome

Each rung is a separate thing. A tool being discoverable doesn't mean the agent is authorized to use it for this task. Authorization doesn't mean both sides agree on what the operation does. Agreement on mechanics doesn't mean the conditions are acceptable to the person the agent represents. And acceptable conditions don't mean the outcome the system reports is the outcome the user wanted.

We keep collapsing this ladder into its first rung. The phone story is what the collapse looks like at the top: a "verified outcome" that verified the wrong thing.

This is structural, not bad luck

One story proves nothing, so here are two more. Same shape, different rung.

The loyalty failure. You tell your agent: camera quality matters more than brand. The agent searches a merchant catalog and gets back a ranked list. First place: a sponsored model that clears every hard constraint but has a weaker camera than the unsponsored phone in second place, at the same price. The agent, reading rank as relevance, buys it. Nothing in the catalog protocol requires the ranking's commercial incentives to be machine-readable, and nothing carries your private preference order. I checked the current UCP catalog spec before writing this: the only ranking language in it concerns text relevance, and there is no sponsorship field on search results. I've asked the maintainers whether one is planned.

The meaning failure. You said the phone should cost "no more than 350,000 total." The agent writes a 350,000 cap into the payment mandate, which is a correct translation, at the mandate's level. The phone costs 342,000. Mandatory express shipping for your Tuesday deadline adds 6,500. Still under the cap. Then the box turns out not to include a charger, so the agent buys one for 4,990 in a second transaction, with its own mandate, also under the cap. Total: 353,490. You said "total." The protocol heard "per transaction." AP2's own community has been circling this: there's an open proposal to add a budget field, an open feature request for cross-merchant enforcement, and a discussion about where cumulative state should live that has sat without a maintainer answer since May. I've asked the narrower question: can a task even be identified across multiple mandate chains?

Outcome, loyalty, meaning. Three different failures, and in all three, every artifact validates. When every part is correct and the whole is wrong, the problem is not a missing feature in any part. Something between the parts is missing.

Products are shaped like their users

Why does this keep happening? Because every one of these systems was designed for a human, and humans bring an enormous amount of unwritten machinery to an interface.

A human notices when the confirmation email doesn't arrive. A human sees the little "Sponsored" chip next to the first result and discounts it without thinking. A human keeps a running total in their head, badly, but well enough to flinch at a second charge. Product design leans on all of this constantly and none of it is written down anywhere, because it never had to be. The assumptions lived in the user.

An agent inherits the interface without the assumptions. It gets the capabilities and none of the flinches. And the popular fix, telling the agent to behave like a careful human, gets it exactly backwards: you keep the constraints that existed for human perception and drop the perception they relied on. What you actually need is the machinery made explicit, which is a different artifact than a prompt.

I spent years building design systems, and this is a familiar failure. A component library without usage rules produces interfaces where every component is used correctly and the page is still wrong. Tokens, lint rules, and governance exist because "technically valid" and "what we meant" drift apart the moment the person who meant it leaves the room. Agents leave the room at scale.

The missing layer, in five sentences

Here is the shape of the thing I think is missing. I call it a handshake, for lack of a better word.

The user gives the agent a private mandate: goals, limits, tolerances, and the boundaries of what the agent may accept on its own. That mandate never leaves the user's side in full; before crossing any consequential boundary, the agent and the system reconcile a minimal, purpose-bound slice of it with the system's declared terms, and the result is a small, versioned, mutually accepted contract. Critical limits in that contract are enforced outside the model, because a language model must never be the final judge of its own authority. Changes that alter what the outcome means to the user suspend execution and go back to the user; technical adjustments inside the agreed envelope don't, because a system that asks about everything trains its user to approve everything. And "done" is not any system's success flag: it's the contract's acceptance criteria, proven jointly by receipts, so a valid payment for a failed order can never add up to "I bought the phone."

That's the whole idea. The rest is bookkeeping, and the bookkeeping is where it will live or die.

Don't we already have protocols for this?

Mostly, yes, and that's good news. UCP gives commerce semantics: catalogs, carts, checkout, order lifecycle. AP2 gives payment mandates, receipts, and cryptographic binding of an authorization to a specific transaction. WebMCP exposes structured tools in the browser. GNAP and OAuth's rich authorization requests handle delegated, scoped authority. ODRL can express usage policies. Verifiable credentials handle attestation. Anyone proposing to reinvent any of that should be ignored, including me.

I went through these one by one and conceded everything they cover; the written-up comparison is here. What survived is narrow, six items, and honestly three carry most of the weight: the private mandate with minimal disclosure, the semantics of what counts as a material change, and the composition rule that turns a pile of per-system receipts into a user-level outcome. Every existing protocol attests its own layer, correctly, and stops at its own edge. The failures in this essay all happen at the edges.

What this can't fix

Some things this layer cannot do, and pretending otherwise would be worse than not building it.

It cannot make anyone's claims true. A contract records who claimed what, at which version, with what level of assurance. A merchant that lies about stock still lies; you just get to prove it afterwards.

It cannot fully escape its own circularity. The mandate that constrains the agent is compiled from your words by the same kind of model it constrains. You can contain that: validate the structure outside the model, track which fields came from you versus the agent's inference, require confirmation for the consequential ones. Contain, not eliminate. Anyone who tells you the translation problem is solved is selling something.

And it can fail by succeeding. If the handshake escalates to the user often, people will click approve without reading, and then the layer manufactures the exact false safety it was built to prevent. In my working model the happy path gets one approval. One. If a design needs five, the design is wrong, and "the user approved it" becomes a legal fact rather than a true one.

Try to kill it

I've written this up as a public working repo, and I want to be clear about what it is: a request for critique, not a standard. It has kill criteria written down. If the three scenarios above can be prevented by existing mechanisms I missed, the delta collapses and the project should be repositioned or stopped. I have already had to sharpen one scenario after my own review: the naive version of the budget story dies against AP2's per-transaction price caps, and only the task-level version survives.

The three protocol questions are live threads, linked above, and any of them may yet come back with "the spec already handles this." Good. That is the cheapest possible way for me to be wrong.

If you build agents, run payments, work on any of these specs, or just enjoy demolishing other people's abstractions: the repo is here. Tell me which of the six delta items is already covered. Issues are open.

If you are new here, I am a product design leader and also work on agentic experience patterns. The working documents, including the parts where the idea gets taken apart, are public in the repo.