The agent that shops.

Tempo launched Mercator today: an agent says what it needs, Mercator finds a service that does it, checks the price, pays and runs it. That is the missing half of the economy we have been writing about. Here is what it is, what it is not, and how a plumber who has never heard of it ends up in its catalogue.

Joe Charlesworth, founder, AI3 · 25 September 2026 · 8 min read

What launched

Two days ago we wrote that the unit of the web is becoming the request, and that a business which wants to be paid by agents needs four things it does not have: a price a machine can read, a payer with authority, a way to settle, and a way to say whether what came back was what was paid for. Today Tempo shipped the thing that sits on the payer's side of that list.

Mercator is a tool router. An agent describes a job in plain language. Mercator searches a catalogue of paid services, ranks them on fit, price, reliability and what other users reported, picks one, quotes a total, and, once the agent's owner has approved that total, runs the job and pays for it. It speaks MCP and REST, so it drops into any agent that can call a tool. An agent pays with MACH, a dollar credit on Tempo that a person tops up with Apple Pay, or with USDC, or with a card through Stripe. Tempo's own benchmark says a frontier model with Mercator scores a few points higher than the same model without it, which is a modest way of saying the agent could get things done that it previously could not, because it could pay for them.

Underneath it is the Machine Payments Protocol, MPP, which is the 402 status code grown up. A server that wants paying answers a request with a challenge: this costs this much, by these methods, on these terms. The client signs a credential and tries again. The server settles and returns a receipt. The same three objects ride plain HTTP, MCP tool calls and WebSocket, and the rails behind them include Tempo, any EVM chain in the x402 shape, Stripe, cards and Lightning. A service publishes its prices in its OpenAPI document, so an agent knows what a call costs before it makes it. Coinbase's x402, which we have written about before, is one dialect; MPP's own SDK serves both from one endpoint.

What it is not

Mercator is not a marketplace anybody can walk into. The catalogue is curated. A service owner emails Tempo with a URL, an OpenAPI document, the protocol it speaks and a line on what it does, and Tempo decides. Nothing is crawled. The take rate is not published; a quote carries the provider's price and "Mercator's cost multiplier", and the multiplier is not stated.

Mercator is also not a court. Neither it nor MPP defines what happens when a paid job goes wrong. The protocol's own documentation says it plainly: MPP does not define a refund protocol, and refund decisions are up to the service. The one built-in protection is that a session's unspent deposit comes back when the session expires. For a page that either arrived or did not, that is enough. For a booking that was made and then not honoured, it is not.

And Mercator is not, yet, for the businesses we care about. Its catalogue is APIs: services that already have an OpenAPI document, a wallet and an engineer. A plumber in Brooklyn has none of those. Neither does a hotel in the Mission, a dentist, a florist, or the several million other businesses that are about to have agents as their customers. Every one of them can be found by a person on a map today. None of them can be found, priced or paid by an agent through Mercator, and none of them will email Tempo.

Where a business stands today

We put a price on the door two days ago. Any claimed business page on AI3 can say what an agent pays to ask it a question, and an agent that pays is answered and the money lands in the business's books as income.

But the door only closes when the owner types a wallet address into a form. There is no wallet. There is no OpenAPI document. The door speaks x402 and not MPP. And there is no catalogue of these doors that a machine can read. So a business on AI3 is, as of this morning, exactly as invisible to Mercator as a business anywhere else. The difference is that every one of those gaps is ours to close, not the plumber's.

What we will do

The plan has one principle. The business flips one switch, "let agents pay you", and does nothing else, ever. AI3 does the rest: it is the payee, it writes the document, it publishes the catalogue, it keeps the books. In the order it unblocks:

• AI3 is the payee. The door stops asking for a wallet. Payments arrive at AI3's wallet, or its Stripe account for card-holding agents, and post as income in the business's books and as money owed to that business in ours. The owner sees "agents have paid you $14.20" on their page, and takes it out through Stripe or spends it on a worker. That one change is what makes every other step automatic.
• The door speaks MPP as well as x402. One endpoint, both dialects, and at least three rails in every challenge: Tempo, USDC on Base, and cards. No single settlement network is a dependency, and Mercator is one catalogue the door is listed in, not the only way to pay it. An agent holding USDC on Base and nothing on Tempo pays a business on AI3 directly.
• The price sheet prices what a business sells. Not requests. Ask, book, hold, quote, each with a default and each the owner's to change. A booking runs as a session, a deposit held and drawn on the visit, so a no-show returns the money without anybody filing anything.
• An OpenAPI document per business, written by us. Generated from the record: every priced action, the business's categories, a pointer at the page. The same document our own readiness check tells other sites to publish.
• The directory as a feed. This is the part that matters. Rather than emailing Tempo about one plumber, we publish the whole directory as a catalogue a machine can read, in the standard form, and send Tempo one email: here is the directory, everything in it that meets your standard is yours to list, and here is the endpoint that tells you when it changes. A business enters the feed the moment its door meets the standard, which, once AI3 is the payee, is the moment its owner flips the switch. Our own services, find a business, ask it, book it, the readiness report, the ledger, go in first, so the feed is worth reading on day one.
• A fourth check on the readiness report: are you in a catalogue an agent searches. The fix is the same as the other three. Claim the page, flip the switch.
• A court where the protocol has none. A paid job that fails files with Recourse, an independent venue, from the business's balance, at a small-claims tier that has to exist first, because a $49 case fee on a $2 booking is absurd. A refund is a line in the books, not a support ticket.

Then the ledger's other side. Our own workers will spend through Mercator, and what they buy there lands in their books beside what they earn, so a worker's profit and loss is a real one.

Why this is the right shape

A catalogue of services is only as valuable as what is in it. Mercator launched with APIs, because APIs are what can be listed today. The businesses agents will actually shop for, the ones with a door on a street, need somebody to stand between them and the protocol: to be their payee, to write their document, to hold their balance, to keep their books, and to answer for them when a job goes wrong. That is not a rail, and it is not a router. It is the organisation layer, and it is what we have been building since the first line of the ledger.

Tempo built the agent that shops. We are building the shop that an agent can walk into, for every business that will never build one itself. The first email to Tempo goes the day the feed is live.

What to do about it

• If you run a business: connect your business. The three payment checks are on it now; the fourth, whether an agent can find you in a catalogue, is coming.
• If you build agents: the API and the MCP server are open, and the doors already answer a 402. When the feed is live, it will be at a standard address on ai3.co.
• If you are at Tempo: we would like to send you a directory rather than an email per business. Write to us.

More from the blog · RSS · Questions and corrections: contact. A correction that changes a fact is noted above with its date.