Learn · series 1 of 3

What actually happens when an agent buys something?

An agent purchase runs through six steps: you set the terms, the agent finds a seller, agrees to an offer, pays, receives the work, and files a receipt. This page walks all six through OTTO, our example agent — an invoicing agent that buys text extraction from scanned pages (OCR) at $0.01 per page.

Who is involved?

Four parties: you, the agent, the seller, and the rail that moves the money.

You, the operator. The person or company the agent acts for. You set the budget and the rules.
The agent. Software given a goal and hands. Here, that is OTTO.
The seller. The service being bought. In our example: an OCR service that turns scanned pages into text.
The payment rail. The network that actually moves the money.

Step 1 — You set the terms

It starts with an instruction. You tell OTTO: read every invoice that arrives, and pull out the line items. To do that job, OTTO needs to buy OCR — so you give it permission to spend. That permission is written down as a mandate: what OTTO may buy, and up to what amount.

Say the mandate reads: OCR processing only, up to $10 a month. (OTTO's numbers are teaching examples, not market data.) Think of an assistant holding a company card with a hard limit. Inside those lines, OTTO acts alone. Outside them, it has to come back and ask.

Step 2 — The agent finds a seller

OTTO goes shopping. Sellers list themselves in catalogs of machine-callable services; many take the form of MCP servers — services with a standard doorway an agent can walk through. OTTO reads the listings and filters: does it do OCR? What does a page cost? Does it answer right now?

Step 3 — Offer and agreement

The seller states its terms in machine-readable form: what it will do, at what price, per what unit. For OTTO's seller: one scanned page in, extracted text out, $0.01 per page. That statement is the offer. OTTO's acceptance is the agreement — an estimate accepted before the work begins, at machine speed.

Step 4 — Payment

OTTO pays $0.01. A payment this size is a micropayment — practical only because the fees are near zero. Different rails handle this step differently. This site covers four as peers: AP2 & UCP, Stripe machine payments, Verifiable Intent & Agent Pay, and x402. They differ in how they authorize the payment and how they move the money. The money mechanics are series 2: How agents pay.

Step 5 — Delivery

The seller does the work and returns it: the scanned page comes back as text. OTTO checks what a machine can check — did text arrive, is it the right page, does it parse. Then it moves to the next invoice.

Step 6 — The receipt

Every purchase should end with a record that it happened. OTTO files one per page: which invoice, which seller, what was paid, what came back. Where the payment happened on-chain, the payment part of that record is public — anyone can inspect it.

What does the purchase look like on the wire?

Steps 3 through 6 are one short exchange between the agent's software and the seller's: a request, an answer carrying the offer, a payment, and a delivery with its receipt.

Every agent purchase follows the same four steps — and step 4 is where trust lives.

On some rails, the "payment required" message is literally the web's own 402 status code, reserved as "Payment Required" in the HTTP standard (RFC 9110). x402 runs its whole flow this way — ask, get a 402 with payment details, pay, ask again, get served — as described in its public specification.

What do you see, as the human?

A summary, not a stream: pages processed, money spent against the mandate, receipts on file. Nothing about it is exotic — it reads like an expense report from an employee with a company card.

The human-in-the-loop checkpoints sit at the edges. Anything inside the mandate happens without you. Anything outside it comes back as a question, not as a purchase.