Agent Experience: who gets to use your service, and what it's worth

26-09-02

Faint request lines stream in from the left and meet a vertical gate of green and dark cells. Only the admitted ones continue as bright green lines ending in nodes, forming a rising profile toward the right. Labels read 01 requests, 02 policy, 03 signal.

Something quiet is happening in your logs. The share of requests typed by a human is falling. The share issued by something running on a human’s behalf is rising. Same endpoints, same payloads, completely different caller.

The gap that opens is not technical. It’s that nobody owns the question of who is allowed to use this, on whose behalf, at what price, and how well is it going for them.

The caller is not the customer anymore

For twenty years a person signed up, got a key, used the product. The key identified the person. An agent breaks that chain: there are now three parties in every call, the end user, the agent acting for them, and the model provider behind it. An API key tells you none of that. It tells you a key was used.

So the urgent thing is not capability, it’s control. Identity that survives delegation, so you know which agent, for which user, under which grant, and can revoke the agent without cutting off the human. Scopes per tool, not per product, because an agent that reads your catalogue should not be able to issue a refund. And budgets, not just rate limits: rate limits protect your infrastructure, budgets protect the customer stuck in a retry loop at 3am.

Your API is already most of an MCP server

If you have a documented REST API, the hard decisions are made. Endpoints become tools, query params become a typed schema, your docs become tool descriptions. That last one is underrated: for an agent, the description is the UI. A tool called getData with no description is a button with no label, and agents don’t guess gracefully, they guess confidently and wrongly.

Fewer, fatter tools beat many thin ones, because agents chain badly. Errors should instruct rather than dead-end. Avoid pagination, because anything that makes the agent loop costs the user tokens and costs you reputation.

Then there’s the browser. WebMCP, from the Chrome and Edge teams and now a W3C Community Group draft, does this one layer up: a page registers its capabilities as callable tools through a document.modelContext API instead of making the agent screenshot the DOM and guess where to click. Chrome is running a public origin trial.

That inversion is the point. You go from being scraped to being called, and a called service is one you can meter, price and observe. Being scraped is the worst of both worlds: you pay for the compute and learn nothing.

Getting paid per call

If agents are the callers, the pricing page is the wrong artifact. Nobody’s agent is going to read your tiers, pick Pro and enter a card.

x402 revives the long-dormant HTTP 402 status code for the alternative: the server answers 402 with a payment envelope, the client signs a stablecoin transfer, a facilitator settles it, the response is released. No account creation, and prices in the low cents that subscriptions cannot express. You don’t have to go crypto-native to take the lesson. Monthly seats assume a human who logs in, and there is no seat here.

The part everyone will skip

Most teams will ship the MCP server, wire up billing, then have no idea whether any of it works, because every dashboard they own measures humans. An agent has no session, doesn’t bounce, and spends zero seconds engaged. A 200 response and a satisfied caller are not the same event.

What you want is a view of the Agent Experience: how well an agent is doing at getting what it came for.

  • Task completion, not request success. Clean 200s ending in abandonment is a failure your uptime graph reports as perfect.
  • Turns to outcome. Clicks-to-checkout for agents, and it maps straight to the user’s token bill.
  • Retry and loop rate. Retries with near-identical arguments mean your schema or your errors are unclear. The highest-signal number here.
  • Tool selection accuracy. The wrong tool reached for is a description problem, fixable in an afternoon.
  • Cost per successful task. A tool that’s cheap per call and needs eleven calls is expensive.
  • Which agent, on whose behalf. Behaviour differs enormously by model and client, and you cannot debug an aggregate.

Support changes too. When something goes wrong the agent doesn’t email you. It retries, fails quietly, and tells its user your service didn’t work. That complaint exists only in your own telemetry, which is why the telemetry has to be built before you need it.

Putting it in one place

All three want to live at the same layer: the access decision, the callable surface, the meter and the log are one request passing one checkpoint. Build them separately and you get three systems that never quite agree on what happened.

Bouncer is one attempt at that shape: paste an OpenAPI URL, get MCP tools plus a WebMCP snippet, hand out a gateway URL instead of your real one, and wrap it in allow and deny lists, scoped keys and spend caps. Then the part I keep coming back to, every call logged with tool name, decision, latency, status and tokens. Once every call carries those five fields, the metrics above stop being a project and become a query.

The short version

Control who can use your service and on whose behalf, ship a callable surface with a price on it, measure what agents actually do. Agent Experience will become a discipline the way developer experience did, and everyone who skips it will have excellent uptime and no idea why nobody’s agent comes back.