Direct answer
Receipts for Agent-to-Agent (A2A) Work
Attach AER-1 receipt IDs to A2A task results, so the receiving agent can check the work before it builds on it. Agent-to-agent protocols move tasks and results between agents, but the result usually travels as prose the receiver must trust. A receipt ID riding with the result changes the receiver's options: fetch the record, verify it at zambo.dev/verify, and rely on the checked steps.
Updated October 20, 2026.
Where receipts fit in A2A
An A2A exchange has a natural seam for records: the moment a task completes and its result is handed back. The sending agent already has the result; if the work ran through a recording layer such as the Zambo MCP, it also has a receipt for each step, saved when the step ran. Attaching those IDs to the task result costs the sender nothing and gives the receiver a checkable trail instead of a confident summary. Receipts do not replace the A2A result; they sit under it, as the evidence layer the result can point to.
The fields that travel
- Receipt ID per step: the identifier of the record for each tool call that produced the result, resolvable to a public receipt page.
- The job-level record ID: for multi-step work, the identifier that binds the step receipts into one set, so the receiver checks the job as a whole.
- The result reference: a pointer from the A2A result to the saved result inside the receipt, so the receiver compares like with like rather than trusting a retyped copy.
- Payment reference, when paid: if the task was paid via x402, the payment reference rides along too, tying the result to its payment. The x402 tutorial walks through that flow.
Verify on receipt
- Collect the IDs from the incoming task result before reading the summary as fact.
- Fetch and verify each record at zambo.dev/verify or by recompute in code: a match confirms the saved result was not changed after the fact.
- Compare the saved results with the outputs in the A2A message. Differences mean the message, not the record, is what drifted.
- Build, redo, or flag: checked steps are safe to build on; steps with no receipt get redone or carried forward explicitly marked unverified, including in any handover you send on.
An example flow
A research agent is tasked, over A2A, with checking three sources and summarizing what each says. It runs the work through Zambo, so each source check leaves a receipt. Its A2A reply carries the summary plus three step receipt IDs and the job record ID. The receiving agent verifies the three records, confirms the saved source results match the summary's claims, and only then folds the summary into its own report, citing the receipt IDs onward. When a human later asks where a claim came from, the chain answers in records, not recollections: report, to A2A result, to receipt, to the saved result from the moment the check ran.
For $0.99, a Day Pass covers 24 hours of full use. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay with USDC on Base via x402.
Honest limits
Receipts cover the steps that ran through a recording layer. An A2A result can mix recorded steps with unrecorded reasoning, and only the recorded steps are checkable, so receivers should map IDs to steps rather than treating one ID as covering a whole reply. A verified receipt proves the saved result was not changed after the fact; it does not prove the sending agent chose the right sources or summarized them fairly, which the receiver still judges from the saved results themselves.
Frequently asked questions
What is an A2A receipt?
An A2A receipt is the AER-1 receipt ID attached to an agent-to-agent task result, pointing to the record of the work that produced it. The receiving agent resolves the ID to a public receipt page and verifies it at zambo.dev/verify, confirming the saved result was not changed after the fact before relying on the output.
Where do receipt IDs attach in an A2A exchange?
They attach at task completion, alongside the result they cover: one receipt ID per recorded step, plus the job-level record ID for multi-step work, and a payment reference when the task was paid. The IDs travel as references, so the result message stays light while the evidence stays fetchable.
How does a receiving agent verify an A2A result?
It fetches each receipt by ID, verifies the record at zambo.dev/verify or by recomputing the record checks in code, and compares the saved results against the outputs in the message. Steps that check out are safe to build on. Steps with no receipt are treated as unverified and get redone or flagged.
Do both agents need Zambo for A2A receipts to work?
The sending side needs its work to run through a recording layer so receipts exist; Zambo's MCP is one such layer. The receiving side needs nothing but the IDs and a browser or code to check them, because verification is public and free at zambo.dev/verify. That asymmetry is deliberate: producing records is the sender's job, checking them is open to anyone.
What does an A2A receipt not prove?
It does not prove the result was correct, the sources were well chosen, or the summary was fair. It proves the record of what ran: the tool, the inputs, the exact saved result, and the time, unchanged since it was saved. The receiver judges quality from the saved results, which is a better basis for judgment than a summary alone.