Direct answer
Verifiable AI agent execution: the work, and the proof it happened
An AI agent finishes a job and reports success in its own words. That report is the weakest evidence there is: the same system that did the work grades it, and the record it points to, a log, a trace, a screenshot, was written by the runner and can be edited by the runner. Verifiable execution closes that gap. Every job leaves a record as it runs, the record carries a receipt, and anyone holding the receipt can check afterwards whether the saved result is still the result the job left. This page defines the term plainly, shows why the usual substitutes do not settle the question, and sets out the four checks to run on any platform, including this one, before trusting its execution claims.
Updated November 2, 2026. First published November 2, 2026. The two work records quoted below are real and public, with their states read back from the live service on November 2, 2026.
What verifiable execution actually means
Three properties, and a system missing any of them is asking for trust instead of offering proof. First, the record is made as the work runs: each job, and each step inside a job, is saved when it happens, with the tool that ran and the result as saved, not reconstructed later from a chat transcript. Second, the record carries a receipt: a compact check value bound to the saved result, issued with the job rather than written about it afterwards. Third, the check is independent: a person or a program that had nothing to do with the run can take the receipt later, recompute the record, and get a plain answer, the saved result matches, or it does not. Verifiable execution is the combination. A platform can have beautiful logs and still fail the third property, because the checking never leaves the house.
Why logs, traces, and screenshots do not settle it
Each substitute fails in its own way. A log is a text the runner writes about itself: it can be trimmed when it grows, edited when it embarrasses, and lost when the session ends, and none of that shows from inside the log. A trace is richer, but it lives inside one platform's own tooling and answers to that platform; the reader sees what the platform's viewer renders, and the viewer and the runner share an owner. A screenshot shows a screen at one moment, proves a pixel pattern existed, and says nothing about which job produced it or what the result was an hour later. None of the three gives an outsider a test they can run themselves. The question to ask of any of them is short: hand me the record and let me check it without asking your system whether it is true. A receipt is built to survive exactly that request.
The evaluation checklist: four things to check
1. A receipt per job, issued as the work runs
Not a summary, not an export, not a weekly report. Each job returns its own receipt at the moment it completes, naming the tool and bound to the result as saved. If the evidence is assembled later, by anyone, it is a story about the work rather than a record of it.
2. An independent verify path
The checker must be separable from the runner. Look for a public verify page where anyone holding a receipt link can run the check, and for offline verification that does not phone the platform at all. A check that only the vendor can perform, inside the vendor's dashboard, is the vendor grading itself with extra steps.
3. A published standard for the record
The format of the record should be a public document anyone can read, implement, and argue with, so the receipt does not depend on one company's private schema staying stable or staying honest. AER-1 is published as an IETF Internet-Draft, draft-zambo-aer1-26, where implementers who owe the format nothing can build against it and publish what they find.
4. A public conformance corpus
A standard on paper still leaves room for two readers to read the same record differently. A conformance corpus closes that room: a fixed set of test vectors with known outcomes, so any implementation can prove it reads records the same way the reference does, including the records designed to fail. The AER-1 corpus is public at https://zambo.dev/aer1/corpus.json and carries 126 vectors and 129 checks.
How Zambo runs it
Zambo is the verifiable work layer for AI: one MCP endpoint, https://zambo.dev/mcp, serving 153 tools with 36 on the default surface, and every call returns a verifiable receipt under AER-1. The receipt opens at zambo.dev/run/ followed by its ID, and the check runs at https://zambo.dev/verify/, in the open, for anyone holding the link. The wrap-up call seals a session of this work into a handover, so a whole job, its steps, its receipts, and its decision state travel as one record. The two public records below show the states that record can carry:
Accepted: the decision is on the record
- Status: accepted, decided_by client, decided_at 2026-10-16T14:31:51.146Z, release_hint ok_to_release.
- Steps: 4 steps total, 4 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
Pending: checked, and still waiting on a decision
- Status: pending, release_hint hold.
- Steps: 5 steps total, 5 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
Run a first job and check it yourself before believing any of this page. 20 calls + 1 wrap-up free every day. Picking up in another AI is always free. For $0.99, a Day Pass makes the endpoint unlimited for 24 hours, no subscription: https://zambo.dev/day-pass/. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders.
What a record does not settle
A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the answer was right, the work was good, or the agent chose the right tool. Verification settles the history of the record so that judgment, yours, the client's, another AI's, can rest on a record that is not quietly moving. This page is general information, not legal advice.
Frequently asked questions
What is verifiable AI agent execution?
It is execution where every job leaves a record that a third party can check after the fact. The record is saved as the work runs, names the tool and the result as saved, and carries a receipt the checker tests independently: if the saved result changed after it was saved, the check fails. In Zambo, work run through https://zambo.dev/mcp returns a verifiable receipt on every call under AER-1, IETF Internet-Draft draft-zambo-aer1-26, each receipt opens at zambo.dev/run/ followed by its ID, and anyone can run the check at https://zambo.dev/verify/.
How is a receipt different from a log or a trace?
A log is written by the same system that did the work, and the system that wrote it can edit it, trim it, or lose it. A trace is the operator's own view inside one platform, and it shows what that platform says happened. A receipt is saved with the result itself, and the later check tests the saved record: the checker recomputes the record and compares, so a result changed after saving fails the check no matter who presents it. The difference is who the evidence answers to. A log answers to the agent. A receipt answers to anyone holding it.
What does the check actually prove?
It proves the saved result was not changed since it was saved. That is the whole claim, and it is the claim that matters when a client, a teammate, or another AI asks whether the record in front of them is the record the job actually left. It does not prove the answer was right or the work was good; judgment about quality still belongs to the reader. A receipt settles the history of the record, so the argument can be about the work itself instead of about whose copy of the work is real.
What should I check before trusting a platform's execution claims?
Four things. One: a receipt per job, issued as the work runs, not a summary written afterwards. Two: an independent verify path, a public page where anyone holding the receipt can run the check, with the checker separate from the agent that did the work. Three: a published standard for the record format, a public document anyone can read, implement, and criticize. Four: a public conformance corpus of fixed test vectors, so independent implementations can prove they read the same record the same way. AER-1, draft-zambo-aer1-26, publishes its corpus at https://zambo.dev/aer1/corpus.json with 126 vectors and 129 checks.
What does it cost to run work this way?
The free tier is 20 calls + 1 wrap-up free every day; picking up in another AI is always free, so checking and continuing work never tolls the receiving side. For $0.99, a Day Pass makes the endpoint, https://zambo.dev/mcp, unlimited for 24 hours, no subscription: get the Day Pass. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.