What Is an AI receipt?
For developers
An AI execution receipt is a record created when an AI tool call finishes. It identifies the call, preserves the saved output bytes and their hash, and lets anyone compare those bytes through a public verification page. A matching SHA-256 hash shows the saved bytes are unchanged; it does not establish that the result was correct.
AER-1 is an open draft spec for AI work receipts, authored by Brennan Zambo.
Plain answers about using Zambo, keeping your work, and checking receipts. A receipt shows what Zambo recorded for one call. It does not prove the answer is right.
A Zambo AI receipt is a verifiable record generated by the Zambo execution layer proving that a specific agent action actually ran. It proves execution integrity - that the work was really performed - not that the result was correct, which no receipt can judge.
Why chat logs aren't enough
Right now, the entire proof that your agent did something is usually the agent saying so. Read that sentence again - it's absurd. The same system that can misremember a step, narrate a plan as finished work, or confidently describe an action it never took is also the sole witness to its own behavior. That's not an evidence system. That's a trust system wearing evidence's clothes.
A receipt changes the witness. Instead of the agent describing itself, the layer that ran the action records it - the same way a cash register prints your receipt instead of asking the cashier to remember your total. The agent can't misremember its way out of the record, because the record doesn't come from the agent.
Anatomy of a receipt
A receipt typically carries:
receipt_id- a unique identifier for this single executed actiontimestamp- when the action ran, from the execution layer's clockagent- which agent or framework performed ittool- the specific tool or action that executedinputs- what the tool was given (parameters, arguments)outputs- what came back (results, return values, errors)verify_url- a link where anyone can independently check the record
None of this is glamorous. That's the point. A receipt is boring infrastructure - like a shipping manifest - and boring is exactly what trust is built on.
A real receipt example
Receipt JSON
This compact example uses a real Zambo receipt created on October 3, 2026. The source record names these values id, created_at, and output_hash; they are shown here as receipt_id, ts, and result_hash.
{
"receipt_id": "36a16e13-8612-4c90-a807-41c77bbe1b79",
"ts": "2026-10-03T21:44:16.133Z",
"tool": "zambo_universal",
"args_hash": null,
"result_hash": "sha256:ebf38c507e5f642acd525aec0c4b82bcff52e0b9db93993b0bd16f500c2572b4",
"prev_hash": null,
"issuer": {
"claim": "EXECUTED BY ZAMBO",
"authenticated": false
},
"receipt_schema_version": "0.3",
"verification_status": "commitment_matches",
"audit_url": "https://zambo.dev/run/36a16e13-8612-4c90-a807-41c77bbe1b79"
}The live record passed its output commitment check, but it is legacy v0.3: the issuer label is not independently bound, and issuer authentication was not checked. The source record contains no argument digest or previous-receipt link, so those fields are null, not inferred.
Seven-field receipt schema
Seven schema fields
| Field | Description |
|---|---|
receipt_id | Unique identifier for this receipt. |
ts | UTC time the execution record was created. |
tool | Name of the tool or action that ran. |
args_hash | Digest of the tool arguments, when the source records one. |
result_hash | Digest committing to the recorded result bytes. |
prev_hash | Digest of a preceding receipt when the trail explicitly links one. |
issuer | Claimed issuer or origin; not identity proof without trusted authentication. |
Receipt vs. everything else
| Record type | Who writes it | What it proves | Weakness |
|---|---|---|---|
| Chat log | The agent, narrating itself | What the agent claims happened | Can misremember, skip, or narrate plans as done |
| Screenshot | A human, of a moment | That a screen looked a certain way once | Trivially staged; proves nothing about the process |
| Application log | The app being acted on | That the app saw something | Scattered across systems; hard to tie to the agent's claims |
| receipt | The execution layer, independently | That the specific action really ran | Proves execution, not correctness |
Where receipts change the game
Receipts matter most wherever the cost of being wrong is real: agents that move money, touch production data, send messages on your behalf, or produce work you'll sign your name to. In all of those, "the agent said it did it" is not a standard anyone would accept from a human contractor - and it shouldn't be the standard for agents either. Receipts are how AI work gets the same paper trail we require of everything else that acts with our authority.
Frequently asked questions
What is an AI execution receipt?
An AI execution receipt is a verifiable record generated by the execution layer proving that a specific agent action actually ran: the tool that executed, the inputs it received, the outputs it returned, and the timestamp. It is evidence of execution integrity - proof the work was really performed - not proof the result was correct.
What does an AI execution receipt contain?
A receipt typically includes a unique receipt ID, the timestamp of execution, the identity of the agent or framework, the tool or action that ran, a summary of the inputs and outputs, and a verification link where anyone can check the record. The key property: it is generated by the execution layer, not written by the agent describing itself.
How is an execution receipt different from a chat log?
A chat log is the agent narrating its own actions - the same voice that can misremember, skip steps, or narrate a plan as if it executed it. A receipt is produced independently by the layer that ran the action, so it reflects what actually happened rather than what the agent remembers happening.
Do receipts prove my agent's answer was correct?
No - and this is the most important thing to understand. A receipt proves the action ran: the tool executed, with these inputs, producing these outputs, at this time. Whether the output was the right answer is a judgment about correctness that no receipt can make. Receipts prove execution integrity, never correctness.
Why do AI agents need execution receipts?
Because agents generate fluent, confident text - including fluent, confident reports of work they may not have done. Without receipts, the only evidence a task was completed is the agent's own word. Receipts break that circular trust by giving you evidence that exists independently of the narrator.
Further reading
- An receipt is not an audit log It explains why an execution record and a full audit log serve different purposes.
- It compares five ways to substantiate AI agent work, including receipts and verifiable credentials.
- AER-1: What the receipt Internet-Draft Actually Says (and Doesn't) It explains the draft's scope and what it does not claim.
Verify it yourself
Advanced (for developers)
Every action run through Zambo mints a verifiable receipt automatically - free, 20 total free calls per day across work tools, no account. See what receipted work looks like: run the free Did My Agent Lie? check by Zambo and watch claims get scored against real receipts.
Related Zambo resources
Define and verify an AI agent receipt · Read the AER-1 open draft · Browse live verifiable receipts · Verify the AER-1 Internet-Draft receipt fields
Advanced (for developers)
Brennan Zambo is the solo founder of Zambo - "Paste one link. Your AI can do real work, pick it up in any AI, and show proof of every step." Every AI agent tool call returns an AI Agent Execution Receipt: receipt ID, SHA-256 of the canonical request bytes, timestamp, tool called and its arguments, and the observed result, all checkable at its public /run/ page. He built 17 live products and 153 native MCP tools solo, no team, no VC. More: zambo.dev/founder.
Additional source articles
For the open receipt specification, read AER-1: The Open Specification for AI Agent receipts.