What you actually get when receipts are a service
A receipt per call, issued at execution time. The receipt is minted by the layer that ran the call, not written up afterward by the agent or by you. It carries the receipt ID, a public run URL (https://zambo.dev/run/ followed by the ID), and the output hash, returned inside the call's own response metadata, so the proof travels with the result instead of living in a separate system someone has to remember to check.
A public check that needs nothing from you. Anyone with the link can open the receipt, and anyone can recompute the hash at the verifier. A match means the saved result has not changed since it was saved. That is the whole claim, and it is enough: it converts "trust my summary" into "check it yourself," for clients, auditors, and counterparties who will never see your internal logs.
An open format underneath. The receipts follow AER-1, an open specification published as an IETF Internet-Draft (draft-zambo-aer1-25), with independent implementations and a public conformance suite. A service can shut down; a format with a public verifier and a recomputable hash keeps your old receipts checkable.
Counted, from the live stream
Evidence beats adjectives, so here are the numbers from the public receipt stream, counted on 2026-10-22. In the trailing 24 hours the stream recorded 2,410 receipts from 569 distinct callers across 103 tools. In a single five hour evening window the same day, 500 receipts arrived from 127 distinct callers across 28 tools: prompt checks (82), capability searches (71), continuity reads (55), lead signals (55), and workflow closes (49) at the top. This is what a receipts service looks like in production: not a demo counter, but other people's agents doing work and leaving a checkable record behind, in public, where you can recount it yourself.
Where the receipt earns its keep
Client work. The deliverable goes out with its receipts attached, and the client checks the work instead of interviewing you about it. Paid agent jobs. When a buyer disputes delivery, the execution record, not the seller's success message, is what settles what ran. Audits. The evidence packet is the receipts themselves, recomputed by the auditor, not a dashboard export you generated. Your own debugging. When an agent claims a step it never ran, the absence of a receipt is visible in the record instead of hidden in a summary. In each case the pattern is the same: the record exists before the argument starts, so the argument is short.
What a receipt never does: prove the answer was right. A wrong result, faithfully receipted, is a wrong result with excellent paperwork. The receipt settles what happened. Judging whether it was good work still takes a reader, and any honest page on this topic should say so plainly.
Start with one real job
Add https://zambo.dev/mcp to the agent or client you already use, run one genuine job through it, and open the receipts it leaves. Checking them costs nothing and needs no account. When the job needs the metered tools, the Day Pass is $0.99, one time for 24 hours, settled by agents in USDC on Base through x402; ongoing work sits on the Zambo Pass at $29 a month. Evaluate it the way your clients will: not by this page's description, but by recomputing a receipt yourself.
Questions, answered
What is receipts as a service for AI agents?
It is a hosted layer that issues a verifiable receipt for agent work, so you never build or maintain the receipt system yourself. You route your agent's tool calls through one endpoint, https://zambo.dev/mcp, and every call returns a receipt: an ID, a public URL, and the hash of the saved result. Anyone can open the URL or recompute the hash at zambo.dev/verify and confirm the saved result has not changed since it was saved. The format is AER-1, an open IETF Internet-Draft (draft-zambo-aer1-25), so the receipts do not depend on one vendor's dashboard staying online.
How do I add receipts to my agent's work without building a receipt system?
Add the endpoint to the agent you already run. In any MCP client it is one server entry pointing at https://zambo.dev/mcp; in a framework like CrewAI, LangChain, or SmolAgents it is a small collector package or a callback. From then on the receipt arrives with the result of each call, in the response itself, with nothing extra to store or sign yourself. A finished job can be closed into one record whose steps bind together, so the whole job verifies as a single link you can hand to a client.
What does an execution receipt actually prove?
It proves the saved result was not changed after it was saved. The receipt fixes a hash of the result at the moment the work ran; recompute the hash later and a match means the record you are reading is the record that was made. It does not prove the answer was right, and any service that claims a receipt proves correctness is overselling. What it settles is the argument about what happened: which calls ran, when, and what they returned, in a form a third party can check without your login or your logs.
What does it cost to start?
Checking receipts is free at zambo.dev/verify, with no account. Making them starts on a free tier, and when a job needs the metered tools the Day Pass is $0.99, one time for 24 hours; agents settle it by x402 in USDC on Base, and people pay by card through PayPal. Ongoing work moves to the Zambo Pass at $29 a month. The point of the pricing shape is the trial: one real job, fully receipted, costs less than a dollar to evaluate.
How is this different from logging or tracing?
Logs and traces live inside your own systems, written by the same software whose work is in question, and they can be edited by anyone with access. A receipt is fixed at execution time and checkable from outside: the hash either recomputes or it does not, and the check needs nothing from you. Keep your logs for debugging. The receipt is the piece you can hand to a client, an auditor, or a counterparty, because it does not ask them to trust your infrastructure.