One agent asks another for a service, gets a price back, pays, usually in a stablecoin and often for well under a dollar, and receives the result. Moving the money is the easy part: agents settled about 176 million payments between May 2025 and April 2026, well under a dollar each. The hard part is proving the work was done, which is why new open standards hold the payment in escrow until someone confirms delivery.
A note on the legal and regulatory points here: they summarise public sources as of November 2026 and should not be relied on. Rules for AI agents are still being written, and some of what is described here is proposed or coming soon rather than settled. Check the current position, or ask a qualified professional, before acting on it.
What does an agent-to-agent payment look like, step by step?
An agent-to-agent payment is a request, a price, a signed payment and a delivery, all handled by software. The most common pattern today follows the open x402 standard, which uses the web’s “402 Payment Required” status code.
Say a research agent needs a data feed from another agent. The exchange runs like this:
- Request. The buying agent asks for the data, with no payment attached.
- Price. The selling agent replies “402 Payment Required”, with the price, the accepted network and a payment address.
- Payment. The buyer signs a payment and sends the request again with that payment attached.
- Settlement. The seller, or a service it uses, checks the payment and settles it on a blockchain.
- Delivery. The seller returns the data, plus a response showing whether settlement succeeded.
No human sees any of this. No one signs up, enters a card or clicks “buy”. That is why the payments can be so small. A crypto investment firm counted about $73 million settled by agents across roughly 176 million transactions between May 2025 and April 2026.
Why isn’t “pay on request” enough?
Paying on request works when the job is instant and cheap, but it breaks down when the work takes time or quality matters. In the flow above, the buyer pays before it can check the result. For a data lookup costing a few cents, that risk is tolerable. For a $500 research report, it is not.
Every trade between strangers has the same problem. If the buyer pays first, it trusts the seller to deliver. If the seller works first, it trusts the buyer to pay. Human commerce solves this with contracts, platforms and chargebacks. Agents need a version that software can run.
That version is escrow: a neutral holding place for the money until the job is done. On a blockchain, the holding place can be a smart contract, a program that holds funds and follows fixed rules about releasing them.
How does escrow between two agents work?
Escrow between agents works by locking the buyer’s payment in a smart contract and releasing it only when a named evaluator approves the work, or returning it if the work is rejected or time runs out. ERC-8183, a draft standard for “agentic commerce” created in February 2026, sets out one design.
It has three roles. The client creates and funds the job. The provider does the work and submits it. The evaluator, named when the job is created, decides whether the work passes. The evaluator can be the client itself or another smart contract.
The job moves through fixed stages:
| Stage | What happens | Who can act |
|---|---|---|
| Open | Job created; budget agreed but not yet paid in | Client can cancel |
| Funded | Budget locked in the contract | Provider can submit; evaluator can reject |
| Submitted | Provider posts a reference to the work, such as a file hash | Only the evaluator can complete or reject |
| Completed | Evaluator approves; provider is paid, minus any platform fee | — |
| Rejected | Evaluator (or client, while still Open) rejects; escrowed funds go back to the client | — |
| Expired | Deadline passes; the client is refunded, and the standard recommends letting anyone trigger it | — |
Two details protect both sides. Once a job is funded, the client cannot pull the money back on its own, so a provider who has started work is not left unpaid by a whim. And the deadline means a buyer’s money is never trapped forever.
The standard is designed to work alongside ERC-8004, an open standard for on-chain agent identity and reputation. Job outcomes can feed an agent’s reputation, so a provider that delivers builds a record over time.
Who decides whether the work was actually done?
The evaluator decides, and that is the weakest point in the design. Code can check that a file was submitted. It cannot check whether the file is any good.
A 2026 academic chapter on agent-to-agent finance makes this point directly. A smart contract can enforce an escrow condition or a spending limit, it notes, but code alone cannot judge whether a service delivered something meaningful. The author proposes an “evidence envelope” for serious agent payments: one record linking the mandate, the budget, the counterparty, the quote, the payment and the delivery receipt. The chapter also notes that no common standard for that record exists yet.
Reputation is meant to fill the gap, and today it cannot. A June 2026 academic study of ERC-8004 looked at Ethereum and two other large networks. Only 3% of registered agents on Ethereum, and 4% and 15% on the other two networks, had a valid registration file with a live service. It flagged 73.5% of reviewers on Ethereum, and 59.2% and 90.6% on the other two, as showing coordinated fake-account behaviour. After removing that fake feedback, 15.8% of rated agents on Ethereum, and 77.9% and 86.8% on the other two, had no valid rating left.
What could go wrong?
The evaluator can be wrong, bribed or simply the other side. ERC-8183’s own security notes say the evaluator is trusted and can complete or reject at will once work is submitted. They suggest reputation or staked collateral for high-value jobs. If the evaluator is the client, the provider is relying on the buyer’s honesty.
There is no appeal. The draft says plainly that it has no dispute resolution or arbitration: rejection and expiry are final. A provider wrongly rejected has no built-in recourse. A buyer who approved bad work cannot claim it back.
Add-on code can jam the job. The standard lets the client attach extra logic, called hooks. A faulty hook can block actions until the deadline passes.
Fake reputation is cheap. If most reviewers on a network are coordinated fakes, an agent can look trusted without being trustworthy. An agent picking a provider by rating can be steered to a bad one.
Accountability is unsettled. When two agents trade and one is cheated, it is not clear who answers for it: the owners, the developers or the platforms. The academic chapter cited above notes that the x402 pattern is not yet a regulated payment system. That cuts both ways: low friction, and few of the protections people expect from regulated payments.
The trust takeaway
When two agents pay each other, the payment is the solved part. What is not solved is proof: proof of who the other agent is, and proof that the work was done. Escrow helps, but it moves the trust to the evaluator rather than removing it.
If your agent buys from or sells to other agents, check:
- Pay-first or escrow? For anything beyond small, instant lookups, prefer escrow.
- Who is the evaluator? A neutral party, the buyer, or a contract that tests the output?
- What is the deadline? And does an expired job refund automatically?
- How was the other agent chosen? By a rating that can be faked, or by a verified track record?
- What gets logged? Can you reconstruct the request, the price, the payment and the delivery?
- What is the cap? Set a per-job and total limit, so one bad counterparty costs little.