How do I know if my AI agent really completed the task
The short answer. You know from the run's record: one verifiable receipt per step, in the order the steps ran, closed by a receipt whose root is computed over exactly those steps, plus the saved final result to compare against what you asked for. If a step is missing, its receipt is missing, and the count exposes it. If a result was changed after the run, its digest no longer recomputes. If steps were dropped or reordered after the fact, the closing root breaks. Completion stops being the agent's opinion and becomes a checklist anyone can run.
Why the summary cannot carry this. The agent's final message is written by the system whose work is in question, after the work is over, from whatever it remembers or chooses to report. A step that failed quietly, a step that was skipped, a partial result presented as the whole: all three fit comfortably inside the word done, and none of them leaves a trace in the message itself. The summary is a claim about the run. The receipts are the run, recorded as it happened, and a claim is exactly what a record exists to replace.
Scope, stated once and applied everywhere on this page: a verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows. The completion check proves the run in front of you is complete and intact; judging the work itself is done on the saved results, which the record hands you unaltered.
Completion is a property of the whole run
A single call is easy to check: one receipt, one digest. A task is a run of calls, and its failure modes live between the calls. Three of them account for most false completions:
- The skipped step. The agent planned five steps, ran four, and summarized all five. In a receipted run, the count is the tell: four receipts against five required steps, and the missing one has no record to point to.
- The failed step, quietly absorbed. A call errored, the agent moved on, and the final answer was built without it. The failed call still has a receipt, carrying its status and its saved result, so the failure sits in the record where the summary would have smoothed it over.
- The edited result. The run finished, then the output was adjusted before anyone reviewed it. The output digest was committed at execution time, so the edited bytes fail the recompute and the change is visible.
Notice what the closing receipt adds. Per-step receipts alone could, in principle, be presented selectively: show the good steps, omit the bad one. The closing root is computed over the ordered step receipt ids of the whole run, so the set itself is committed. Presenting a subset breaks the root, which is what turns a pile of receipts into a completion record. The whole-job receipt page covers that construction in full, and the audit trail page shows the same records read as a trail. When the completed run is picked up by a different agent, the whole record travels with it: can one AI agent hand work to another agent shows a real handover, accepted by the receiving agent with a receipt of its own.
The completion check, step by step
- List the run's receipts. Every step that executed has one, in order, each naming its tool, its recorded inputs, and its saved result.
- Count them against the task. The task defines the expected steps. A receipt for each one, with a success status or an honestly recorded failure, is the completeness test.
- Open the final receipt and recompute its output digest. Take the saved result bytes exactly as saved, hash them, compare. A match means the result you are reading is the result the run produced.
- Recompute the closing root. Hash each step receipt id, fold the leaves together in order, and compare with the root in the closing receipt. A match means the set is whole and in its original order.
- Read the saved results themselves. Only now judge the work, on the actual outputs, intact, with the provenance class on each receipt saying who ran or reported the call.
The public verifier at zambo.dev/verify runs the digest, commitment, provenance, and metadata checks in the open. The root recompute needs nothing but the step receipt ids and a SHA-256 function, which is the point: the strongest part of the check has no dependency on the system being checked. Whether the agent ran in Claude, ChatGPT, Gemini, Cursor, or Grok, the check is the same, because the record format is the same. The companion question, whether a single call ran at all, is covered in Did my AI agent actually run it? And when the checked work goes out to a client, the completion record doubles as the disclosure: how do I disclose AI use to a client without starting a dispute sends this same record, with the AI named per step.
The format underneath: AER-1
The receipts used in every section above follow one open format: AER-1, IETF Internet-Draft revision 23 (draft-zambo-aer1-23). AER-1 is an IETF Internet-Draft, not a finalized standard. It defines the per-step verifiable receipt and the workflow record that links receipts for a run, so a receipt produced in one place can be checked by a receiver somewhere else, with no account on the system that produced it and no cooperation from the operator who ran the agent.
To put receipts under your own agent's work: start with the live demo for a single checked call, then a Zambo Day Pass ($0.99, one time, no subscription) for a day of calls with a verifiable receipt under each one. The general method this page applies is laid out in Verify AI work: check the record, not the summary.
Questions, answered
How do I know if my AI agent really completed the task?
Check the run's record instead of the agent's summary. A completed task leaves one verifiable receipt per step, in order, closed by a receipt that folds the step receipts into a single Merkle root. Count the steps against what the task required, recompute the final result's digest and the root from the step receipt ids, and confirm the verify checks pass. If every step is present and the digests recompute, the run you are looking at is the run that happened, with its results intact.
What is the difference between my agent saying it is done and the task being complete?
The statement is the agent's own report, produced by the same system whose work is in question, and it can skip a failed or missing step without mentioning it. Completion is a property of the run's record: the ordered receipts for the steps that actually executed, the closing receipt over the set, and the saved final result. The statement asks you to believe the agent; the record lets you count the steps and recompute the digests yourself.
What if one step of the task failed or never ran?
Then the record shows it. A step that ran and failed carries its own receipt with its failure status and its saved result. A step that never ran has no receipt, and when you count the run's receipts against the steps the task required, the gap is visible instead of silent. A summary can smooth both cases into the word done; the receipt set cannot, because the closing root is computed over exactly the steps that are there.
Can an agent fake a completion record?
Not after the fact. Each receipt is minted by the executing system at execution time, and its digests are committed in the record at that moment. Editing a saved result later breaks its output digest, and dropping or reordering a step breaks the closing root, so a record that recomputes clean is the record that was made during the run. The provenance class on each receipt also states who ran or reported the call, so the record names who stands behind it.
Does a completion check prove the result was right?
No, and it does not claim to. The check proves the saved result was not changed since it was saved, that every step in the record is the step that ran, and that the final result you are reading is the one the run produced. Whether the work was good is a judgment you make on the actual saved results, which is exactly what the record gives you: the real outputs, intact, instead of a summary of them.