There is a version of the agentic economy that is mostly already here. Agents can browse, form-fill, click "buy now," and extract confirmation numbers from HTML. It works, after a fashion. It is also a bag of workarounds dressed up as infrastructure.
The deeper problem is not that agents can't use the web. It is that the web was never designed to be used by agents. Every surface - the page structure, the auth flows, the pricing tables, the terms of service - was designed to be read by a human, confirmed by a human, and charged to a human who had a moment to hesitate. When you strip away the human, you discover that none of the machinery underneath was designed to handle what an autonomous program needs: a structured description of what it can do, a proof that it is authorised to do it, and a settlement path that doesn't require a human in the loop.
The result is a set of increasingly fragile workarounds: browser automation that breaks on the next CSS class rename, unofficial APIs that are fine until they aren't, OAuth tokens designed for delegated human consent being repurposed for fully autonomous agents that never get a consent screen.
What's missing is a clear account of the three things every agentic commerce platform actually needs to do - and why they have to be designed together, not added one at a time.
Layer 1: Discovery
An agent needs to answer "what can this business do for me?" before it can do anything else. That sounds like a search problem, and in some narrow sense it is - but the kind of answer that matters is much richer than a list of endpoints.
A human navigating a hotel booking site gets a visual layout, a pricing table, a terms-of-service link, and rate-limit information nowhere on the page (because humans don't need it). An agent needs all of that in machine-readable form, structured so it can be reasoned about without scraping. That means knowing not just the action names and their schemas, but the terms under which those actions are available: what scopes they require, whether they have side effects, what the pricing model is, whether a transactional call requires an idempotency key, what currency is accepted, what a refund looks like.
This is why an OpenAPI spec, while useful, isn't sufficient as a discovery layer for agents. It describes the interface well but says nothing about the terms. You can autodiscover from an OpenAPI spec that POST /v1/book takes a roomId and a checkIn date. You cannot autodiscover from it that this action charges a card, requires a spend pre-authorisation, is subject to a 10 requests-per-minute rate limit per agent, and requires booking:write and payments:charge scopes to proceed. Those are business terms, not interface terms, and agents need to see them before deciding whether to proceed.
Good discovery in an agentic system is therefore a capability spec: a machine-readable document that describes what a business can do, the terms under which it can be done, and the constraints the agent must respect. Full-text search gets an agent from natural-language intent to relevant actions; semantic search extends that to cases where the vocabulary doesn't match. But search is just the front door - the spec retrieved through discovery is what actually enables safe, autonomous execution.
Layer 2: Trust
Trust is where most "we'll add agents later" projects hit a wall, and where the gap between REST API design patterns and what agents actually need is sharpest.
Existing REST authorisation is designed around a human principal who is present. OAuth 2.0 works well when there is a user who can see a consent screen, understand what they are authorising, and revoke it. The token lifetime is usually long because rotating it requires user involvement. The scope is usually coarse - read:all, write:bookings - because humans don't think in terms of per-call spend caps.
An autonomous agent needs a different trust model entirely.
Bounded authority, not delegated identity
When an agent is authorised to spend up to €500 on hotel rooms this week, that constraint needs to be verified cryptographically on every call, not just assumed. A mandate - a signed token that carries a spend cap, a set of permitted scopes, an expiry, and a principal identity - is fundamentally different from an OAuth access token. The mandate's spend cap is reserved against before the call reaches the provider; if the call would exceed the cap, it fails before any money moves.
Scope enforcement at the gateway, not the client
It's tempting to say "our SDK will only call scoped methods." That is not trust enforcement - it is hope. Trust enforcement means that even if an agent's code is modified, or a malicious agent presents itself, the gateway verifies the scope on every invocation and rejects calls that the mandate doesn't permit. The enforcement has to live at the infrastructure layer, not the client layer.
Idempotency as a first-class property of transactional calls
A human who double-clicks "confirm booking" sees a duplicate confirmation UX. An agent that retries a failed HTTP call might be retrying a call that actually succeeded but timed out. Without infrastructure-level idempotency - a deduplication key that the gateway enforces end-to-end - every transactional action is a race condition. This is not something you can retrofit: it requires the gateway to check and set the idempotency key atomically before proxying, and to replay the stored response on a duplicate.
Rate limiting per agent, not per IP
Traditional rate limiting is an abuse-prevention measure applied at the network edge. Agentic rate limiting is a business-terms enforcement measure applied to a specific agent's identity. An agent that is well-behaved in aggregate but has a velocity spike on a particular action needs to be limited on that basis, not on the basis of shared infrastructure. Reputation - a per-agent trust score that rises with clean calls and falls with blocks or errors, and that scales the effective rate-limit quota - is a downstream consequence of this: repeat misbehaviour should throttle the offending agent progressively, not apply a flat cap equally to everyone.
Human approval as a first-class gateway response
For high-value or high-risk calls, the right answer is not "proceed" or "reject" - it is "pause for approval." This requires a native gateway status code (not an ad-hoc error response), a token the agent can include when retrying, and a mechanism for notifying the human principal and recording their decision. You cannot bolt this onto a REST API that returns 200 or 4xx, because you need a 402-with-approval-token response and a retry flow that is native to the authorisation layer.
Why you can't bolt trust on after the fact
Layer 3: Settlement
Settlement is the layer that actually makes a business's capability valuable to an agent: the thing that turns "invoke" into "paid, auditable, final."
Human commerce has settlement built into the user-facing product: the checkout page is the settlement UX. When an agent calls book_room, there is no checkout page. There is a call, a response, and a question: did money move, and is there a record that can't be disputed?
Reserve before proxy, capture after
The agent declares the amount it expects to spend when invoking a transactional action. The gateway reserves that amount against the mandate's spend cap before the call reaches the provider. On success, the actual amount charged is captured - with the platform's take-rate accounted for as a balanced ledger posting; on failure, the reservation is released. The agent's available balance reflects the state of in-flight calls, not just completed ones. A payment processor handles capture-and-charge; it doesn't handle reserve-against-a-spend-cap.
A double-entry ledger, not a transaction log
A payment processor's transaction log tells you what moved. A double-entry ledger tells you why, in a form that is auditable. When a booking is made, the ledger records the reservation against the agent's account, the capture against the provider's account, and the fee against the platform's account as balanced postings. A refund reverses those postings proportionally. The chain is immutable. You know at any point exactly who holds what, and why, going back to the beginning.
Hash-chained audit that can be externally verified
The hash-chained audit log is a specific design pattern: each record includes a hash that covers the prior record's hash, so the chain can be verified from scratch by any party with access to it. Tampering with any record invalidates every subsequent one. This is not a nice-to-have for agents - it is the mechanism that makes an agent's claim "I made this booking on behalf of this principal under this mandate" provable. WORM object storage (object-lock-retained copies in S3 or compatible) adds a second layer: even if the database is compromised, the chain of locked copies provides an independent verification path.
Why the three layers have to be designed together
The failure mode of building these layers sequentially - or bolting them onto an existing API - is not that each layer is technically wrong. It is that the interfaces between them are wrong.
Discovery produces a spec. The spec contains the trust terms: required scopes, spend constraints, idempotency requirements. If discovery is a separate system that doesn't know about trust terms, the agent has to re-learn those terms from the trust layer at invocation time - which means it can't make an informed decision about whether to proceed before it tries and gets a 403.
Trust enforces a mandate. The mandate contains a spend cap. The spend cap is enforced by reserving against the ledger. If trust is a separate system that doesn't know about the ledger, the spend cap is advisory - the agent might be told it has a €500 cap but the gateway can't actually prevent overspend without talking to something that tracks reservations.
Settlement produces an audit record. The audit record contains the mandate used, the action invoked, the amount reserved and captured, and the fraud score at invocation time. If settlement is a separate system with its own audit log, reconciliation is a manual process. If it shares the hash-chained audit chain with the trust layer's invocation records, the provenance of every transaction is self-evident.
The spec needs to be the single source of truth that the registry, gateway, and ledger all read from. The gateway needs to be the single enforcement point that reads the spec, validates the mandate, checks the fraud score, reserves against the ledger, and produces the audit record. The ledger needs to be the single source of financial truth that the gateway writes to and the business reads from.
The gap that's actually missing
The web was built for humans, and human-designed systems have a human-sized gap between authorisation and execution: the moment where a person reads the price, understands the terms, and clicks confirm. Agents don't have that moment. The infrastructure has to have it instead.
That means discovery, trust, and settlement can't be three separate bolted-together pieces. They have to be one coherent layer: a spec that carries business terms, a gateway that enforces them, and a ledger that settles and proves them. Each is independently useful; together, they are the thing the agent economy is missing.
For the credential model behind mandate signing and why API keys don't carry the same guarantees, see Why API keys are the wrong auth primitive for AI agents. For the failure mode that makes idempotency non-optional in agentic systems, see What happens when your AI agent double-books a hotel room.