Execution evidence
How do you prove an AI agent did the work?
Last updated: 2026-09-29
Start with the execution boundary, not the agent's final sentence. A useful record says what was attempted, what ran, what was observed, and what still needs confirmation.
Try the Zambo demo · Explore Zambo
Ask for a stable receipt, inspect the tool and timestamp, retrieve the exact committed bytes, recompute SHA-256, and check the owning system for the outside outcome. A receipt is evidence of a recorded execution, not a universal proof of success.
Four states that should not be confused
The agent proposed an action. No execution is established.
The agent or another system said an action happened. This is a claim awaiting evidence.
A tool crossed the execution boundary and the system recorded its result or failure.
A real read-back, callback, delivery event, or settlement independently bound the outside effect to the record.
Use an individual execution receipt
An AER-1 execution receipt identifies one tool call, its time, scope, provenance, schema, and output commitment. Open the public receipt URL and verify that its identifier matches the action under review. Inspect whether the provenance says executed, observed via a gateway, or logged from an external report.
Hash verification requires the exact canonical bytes, not a reserialized approximation. Decode the bytes, compute the declared SHA-256 digest, and compare it with the receipt's output hash. Check the result status and any evidence source separately. A matching digest establishes that the stored bytes match the commitment. It does not establish that an external provider was correct.
Use a workflow receipt for multi-step work
A workflow receipt binds the ordered hashes of its individual step receipts through a Merkle root. Fetch every step, verify each receipt, confirm the sequence is complete, and recompute the root. A valid root shows that the listed commitments and their order agree with the workflow manifest. It does not prove that the goal was achieved or that an outside side effect persisted.
Live workflow example
Inspect workflow 42a3c2cf-2cdd-5b8a-aced-016e5a2fb634 at its public receipt page. The page provides five ordered steps, links to each step receipt, and a published Merkle root. Use its Verify control or independently fetch each step's verification endpoint, compare the output hashes, and recompute the root. Treat the resulting integrity check separately from any claim about the workflow's real-world outcome.
When no receipt is available
- Say that execution evidence is unavailable instead of inferring completion.
- Search the owning system for request IDs, audit logs, approval records, delivery callbacks, and post-action read-back.
- Label each source as executed, observed, or reported and preserve its original timestamp.
- Record a new verification event for a retry. Do not rewrite history to make a later retry look like the original action.
Verification limits
Receipts can be incomplete, stale, redacted, unavailable, or scoped to only one tool call. A valid hash does not prove intent, truth of input, quality of output, authorization, payment settlement, or an external side effect. Reviewers should preserve these unknowns and ask the system that owns the outcome for confirmation.
Open the receipt verifier · View pricing · Install the MCP connection