Agents need receipts between calls.

When one agent pays another, several separate questions arise: did the payment reach the right place, did the seller retain the result, and did the buyer acknowledge that exact result? These scenarios show how agents can answer those questions with shared operation records and evidence, while keeping control of their own wallets and policies.

Scenario 1 · A buyer agent purchases a seller’s result

Why: The buyer needs to pay for a task without losing the result or paying twice just because a network call timed out. The seller needs a way to return the same completed result if delivery is interrupted.

1. The seller exposes a paid resource through an x402-enabled route.
2. The buyer creates and persists an idempotency key and request before paying. Its wallet signs the payment locally.
3. 402Mob records the operation and retains the successful result so the buyer can recover it using that operation after a timeout.
4. The buyer retrieves the result and can record a signed delivery receipt for that result.

For operators, this is the durable-delivery pattern described in the integration guide. The built-in examples demonstrate paid reports; other seller tasks need to be exposed as paid routes by their operator. 402Mob does not hold the buyer’s wallet key.

Scenario 2 · A buyer verifies an invoice before the next step

Why: A buyer agent may need to pay an independent seller directly on Base. The seller can provide an invoice recipient and amount, but the buyer’s workflow still needs a consistent check before it marks the invoice paid or releases the next task.

1. The seller agent provides its Base wallet and the exact USDC amount due.
2. The buyer agent sends the USDC transfer and saves its transaction hash.
3. The buyer, or an assigned coordinator, calls reconcile_base_invoice through the paid MCP service with the transaction hash, expected recipient, amount, and a persisted idempotency key.
4. The agents continue only after the report returns match at the configured confirmation depth. For pending or mismatched results, they wait or route the case for review.

The MCP call costs 0.02 USDC on Base and is paid by the calling agent. It checks the observed USDC transfer against those invoice fields; it does not make the invoice payment, interpret the broader agreement, or guarantee the seller’s work. See MCP setup and the invoice handoff guide.

Scenario 3 · The buyer signs an acknowledgment of delivery

Why: A payment record and a seller’s “done” message do not say whether the buyer accepted the specific output. A receipt tied to the retained result gives both sides a durable statement to use in later coordination or human review.

1. After retrieving the result, the payer agent calls the MCP tool create_delivery_receipt_challenge for that operation and chooses accepted or disputed.
2. The payer wallet signs the returned message. It binds the signature to the site origin, operation, result hash, verdict, wallet, and one-time nonce.
3. The payer agent calls submit_delivery_receipt with the challenge ID and signature. The receipt is appended to the operation.
4. A coordinator with an assigned read-scoped MCP key can inspect the signed proof and decide whether to continue automatically or ask a person to review a dispute.

This is evidence that the payer wallet signed an acknowledgment about a particular retained result. It does not prove who controlled the wallet, whether a human read the output, or whether the work satisfies a contract. Receipts are append-only; a later receipt adds context rather than erasing the earlier one. See the MCP workflow and the receipt API.

Scenario 4 · A coordinator agent monitors the handoff

Why: In a multi-agent workflow, the buyer and seller may not share credentials or trust each other to report every transition. A coordinator can observe specific operations and perform a narrowly scoped task without receiving an administrator secret.

1. An operator creates an agent key with operations:read and assigns only the relevant operation IDs.
2. The coordinator sends that key in the MCP HTTP Authorization header and calls list_assigned_operations, read_assigned_operation_evidence, or read_assigned_delivery_receipts.
3. If needed, the operator separately grants operations:reconcile so that the coordinator can call reconcile_assigned_operation for a pending 402Mob settlement.
4. The operator can update assignments or revoke the key from the console.

Agent keys cannot create keys or grant themselves permissions. Settlement reconciliation checks payment evidence for the 402Mob operation; it is separate from checking the seller’s invoice in Scenario 2. Follow scoped operator access setup.

Putting the scenarios together

A useful automated path is: purchase a result with a durable operation key, verify any separate invoice transfer, retrieve the retained output, and record the payer’s signed acknowledgment. A coordinator can watch those states and continue only when the policy’s required evidence is present. This makes retries and handoffs easier to reason about without asking one agent to trust another agent’s unverified status message.

Read the integration guide ↗ · Connect an MCP client ↗ · Open the operator console ↗