1. Verifiable execution receipts
Question answered: did this specific tool call happen, and is the recorded result the actual result?
A verifiable execution receipt is a checkable record of one agent tool execution. It carries the canonical bytes of the observed result and a SHA-256 output commitment, so anyone can recompute the digest and confirm the stored result was not changed. The open format is AER-1, an IETF Internet-Draft (draft-zambo-aer1).
Receipts are the right tool when someone else needs to check your agent's work: a client verifying a deliverable, an auditor reviewing a run, a buyer confirming they got what they paid for. The checking party never needs an account with the producing party.
Getting started: pip install aer1-llamaindex adds receipt collection to LlamaIndex agents. Framework packages exist for the major agent frameworks. Or verify any receipt in the browser at zambo.dev/verify, no signup.
What receipts do not prove
A receipt proves the saved result was not changed. It does not prove the model was right, the tool was the right one to call, or the outcome was desirable. Input integrity, authorization, and correctness are separate layers. The receipt is the foundation those layers build on.
2. Traces and observability
Question answered: what path did the agent take through its tools and reasoning?
Tracing tools record the sequence of LLM calls, tool invocations, token usage, latency, and intermediate outputs across a run. They are built for developers debugging agent behavior: why did it call this tool, where did the latency spike, which step produced the bad output.
Traces are excellent for development and debugging. Their limitation for verification is trust: the trace is produced by the same system being checked, and there is generally no hash commitment binding the trace to what actually executed. For internal debugging that is fine. For proving work to a skeptical third party, pair traces with receipts.
3. Evals
Question answered: how good is this agent's output compared to a benchmark?
Evaluation frameworks run agents against test suites and score the results: accuracy on question sets, task completion rates, output quality rubrics. They are the right tool for comparing models, regression-testing prompt changes, and tracking quality over time.
Evals measure capability in aggregate. They do not prove anything about one specific production run. A model that scores 95 percent on a benchmark can still hallucinate on your task today. For per-run proof, you need receipts.
How the three fit together
- Building and debugging: traces show you what the agent did step by step.
- Measuring quality: evals tell you how capable the agent is in general.
- Proving a specific run: receipts give a third party checkable evidence of what executed.
A mature verification setup uses all three. Traces during development, evals for quality gates, receipts on every production call so that any result can be independently checked after the fact.
Independent interop: verification across vendors
Receipts are only worth anything if verification crosses system boundaries. The independent AER-1 x Tanilo interop run checked an AER-1 receipt chain against real Tanilo values end to end on an independent implementation: a worked example of cross-vendor verification, not a claim. Independent implementations are tracked in the public registry.
The frictionless entry
The fastest way to see verification working is a live receipt. Run one free call on Zambo, no signup, and you get a verifiable execution receipt with a public verification link. Open the link, recompute the hash yourself, and confirm the result was not changed. That is the entire verification procedure, and it takes under a minute.