What Is AER-1? The Beginner's Guide to Verifiable Receipts for AI Agent Tool Calls
CodexFuse Team · 2026-11-05T02:37:19.462Z · 11 min read min read
What is AER-1?
AER-1 is a small, portable vocabulary for recording one AI agent tool call as a verifiable receipt. If you typed "what is aer-1" into a search box, here is the one-line version: every time an AI agent calls a tool, AER-1 gives that call a checkable record — what ran, when it ran, the exact bytes that came back, and a public URL where anyone can verify the record without an account.
AER-1 is an IETF Internet-Draft — draft-zambo-aer1-26, dated October 22, 2026, with intended status Informational — authored by Brennan Zambo. It is a proposal and a work in progress, not a finalized standard; the draft says so in plain language, and this guide will never call it one. Put simply: the AER-1 IETF draft is the spec document, and zambo.dev is the reference implementation that follows it.
The receipt answers exactly one narrow question: what did this system record for this execution? That narrowness is the whole design. The format separates what the system observed from claims about the outside world — and it separates provenance, meaning who ran or reported the action, from the record itself.
The agents people most want to audit usually run on a rented box somewhere — the same VPS hosting most developers already use for side projects — so the first place AER-1 receipts matter is on servers, where nobody is watching the terminal. That is the whole idea of an AER-1 AI agent execution receipt: one call, one record, checkable by anyone.
Why do AI agents need receipts at all?
Because an agent's work is invisible by default: it makes tool calls, reads the results, and moves on, leaving no trail a second person can inspect.
Think about the jobs agents actually do — look up a price, send a message, rewrite a file, call an external API. The agent sees each result inside its own context window and keeps going. Ask it later what it did, and you get its word for it. A receipt changes that: the execution is recorded when it happens, in a format anyone can re-check, instead of being reconstructed from the agent's memory afterward.
That is the gap AER-1 fills. It does not make agents smarter or safer by itself; it gives their work a paper trail with checkable math behind it.
What does an AER-1 receipt actually record?
Six things, each with a fixed meaning: a stable identifier, a timestamp, the exact bytes the output commitment was computed over, the SHA-256 commitment itself, the tool plus caller scope, and a provenance class.
| Receipt field | What it means in plain English |
|---|---|
| id | A lowercase UUID that names this one execution forever. The receipt resolves at a stable public URL built from this identifier. |
| created_at | When the record was created, written as an RFC 3339 timestamp. |
| canonical_bytes | The exact UTF-8 byte sequence the output commitment was computed over. A verifier must see the same bytes before comparing hashes. |
| output commitment | A SHA-256 digest of the canonical bytes, written as "sha256:" followed by the lowercase hex digest. This is the tamper-evidence seal. |
| tool | The tool's name, version, and caller scope (for example "public"). |
| provenance_class | What the recording system actually did: executed, observed-via-gateway, or logged-by-agent. |
Two rules make this work as a public system. First, the public URL is a resolution rule, not a stored field: every receipt must be retrievable at a stable public URL without an account, wallet, or token — in the reference implementation that address is https://zambo.dev/run/<id>.
Second, the commitment is only as good as the bytes behind it. Verifiers must receive or reproduce the exact same canonical bytes before comparing hashes. Change one byte and the digest changes with it, so the receipt no longer matches.
What is a provenance class — and why should you care?
A provenance class says what the recording system actually did. "Executed" means the system ran the tool itself. "Observed-via-gateway" means it watched the call pass through a gateway. "Logged-by-agent" means the agent reported the call about itself.
This is the field most receipt schemes skip, and it is the one that keeps AER-1 honest. A receipt for a call the system executed itself is stronger evidence than one the agent merely logged about itself. Because the class is a first-class field, a verifier can tell which kind of evidence it is looking at instead of treating every receipt as equal.
In other words, AER-1 does not just tell you what was recorded — it tells you how much to trust the recording.
How do you check an AER-1 receipt?
Open the receipt's public page, read the recorded bytes and the digest, recompute the SHA-256 yourself, and compare. Four steps, no account.
- Open the public receipt page. Replace <id> with the receipt's UUID at https://zambo.dev/run/<id>. The page shows the observed result and the saved time.
- Read the machine verification response. The matching machine link returns the verification checks: it identifies the tool, the recorded request context, the canonical saved bytes, and the output hash digest.
- Recompute SHA-256 over the decoded saved bytes yourself. Any SHA-256 tool works. The receipt is canonical JSON, so pasting it into a JSON formatter first makes the structure readable.
- Compare your digest with the recorded one. A match means the saved record has not changed since it was saved — and, in Zambo's own honesty line, "A receipt proves the saved result was not changed since it was saved. It never proves the answer was right and never proves an external event happened."
Notice the honest tension the spec itself keeps: the draft says verification is "offered as a public HTTP endpoint rather than offline recomputation," while Zambo's own package page says "anyone holding a receipt can recompute the hashes and confirm the chain without trusting any server." Both are true in practice — the hosted page is the easy path, and the math is the independent path.
What is a workflow receipt?
AER-1 workflow receipts bind an ordered sequence of step receipts to a single goal with one Merkle root over the step sequence — one hash that commits to every step, in order.
Multi-step sessions get a workflow page at https://zambo.dev/workflow/<workflow_id>. Step receipt pages link up to the parent workflow as "Part of workflow," and the workflow page links down to each step. The newest draft revision adds a truncation limit (Section 8.4) so a workflow receipt cannot silently drop steps.
Alongside workflows, the spec defines hash-chained job timelines for tamper-evident sequencing of executions: each execution links to the previous one, so reordering or deleting an entry breaks the chain.
This is the per-call receipt layer. If you want to navigate whole working sessions of an agent instead, arvre draws Claude Code sessions and their forks as a tree you can walk in the terminal — sessions above, receipts below, different jobs entirely.
What does a receipt NOT prove?
Almost everything people wish it proved. A receipt proves the bytes were not altered; it never proves the answer was right, the reasoning was sound, or anything happened in the real world.
| An AER-1 receipt proves | An AER-1 receipt does NOT prove |
|---|---|
| The saved result was not changed since it was saved | The answer was right |
| The steps ran in the recorded order (workflow root) | The workflow achieved its goal |
| The recorded bytes match the recorded digest | The provider's data was true |
| The sequence was not reordered (hash chain) | An external side effect occurred |
The draft's own introduction draws this line: a receipt "does not prove an external business outcome the system did not observe, and it does not turn a planned, blocked, or preview action into a completed execution." Zambo's verifier page says the same thing in plainer words, and the package documentation adds a third: "A matching hash does not prove the action ran, the data is true, or any external outcome occurred."
Hold onto that line and AER-1 stays useful. Lose it, and a receipt becomes a false certificate.
Who is building with AER-1 today?
As of November 2026, the ecosystem for verifiable AI agent receipts is the author plus early adopters: the Zambo reference implementation, an OpenAI Agents SDK package, a seven-language conformance kit, and a few independent verifiers named in the draft itself.
The reference implementation is Zambo (zambo.dev): "Give your AI hands, memory, and proof." You paste the MCP endpoint into your AI app's connectors — no API key is needed to start — and tool calls made through it get public receipt pages, free for 20 calls plus one wrap-up every day.
For developers, the PyPI package aer1-openai-agents (version 0.1.20, released November 2, 2026, Apache-2.0 license) wraps OpenAI Agents SDK runs so every finished job carries an AER-1 workflow receipt. Its page notes that the processor "never touches the network and never changes agent behavior. It only observes."
For implementers, the conformance kit lives on GitLab with seven bundled runners — Rust, Go, TypeScript, Python, Java, C#, and Swift — each checked against the draft's vector corpus. An implementation counts as conformant when it produces byte-identical verdicts across the corpus. The draft's implementation-status section also reports independent verifiers built from the draft text alone, including a production validator and Node.js, Java, and Perl verifiers.
This is a young lane, and the neighboring lanes are filling in too: AgentFirstStack is building agent-native analytics and session replay, and Octomind is building a CLI-first runtime for coding agents — each a different layer, none of them rivals to a receipt format.
AER-1 vs x402: receipts are not payments
AER-1 and x402 solve different problems: AER-1 records what an agent did, while x402 pays for it. They are different lanes, never rivals.
x402 is the crypto-payment rail for agent transactions; AER-1 is the verifiable paper trail for agent executions. An agent could in principle use both — pay over x402 and receipt the work with AER-1 — but the draft disclaims any ownership of adjacent categories, and the two specs do not depend on each other.
Sources
The draft-zambo-aer1-26 text on the IETF archive and Datatracker; Zambo's project pages at zambo.dev, /aer-1, /verify, and /add; the PyPI page for aer1-openai-agents; and the author's GitLab Pages hub — all fetched on November 5, 2026. A news-vertical search for independent coverage returned only the draft text itself: no third-party press or explainer existed as of this writing.
Frequently Asked Questions
Is AER-1 an official standard?
No. AER-1 is an IETF Internet-Draft — draft-zambo-aer1-26, dated October 22, 2026, with intended status Informational — and Internet-Drafts are explicitly "work in progress," valid for a maximum of six months. The current draft expires April 25, 2027. The author writes that the document "does not establish certification, registry membership, universal adoption, or a finalized standards status." If you arrived searching for the agent tool call receipts standard, this draft is the closest thing that exists — but it is still a proposal, not a ratified standard.
Does an AER-1 receipt prove my agent did the right thing?
No — and that is the design. A receipt proves the saved result was not changed since it was saved. It never proves the answer was right, the reasoning was correct, or an external event happened. Treat it as tamper-evidence for the record, not a certificate of correctness.
Can I verify a receipt without creating an account?
Yes. Every receipt resolves at a stable public URL with no account, wallet, or token — https://zambo.dev/run/<id> in the reference implementation, where <id> is the receipt's UUID. You can also recompute the SHA-256 over the canonical bytes yourself and compare it with the recorded digest.
What is a workflow receipt?
A receipt for a whole multi-step run: it binds the ordered step receipts to a single goal with a Merkle root over the step sequence, so changing any step — or their order — breaks the root. The workflow page links to each step receipt, and each step links back to its workflow.
How is AER-1 different from x402?
AER-1 is a verifiable record of what an agent's tool call did; x402 is a payment rail for agent transactions. Receipts versus payments — different lanes, and they can coexist.
