Finished is not proven
Your agent says "done." That is the end of its story, not the end of verification. A completion message is a status report, not evidence. Agents produce fluent, confident summaries of work that was never performed: plans narrated as completed actions, generic success statuses taken at face value, real work done in the wrong file or the wrong session. The summary looks identical in every case.
So stop asking whether the agent finished. Ask what can be proven: for each thing it claims to have done, is there an execution-time record from the layer that ran it? That record is a verifiable execution receipt. No receipt, no proof. It is that mechanical.
The honest limit
A receipt proves the saved result was not changed. It does not prove the model was right, the tool was the right one, or the strategy was sound. Proof of execution is the foundation. Judgment about quality sits on top of it, and it is still your job.
The 4-step procedure
No judgment calls, no reading the agent's tone, no trusting the summary. Follow these steps in order and you will know, with evidence, whether the work happened.
- Collect the claims. Write down every concrete thing the agent says it did. "I updated the file" is a claim. "I sent the email" is a claim. Vague statements like "everything is handled" are filler, not claims. Ignore filler.
- Demand the execution record for each claim. For every claim, ask for the timestamped record from the execution layer: which tool ran, what inputs it received, what it returned. That record is the verifiable receipt for the action. The open format is AER-1, an IETF Internet-Draft (draft-zambo-aer1-23), and every zambo receipt carries a public URL at
zambo.dev/run/<id>that anyone can check. - Confirm real-world change. Pick the claims that matter most and check them yourself. Open the file. Look at the sent folder. Query the record. A receipt plus a matching real-world change is proof. A receipt alone is a strong lead. A claim alone is nothing.
- Count what is missing. Every claim without a matching receipt is unproven. The gap between "claims made" and "claims proven" is the exact size of the problem. Done claims minus verified claims tells you precisely how much of the summary was story and how much was work.
This works because it never asks you to judge the agent's honesty. You only match claims against evidence the agent did not write.
Claims vs. evidence: what actually counts
| Your agent says | What that proves | What would actually prove it |
|---|---|---|
| "I analyzed the data." | Nothing on its own. | A receipt showing which analysis tool ran, on which data, at what time, plus the output it produced. |
| "I sent the email." | Intent, at best. | A sent-message record with timestamp, recipient, and content you can confirm in the sent folder. |
| "I updated the file." | A plan, not an action. | The file itself, with a modification time matching when the agent claimed to act, plus the receipt for the write call. |
| "The task is complete." | The agent believes it is finished. | Every sub-claim above, checked individually. Completion is a conclusion, not evidence. |
What does not count as proof
Most of what passes for agent accountability today is the agent vouching for itself:
- A chat summary. The agent wrote it. It could be wrong, incomplete, or invented, and nothing in the message lets you tell.
- Screenshots or exported logs. Logs are written by the same system being audited. Editing a log after the fact is trivial, and there is no way to detect it.
- A completion badge. "Task completed successfully" is a status string, not evidence. It attests to nothing checkable.
The common thread: every one of these requires you to trust the party whose work you are trying to verify. Proof must survive distrust, or it is not proof.
What proof looks like: a verifiable receipt
A verifiable receipt is a record captured at execution time for one unit of agent work, with four properties:
- Captured when it happened. The record is generated as the tool executes, not reconstructed later from a summary.
- Bound to the exact bytes. The receipt carries the canonical bytes of what the tool returned and a SHA-256 commitment over them. Anyone can recompute the hash and confirm the stored result was not changed.
- Checkable without the agent's help. A third party verifies it with public information only. No account, no API key, no asking the agent to confirm its own story.
- Edits show. Any edit after the fact breaks verification. The record either checks out or it does not; there is no middle ground.
Example: zambo.dev/run/588f5158-e335-4ba8-9009-72fad8410d55 is a real receipt for one call. Open it and recompute its digest to check the saved result was not changed since it was saved.
Try it live: zambo.dev/verify checks a receipt right now, no signup.
The one-minute check
When an agent hands you work, ask for the receipt, then:
- Open the receipt and find the output commitment (a
sha256:digest). - Take the canonical bytes the receipt carries and hash them yourself, or paste the receipt into a public verifier.
- If the digest matches, the result you are looking at is the result the tool actually returned. If it does not, something was edited after the fact.
For how this check fits with transcripts, logs and traces, see AI agent record verification: transcripts, logs, traces and run history.
If you buy or manage agent work
Make receipts a condition of payment, not a post-incident investigation tool. The contract language is simple: every unit of billed agent work ships with a verifiable receipt; payment clears when the receipts verify. Freelancers, agencies, and internal teams can all comply with the same open format, which means your check does not depend on any one vendor's dashboard.
The agents worth paying are the ones that can prove what they did. Ask for the proof before you pay, and the market sorts itself out.
My AI agent claims it finished but nothing happened
This is the most common agent failure there is, and it is usually not malice. The final message is a summary the agent wrote about its own work. A step it planned gets narrated as a step it ran, a tool call that errored gets smoothed into a success, or the call never happened at all. The summary cannot tell you which of those you are holding. Only evidence that lives outside the summary can.
Work it claim by claim. For each thing the agent says it did, ask for the verifiable receipt for that call: a record captured when the tool ran, bound to the exact inputs it received and the exact output it returned. Then do the readback: open the place the work was supposed to change, the record, the file, the sent folder, the database row, and compare it against what the receipt says came back. Receipt present and state matches: that step happened. No receipt, or the state disagrees: that step is unproven, whatever the summary says. The readback half of this check is worked end to end in Your AI Agent Said 'Done.' The Database Disagrees.
Keep the claim narrow, because narrow is what makes it checkable. A receipt proves the saved result was not changed since it was saved; it does not prove the agent chose the right action. But when the claim is a finish that never happened, the open question is not judgment, it is existence, and existence is exactly what the receipt plus the readback settle. See it happen: the live demo mints a real receipt in about 10 seconds, no signup. To keep every run covered instead of checking after the fact, a Day Pass keeps receipts on for the day.
How to prove AI agent did the work
The situation: someone asks you to prove it, and the chat log is all you have. A client, a manager, or your own future self wants evidence the agent did the work, and a summary the agent wrote about itself is not evidence. How to prove AI agent did the work comes down to one move: stop presenting the report and start presenting records the other side can check without trusting you or the agent.
Take the agent's report claim by claim. For each claim, produce the verifiable receipt for the call behind it and walk the checker through the recompute: the commitment fixed at execution time, the saved result, the match. Then close the loop with a readback on the claims that matter: open the file, the record, the sent folder, and show the state matches what the receipt saved. A claim with a receipt and a matching readback is proven. A claim with neither is a claim, and saying so plainly is what makes the proven ones believable.
Proof like this has to be captured while the work runs, which is why it is a setup decision, not a writing task. Work routed through Zambo leaves a verifiable receipt for every call, so the proof packet assembles itself: the receipts, in order, under the job's workflow record. If the problem is that you keep reaching the end of a job with nothing to show a skeptic, a $0.99 Day Pass keeps receipts on for 24 hours of work, so the next delivery arrives with its proof attached. The claim stays narrow: a receipt proves the saved result was not changed since it was saved. It does not prove the agent chose well, and a careful checker will still judge the work itself, against the record.
AI agent did not do what I asked proof
A different failure: the agent worked, just not on what you asked. The file it edited is the wrong file, the email went to the wrong person, the query it ran answers a question you did not pose. The summary reads like success because the agent believes it followed the brief. When an AI agent did not do what I asked, proof means lining up three records side by side: what you asked, what the call was actually given, and what came back.
A verifiable receipt is what makes that comparison possible, because it fixes the exact inputs the call received and the exact output it returned at execution time. If the recorded inputs differ from your instruction, the agent changed the job on the way in, and the receipt shows where. If the inputs match your instruction and the output still misses it, the failure sits in the call itself. If there is no receipt, there is no comparison to run: you have your memory of the ask and the agent's account of the work, and neither one can be recomputed.
Run the comparison before you argue about intent. Most of these cases are drift, not defiance: a vague instruction, a default the agent filled in, a similar name it picked. The receipt does not care which it was, and that is the point. It proves the saved result was not changed since it was saved, so the inputs and outputs you are comparing are the ones that actually moved through the call.
Frequently asked questions
How do I know if my AI agent finished the task?
Don't rely on its summary. Run the 4-step procedure above: collect the claims, demand a receipt for each, confirm real-world change on the important ones, count what's missing. You will know in minutes, with evidence.
Can AI agents provide proof of work?
Yes, when the execution layer mints a verifiable receipt per tool call. AER-1 is the open format; it records which tool ran, what went in, what came back, and when, bound by a commitment anyone can recompute.
What if the agent's claim has no receipt?
Then it is unproven, full stop. The fix is structural, not rhetorical: route the agent's calls through an execution layer that mints receipts. zambo.dev/mcp wires one into your agent today: one paste of the endpoint, no key.
Does a receipt prove the agent did the right thing?
No. It proves the action ran and the saved result was not changed. Whether the action was the right one is a judgment call that stays with you. Receipts give you the ground truth to make it.
How to prove AI agent did the work?
Break the agent's report into individual claims and require a verifiable receipt for each one. For every claim, open the receipt, recompute the hash commitment over the saved result, and read the saved result; then check the claims that matter against live state, the file, the record, the sent folder. Claims with a matching receipt and matching state are proven. Claims without a receipt are unproven, whatever the summary says. A receipt proves the saved result was not changed since it was saved, not that the agent chose the right action.
What proof settles it when an AI agent did not do what I asked?
Compare three things: your instruction, the inputs recorded on the call's verifiable receipt, and the output the receipt saved. If the recorded inputs differ from what you asked, the agent changed the job. If the inputs match and the output misses the instruction, the failure sits with the call. If there is no receipt, there is no proof either way, only the agent's account of its own work. The receipt proves the saved result was not changed since it was saved, so the comparison runs on the record as it was saved, and any later edit shows up as a failed recompute.