What "proof of execution" is really asking
When someone asks for proof of execution, they are asking one question with four parts:
- Did the tool actually run? Not "was a plan written," not "was an answer produced." Did the call happen.
- With what inputs? The exact arguments the tool received, because different inputs mean a different execution.
- What did it return? The exact output, as the tool produced it, not as the agent summarized it.
- When did it happen? A timestamp binding the execution to a point in time, so "it ran" cannot drift into "it might have run."
If the record in front of you cannot answer all four, you do not have proof of execution. You have a status message.
Why "it said done" keeps failing
Most agent output today is self-reported completion: a final message that says the work finished. That fails as proof in three specific ways:
- Hallucinated completion. Agents report done when the plan looked complete, when the tool errored silently, or when a step was skipped and never noticed. The report is generated by the same system that did the work, so it cannot catch its own omissions.
- Summarized outputs. Even when the work happened, the record you get is the agent's paraphrase of the tool output. A paraphrase is not the output; details that matter to you may have been dropped by the model on the way through.
- No binding to the call. A completion message does not name the tool, the inputs, or the time. It cannot be traced back to anything except the agent's word.
The fix is not "a smarter agent." It is a record that does not depend on the agent's honesty or memory at all.
The four properties that make it proof
Proof of execution is not a vibe. It is four checkable properties:
- Capture at execution. The record is written when the tool call happens, with the exact tool name, the inputs it received, and the outputs it returned. Reconstructed-after-the-fact is a story; captured-at-execution is evidence.
- Canonical bytes. The record carries the tool's output in canonical form, so what you check is what ran, not a summary of it.
- Recomputable commitment. A SHA-256 commitment over the canonical bytes lets anyone recompute the hash and confirm the stored result was not changed afterward. The check needs no account, no API key, and no trust in the agent.
- Third-party checkability. The format is open, so the record can be verified by someone who has never heard of your stack. Proof that only your own dashboard can check is an audit feature, not proof.
Miss any one and you slide back toward claims: capture without commitment gives you editable history; commitment without openness gives you proof only your own system believes.
What AER-1 gives you
AER-1 is an IETF Internet-Draft (draft-zambo-aer1-23) for verifiable execution receipts: one receipt per agent tool call, carrying the canonical bytes and a SHA-256 output commitment anyone can recompute. That is properties one through four, standardized in an open format. Try the check yourself with a live receipt, no account: zambo.dev/verify.
Because the format is open, receipts from one implementation verify against the same draft as receipts from another. The implementations registry tracks independent implementations; ship another one and claim your row. Cross-vendor verification is proven, not promised: the AER-1 x Tanilo interop ran a full receipt chain with real Tanilo values, verified end to end and double-verified by both sides.
What receipts prove, honestly
A verifiable receipt proves the saved result was not changed. It does not prove the model was right, the action was authorized, or the strategy was sound. Proof of execution covers the record of what ran; authorization records and acceptance criteria sit on top of it. Anyone selling you "provably correct agents" from execution records alone is over-claiming.
How to read a proof-of-execution claim
Next time a vendor or a framework promises proof of execution, run this five-second test. Ask for one tool call and demand the record name the exact tool, the inputs it got, the outputs it returned, and a timestamp binding them together. Then ask whether a stranger, with no account and no trust in the vendor, could recompute the commitment and confirm the result was not changed.
If the answer to either is no, you have a log line, not proof. The bar is specific on purpose: vague proof is how hallucinated completion survives. For the longer version of the test, see how to verify your AI agent actually completed the task and what an AI agent execution receipt is.
How do I prove an AI agent executed a tool call
With the receipt for that call, and only with it. To prove an AI agent executed a tool call, produce the call's verifiable receipt: the record minted at execution time that names the tool, fixes the saved result under a digest, and can be recomputed by whoever you are proving it to. Walk them through the check rather than asking them to trust the document: open the receipt, recompute the digest over the saved result, confirm it matches, and read the saved result. A screenshot of a dashboard, a chat transcript, and a log export all fail the same way: the party presenting them controls them, and nothing in them can be recomputed.
Zambo is the verifiable work layer for AI: calls made through it leave this receipt automatically, and the public verifier at zambo.dev/verify lets your counterparty run the check themselves. Proof you have to take someone's word for is not proof; proof they can recompute is.
Agent tool call proof
Proof is a property of the record, not the presenter. Agent tool call proof means evidence about a specific tool call that a skeptical receiver can check without trusting whoever presents it. In practice that is a verifiable receipt: tool name, recorded inputs, saved result, and a digest over that result, fixed at execution time. Anything weaker, a transcript excerpt, a success message, a timestamped log line in a file the presenter holds, is testimony. Testimony can be honest and still not be proof, because the receiver has no way to recompute any part of it.
The standard to hold is simple: if the receiver cannot independently reach the same answer from the artifact alone, it is not proof yet. Receipts are built to pass exactly that test.
Verify AI agent API calls happened
API calls are the easiest claims to fake and the easiest to fix. An agent that reports it called an API may have called a different endpoint, called with different arguments, received an error it summarized away, or not called at all. To verify AI agent API calls happened, match each claimed call to its verifiable receipt: the receipt records the call and fixes the saved result, so you can confirm the call ran and read what actually came back, including the errors the summary skipped. The hosted profile behind these receipts is described in the AI agent receipt API.
Where the work ran without receipts, the calls cannot be verified after the fact; the provider's own logs, if they exist, belong to the provider and carry the same holder problem as any log. Capture at execution time is the whole game.
Proof AI agent executed task
The ask behind the search: show me it ran, do not tell me it ran. Proof an AI agent executed a task is what a client, an auditor, or a teammate is asking for when they refuse to accept the agent's own summary as the evidence. They want an artifact they can check themselves, produced while the task ran, that does not depend on the agent or its operator telling the truth afterward.
That artifact is the task's set of verifiable receipts: one for each call the task made, each fixing the tool, the recorded inputs, and the saved result under a commitment made at execution time, with the run's workflow record binding the steps in order. Hand over the receipts and the check is mechanical: recompute each commitment, read each saved result, confirm the sequence accounts for the whole task. Screenshots of a dashboard, exported chat transcripts, and log files the presenter controls all fail this test the same way: nothing in them can be recomputed, so accepting them is just trusting the presenter with extra steps.
Zambo mints that receipt set automatically for work run through it, and the public verifier at zambo.dev/verify lets the receiver run the check without an account. Keep the claim narrow when you present it: the receipts prove the saved results were not changed since they were saved and show exactly what each call returned. Whether the task was the right task, and whether the results are good, remains a judgment the receiver makes against that checked record, which is exactly the ground proof is supposed to give them.
What is proof of agent work?
Proof of agent work is a record of a finished job that a skeptic can check without trusting the agent, its operator, or the summary either of them wrote. It names the steps that ran, fixes each step's saved result under a hash commitment made while the work ran, and binds the steps in order, so the checker recomputes the commitments and reads the results directly. Anything weaker, a log the operator can edit, a screenshot, a confident summary, is a claim, not proof. On Zambo the proof is the receipt set plus its workflow record, and it travels as one handover link.
Questions, answered
How do I get proof an AI agent executed a task?
Run the task where each call leaves a verifiable receipt, then hand over the receipts. Each receipt fixes the tool that ran, the recorded inputs, and the saved result under a hash commitment made at execution time, and the run's workflow record binds the steps in order. The receiver recomputes each commitment and reads the saved results, so the proof does not depend on trusting the agent or its operator. A receipt proves the saved result was not changed since it was saved.
Does proof of execution prove the task was done correctly?
No. Proof of execution proves the calls ran and the saved results were not changed since they were saved. Correctness is a separate judgment about whether the calls were the right ones and the results are good. Proof gives the judge a record that can be checked instead of a summary that has to be believed, and that record is what makes the correctness judgment possible at all.
What is proof of agent work?
A record of the job that a skeptic can recheck without trusting the agent or its operator: the steps that ran, each step's saved result fixed under a hash commitment made while the work ran, and the steps bound in order. The checker recomputes the commitments and reads the results. A log the operator can edit, a screenshot, or a summary is a claim. The receipt set and its workflow record are the proof.
What is AI agent proof of action?
AI agent proof of action is evidence that a specific action an agent claims ran really ran as recorded: the tool that ran, the time, the recorded inputs, and the saved result under a hash commitment computed at execution time, in a verifiable receipt anyone can recompute. A claim of action in a summary, or in a log the operator can edit, is not proof of action, because the reader cannot check it. The receipt proves the saved record was not changed since it was saved; it does not prove the action was the right one to take.
AI agent proof of action
The problem: an agent reports an action, and the report is the only evidence the action exists. It sent the email, ran the query, updated the record, made the call. AI agent proof of action is the standard the report has to meet before anyone relies on it: for each claimed action, a verifiable receipt fixed when the action ran, naming the tool, the time, the recorded inputs, and the saved result under a hash commitment computed over the recorded bytes. If an action has no receipt, it stays a claim, however confident the summary sounds.
Checking an action is mechanical. Match each claimed action to its receipt, recompute the commitment from the saved result, and read the saved result itself: the send, the write, and the purchase either appear in the record as they ran, or they do not. A receipt that fails its recompute, or an action with no receipt behind it, is reported as unverified, and the split between verified and claimed actions is the honest state of the job. The open format for these receipts is AER-1, published as IETF Internet-Draft draft-zambo-aer1-23. A receipt proves the saved record was not changed since it was saved; whether the action should have been taken at all is a separate judgment.
Proof of action cannot be reconstructed after a run that left no receipts, which is why the arrangement happens before the work. Run the job through Zambo at zambo.dev/mcp and every action returns with its receipt attached, multi-step jobs closing under one workflow record. For $0.99, a Day Pass covers 24 hours of calls with a receipt on every one. Ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.