Learn · how agents work — part 3 of 3
How can anyone trust a purchase no human watched?
The same way you trust a contractor you have never met: through paperwork. In agentic commerce, each step of a purchase leaves a record — the permission, the offer, the payment. Software checks those records instead of watching the work. As of 2026-09-01, the records are strong on the money side and weak on the delivery side. This page walks through both halves.
How did trust work before software bought things?
Think about hiring a contractor to retile a bathroom. You have never met. You will not stand there watching for three days. What actually protects you is a chain of paper.
- The estimate. What work, at what price — in writing, before you commit.
- The signed work order. Both of you commit to the estimate. What was agreed is now on record.
- The work. The tiles go on the wall.
- The invoice and the receipt. What was done, what was owed, and proof that you paid it.
Behind all of it sits recourse. If the work never happens, you can withhold payment, complain, or go to small-claims court. Each of those works because of the paper. No paper, no case.
What does the same purchase look like at machine speed?
Meet OTTO, our example AI agent — an invoicing agent that buys OCR (text extraction from scanned pages) at $0.01 per page. OTTO's purchases take seconds, and no human watches them. Each one follows the same four steps:
The contractor's paper chain exists here too. It is machine-readable, and much of it is signed — so software can check it afterward. Here is the mapping.
| The contractor's paper | OTTO's version |
|---|---|
| The estimate | A machine-readable offer: the seller's terms and price, in a form OTTO's software can read and accept. |
| The signed work order | A mandate: standing, provable permission from OTTO's operator — what it may buy, up to what amount. Card networks add Verifiable Intent, a checkable record of what was authorized. |
| The finished work | Delivery: the service runs and returns the extracted text. |
| The invoice and receipt | A cryptographic receipt: signed, checkable proof that the payment settled. |
| Small-claims court | Nothing yet. This row has no machine version — and that is the subject of the next section. |
Where does the analogy break?
It breaks at the receipt. A cryptographic receipt proves that money moved. It does not prove that the work was done — that the pages were read, or read correctly. Today's receipts prove payment, not delivery.
With the contractor, your own eyes close that gap. You can walk into the bathroom and look at the tiles. In a machine-to-machine payment, nobody looks. If a seller took OTTO's cent and returned garbage, the receipt would look exactly the same.
The second break is the empty last row. Some rails do carry recourse: card networks have a built-in dispute process, including the chargeback. Stablecoin settlement is final by design, so any dispute process must be built on top. Neither side of that tradeoff closes the delivery gap.
And courts do not scale down. No small-claims court will hear a case about OTTO's 40-page batch — a purchase worth 40 cents. Recourse at machine scale has to be rebuilt, not borrowed.
The people writing the standards say this plainly. From a 2026 discussion in the x402 protocol's public repository:
“Mandate / budget proves may spend. Settlement proves funds moved. Without a recomputable join to what ran, disputes collapse to screenshots.”
Screenshots — because when receipts cannot prove delivery, a complaint comes down to one side's word against the other's. The agent economy is growing, and every new purchase crosses this same gap. Closing it is what the current standards work is about.
What is being built to close the gap?
Three public efforts, as of 2026-09-01. All are drafts or early programs. None is finished, and none has won — this page describes them and does not rank them.
- SEP-2828 proposes signed execution records: a receipt for the work itself, produced when a tool call runs. It began in the MCP standards process; its author later moved it, and as of 2026-09-01 it continues as a draft at the IETF, the internet's standards body. Read the IETF draft.
- Offer-receipt is an extension to the x402 protocol that staples the promise to the proof: the seller signs its offer, and after delivery signs a receipt that points back to it. The delivery confirmation is still the seller's own signature — a step forward, not independent proof. As of 2026-09-01 it is a draft, at version 0.6. Read the offer-receipt extension.
- Verifiable Intent is the card-network approach: prove what the buyer authorized before any money moves, so the front of the paper chain holds. Mastercard announced it on 2026-03-05 as part of its Agent Pay program. Read Mastercard's announcement.
What can you do meanwhile?
Read receipts for what they are. A receipt is proof of payment — nothing more. A seller's claims about delivery, quality, or revenue need their own evidence.
Prefer rails and sellers that leave public records. On-chain payments sit on a public ledger, so anyone — including you — can check a seller's payment history before spending. Then spend a little first, and check what the receipts show. A short answer on spotting fake sellers is in the FAQ.
And hold this site to the same bar. Every number we publish must be recomputable from public data — the method is public in the methodology. If a claim here cannot be checked, tell us, and we will fix it or cut it.