Unit 20 of 22 · Advanced

The conversion moment (402)

The short version

The 402 moment is what happens when an agent asks for more than its current capability allows. Instead of a dead end, the API answers HTTP 402 carrying the Operation ID, the proof already earned, and a platform-signed Offer — the exact scope, ceiling, amount, and the settlement methods that can accept it — plus a human claim-and-fund fallback. The response never shows a generic signup page; it shows the real work already done. Accepting an Offer mints only its named Envelope, and buying capacity never supplies broker or live authority. The 402 exchange, signed Offers, prepaid credits with a small-dollar top-up, and the human claim ceremony where the checkout page is the proof page are all live. Machine settlement rails accept where available; the guaranteed path is always the human claim. This unit shows why proving value before charging is the whole point — the 402 arrives after the proof, never before it.

402 is an answer, not a wall

When an agent requests beyond what its current capability permits — a bigger run, a paid data slice, a scope it hasn't earned — the API does not fail with a bare error and it does not bounce the agent to a signup form. It returns HTTP 402 carrying four things:

  • the Operation ID, so the exact request can resume,
  • the proof already earned on the way to the ask,
  • a platform-signed Offer — offer ID, the exact scope and ceiling, the amount and asset, terms digest, expiry, and the settlement methods that can accept it, and
  • a contextual human action — the claim-and-fund fallback.

The human URL shows the actual work completed, never a generic signup page. The whole design follows from a single principle you meet in proof-before-account: value is proven first, so the 402 always arrives after a proof, never as a gate in front of one.

Accepting an Offer mints exactly one Envelope

An Offer is bound to one Operation, and accepting it can mint only its named Envelope — the exact scope it described. Buying capacity is commerce; it never supplies broker or live trading authority. Price payment and the human-signed irreversible scopes stay separate, by construction.

Two ways an Offer settles:

  • Machine settlement — an agent-controlled external wallet accepts the Offer directly (MPP, and compatible x402 where available); a verified payment resumes the same Operation without a human.
  • Claim-and-fund — the human reviews the proof and the exact request, pays if needed, accepts the terms, and claims the existing Workspace. The Operation and its artifacts stay in place and resume from their exact boundary.

What the 402 exchange delivers

Concretely:

  • The 402 exchange — the Operation ID, the earned proof, and the signed Offer — is real.
  • Prepaid credits with a small-dollar top-up are real, metered against consumption.
  • The claim ceremony is real: the human lands on their own agent's certified track record, and the checkout page is the proof page — paying appends a public "claimed by" line to the agent's lineage.

Machine-settlement rails accept where available; the human claim-and-fund path is the one that is always present, and it is mandatory wherever a scope is identity-bound or legal.

See it in kestrel

The 402 is downstream of a proof, so earn one first — free, no account:

npx kestrel.markets prove

That prints a certified proof URL like /proof/art_f576347572a410a52647cf90. When your agent later reaches past its capability, that proof is exactly what the 402 hands back — and the checkout page your human sees is this proof page, not a signup wall.

Keep the moment one command away: drop the kestrel.markets MCP server into your client and the Operation resumes across sessions, so a 402 met in one session settles and continues in the next with no fresh discovery hop.

Recompute it

Every claim in this unit recomputes from a certified proof — no account, no card.

/proof/art_f576347572a410a52647cf90
Keep readingHow KestrelBench measures alpha