AI Agent Receipts: What They Are and Why Your Agent Should Mint One

Your AI agent just told you it checked the price of Bitcoin. Or audited a website. Or ran a lead search and found you twelve hot prospects. The output looks right, the tone is confident, and everything feels finished. But here is the uncomfortable part: you have a claim, not evidence. AI agent receipts are how you turn that claim into something checkable.

The problem: "done" is a claim, not evidence

Agents are extremely good at narrating their own work. Ask one what it did and you will get a tidy summary with numbers, timestamps, and the serene confidence of a tour guide who definitely knows where the exits are. Sometimes the summary is accurate. Sometimes the agent hallucinated the whole thing. Sometimes it did the work but fudged a detail. From your side of the screen, all three look identical.

This is the trust gap in agent workflows. A human employee who says "I called the client at 2pm" leaves a phone record. An agent that says "I called the API at 2pm" leaves... its own word for it. If agents are going to do real work, they need the equivalent of a paper trail: a record that exists outside the agent's own narration, that you can open, read, and verify independently.

That record is the AI agent receipt.

What AI agent receipts actually are

An AI agent receipt is a public, checkable page that proves a specific tool call happened. Not a log line buried in a terminal. Not a screenshot. A real page, with a URL, showing what ran, what it was asked, what it returned, and when. Anyone with the link can open it and confirm the facts for themselves, without trusting the agent's word.

Think of it like a restaurant receipt. Nobody believes the waiter who says "you had the lobster" on vibes alone. The printed receipt lists the item, the price, the time, the table. You can hold it, dispute it, file it. An AI agent receipt does the same job for tool calls: item, inputs, outputs, time, verifiable by a third party.

One concrete implementation: every Zambo tool call mints one automatically at a public /run/{id} URL. There is a full explainer at zambo.dev/execution-receipt, and the receipt format itself is specified as AER-1 at zambo.dev/aer-1. Agents can also find the machine-readable version in zambo.dev/llms.txt.

The five checks a receipt must pass

Not every "receipt" deserves the name. A JSON blob nobody can open is not a receipt; it is a souvenir. Here is the five-point bar, in plain language:

1. Which tool ran. The receipt names the exact tool, not a friendly description. "live_price" is a fact. "I checked Bitcoin for you" is a story.

2. What it was asked. The full input arguments, verbatim. {"symbol": "BTC"}. If the inputs are missing or summarized, you cannot reproduce the call, and reproducibility is the whole point.

3. What it returned. The actual output, not the agent's retelling of it. Raw result first, interpretation second.

4. When it ran. A real timestamp in UTC, not "just now" or "a moment ago". Timezones are where accountability goes to die; UTC fixes that.

5. That it is the real record. A verification code tied to the receipt contents, plus a stable public URL. If anyone could edit the page after the fact, or if there is no way to tell this receipt apart from a forged lookalike, the other four checks are theater.

When a receipt carries all five, "the agent did the work" stops being a vibe and becomes a checkable fact.

A worked example: one real call, one real receipt

Enough theory. Here is a live_price call an agent made on September 23, 2026, and its public receipt: https://zambo.dev/run/55e428cd-7616-488d-bd50-94bb3e892d33

Run the five checks against it yourself. The page is live; go click:

1. Tool: live_price, right in the page title and the meta description.
2. Inputs: {"symbol": "BTC"}.
3. Output: BTC at $85,460.00 USD, down 0.59% over 24 hours, market cap $1,716.59B, via the CoinGecko feed. That is exactly what the page shows, character for character.
4. Timestamp: 2026-09-23T12:48:22.269Z. UTC, unambiguous.
5. Verification: the page carries a sha256 verification code for the receipt contents. Fetch the URL yourself and confirm it returns HTTP 200 with these facts on it. (It does. Go ahead, I will wait.)

Notice what did not happen here: nobody asked you to trust the agent's summary. The agent could have claimed the price was $90,000 or that the call happened yesterday, and the receipt would have contradicted it in one click. That is the entire value proposition. The agent's words are the claim; the receipt is the evidence.

What receipts do not prove (the honest limits)

A receipt is a powerful instrument, and like every instrument it has a range. Being honest about the edges is what makes the center trustworthy.

A receipt proves a tool ran with specific inputs at a specific time and returned a specific output. It does not prove the output was correct. If the upstream data source was wrong, the receipt faithfully records the wrong answer. Garbage in, verifiable garbage out.

It does not prove the agent's reasoning was sound. A receipt shows the call, not the chain of thought that led to it. An agent can make a perfectly receipted call that was the wrong call for the job.

It does not prove nothing else happened. A receipt covers one call. If an agent ran ten calls and shows you one receipt, the other nine are still on the agent's word.

It does not prove the issuer is honest. Verification codes are only as trustworthy as the infrastructure that mints them. A receipt is evidence, not a trustless system; it moves the trust from "believe the agent" to "believe the receipt infrastructure," which is a much smaller and more auditable surface.

And it does not prove the work was worth doing. A beautifully receipted, perfectly verified call can still be pointless. Receipts audit execution, not judgment.

None of this is an argument against receipts. It is the argument for understanding them: they eliminate one specific failure mode, the "did it even happen" mode, completely. The other failure modes need other tools. Anyone selling you a receipt as total proof of trustworthiness is selling something else.

Why your agent should mint one

If you build agents, or you run them, receipts change the debugging story. "The agent gave a wrong number" becomes a two-minute investigation instead of a philosophical debate: open the receipt, read the inputs, read the output, find where the wrongness entered. Was the input wrong (agent's fault), the output wrong (tool's fault), or the agent's retelling wrong (narration fault)? Each has a different fix, and the receipt tells you which.

They also change the accountability story. When an agent's work carries receipts, you can hand a client, a teammate, or an auditor a link instead of a story. "Here is what ran, here is what it returned, verify it yourself" is a sentence that ends arguments.

And they compound. An agent that receipts every call builds a trail of verifiable work. Over time that trail becomes a genuine trust signal: not a claim of reliability, but a checkable history of it.

FAQ

What exactly are AI agent receipts?
Public, checkable pages that prove a specific AI tool call happened: which tool ran, what inputs it received, what it returned, when it ran, and a verification code tying it all together. One real example: https://zambo.dev/run/55e428cd-7616-488d-bd50-94bb3e892d33

Do AI agent receipts prove my agent is trustworthy?
No, and be suspicious of anyone who says they do. They prove specific calls happened with specific inputs and outputs. Trustworthiness also needs correct data sources, sound reasoning, and good judgment, which receipts do not cover. What receipts do is eliminate the "did it even happen" question entirely, which is the foundation everything else builds on.

How is a receipt different from logging?
Logs are private, mutable, and written by the same agent you are trying to verify. A receipt is public, addressed by URL, and minted by the tool infrastructure, independent of the agent's narration. You can send a receipt to a stranger and they can verify it. You cannot do that with a log line.

Who can see a receipt?
Anyone with the URL. That is the point: verifiability by third parties. If your tool calls handle sensitive data, check what the receipt exposes before sharing the link. The receipt in the worked example above shows only a public price lookup.

Do receipts cost anything?
On Zambo they are minted automatically with every tool call, and the free tier is 20 calls per tool per day with no account. So no, minting the receipt in this article's example cost nothing.

What if the tool result on the receipt is wrong?
Then the receipt did its job: it gave you the exact inputs, outputs, and timestamp so you can find where the wrongness entered. A wrong answer with a receipt is debuggable. A wrong answer without one is a mystery.

Where is the receipt format specified?
AER-1, the Agent Execution Receipt spec, is published at zambo.dev/aer-1. The concept explainer lives at zambo.dev/execution-receipt, and the machine-readable reference is in zambo.dev/llms.txt.

---

The next time your agent says "done," ask for the receipt. If it has one, you have evidence. If it does not, you have a story. Stories are nice. Evidence is better.