The AI agent execution certificate: a record a stranger can check.

An AI agent execution certificate is a verifiable record of agent work that was fixed when the work ran: it names the tool, carries the saved result, and commits to that result under a digest any receiver can recompute. Zambo is the verifiable work layer for AI, and this page defines the term by the only test that matters: hand the artifact to a stranger with no account and no context, and see whether they can reach a verdict alone. A receipt proves the saved result was not changed since it was saved. That narrow check is what a real certificate is.

Worked example: an execution certificate, checked end to end

Receipt e7ca2113-1246-4969-9281-c6dccc21d031 records a live_price call made on October 15, 2026 at 21:33:40 UTC, provenance class EXECUTED BY ZAMBO. Its saved result reads BTC $82,246.00 USD, up 0.48% in 24 hours. Its output digest is sha256:2db65287e1313b6378f9b74f0b7fb85b357183a04ec3ecfb1a28766922205e9b. The public verify endpoint recomputes the digest from the saved bytes and reports the commitment check as a pass, expected hash equal to computed hash. You can rerun the same check at the public verifier and reach the same answer, without an account and without asking whoever ran the call.

Notice what the check does not do. It does not judge whether the price was a good price or live_price was the right tool. It shows you the saved result, intact, so your judgment runs on the actual record instead of on a summary of it.

Try it on a fresh call: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 15, 2026. Updated October 17, 2026. Written against AER-1, IETF Internet-Draft revision 23: draft-zambo-aer1-23. AER-1 is an IETF Internet-Draft, not a finalized standard.

AI agent execution certificate

What the word usually means, and why it fails. Most things called execution certificates are documents: a PDF, a badge on a dashboard, a signed letter from the platform that ran the work. Every one of them asks the receiver to trust the issuer, because nothing in the document can be recomputed. The issuer can regenerate it, amend it, or issue one for work that never ran, and the document looks the same either way. A certificate whose force depends on believing its issuer is a claim with letterhead.

What the word means here. In the AER-1 sense, the certificate is the verifiable execution receipt itself: minted at execution time by the system that ran the call, carrying the saved result and a SHA-256 digest over that result, at a public URL. The receiver's check is mechanical: recompute the digest, compare, read the saved result. The issuer's honesty stops mattering, because the verdict comes from the bytes. If an artifact cannot pass that test, call it what it is: a report.

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.

AI agent execution attestation

Attestation is a statement; a receipt is a record. An AI agent execution attestation is a party's assertion that work was executed: the platform, the operator, or the agent itself states that a call ran and produced a result. Attestations are not worthless; they assign responsibility, and a named attester can be held to their statement. But an attestation's force ends at the attester's credibility. Nothing in the statement lets a receiver recompute anything, so a false or careless attestation is indistinguishable from a true one.

How the two fit together. AER-1 receipts carry a provenance class, the label that says who ran or reported the action, which is where attestation belongs: as a declared, checkable part of the record, bound to the result it describes, not as a substitute for the record. Ask for both. The attestation tells you who stands behind the work; the receipt lets you check the work itself.

Machine-verifiable agent execution

Built for a checker that is also a program. Machine-verifiable agent execution means the verification of an agent's work can be performed by software, end to end, with no human judgment in the loop: fetch the receipt, decode the saved result, recompute the digest, compare, done. This matters because the receivers of agent work are increasingly agents themselves: a second agent deciding whether to build on the first agent's output cannot read a PDF or weigh a vendor's reputation. It needs fields, bytes, and a digest.

That is why the format is a published schema with a conformance kit, not a web page design: any implementation can mint receipts and any program can check them, in any language, offline from the record itself. The verification that ran on the worked example above is an API call and a hash, nothing more.

Verifiable task completion for AI agents

Completion is a property of the whole job, not the last message. Verifiable task completion for AI agents means a finished task resolves to records that check out at every level: each step's verifiable receipt recomputes, and the workflow record at close accounts for the steps in order, so a step added, dropped, or swapped after the fact breaks the check. An agent's final message saying the task is complete is, on its own, the weakest artifact in the system: it is written last, by the party being checked, from its own account of the run.

The practical rule follows directly: accept completion from the record, not from the report. If the task's receipts and workflow record verify, the task is complete in the only sense a receiver can confirm. If they do not exist, the task is reported complete, which is a different and lesser thing. The whole-job receipt covers the workflow-level record in full.

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 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

What is an AI agent execution certificate?

In the AER-1 sense, it is the verifiable execution receipt itself: a record minted at execution time that names the tool, fixes the saved result under a SHA-256 digest, and can be recomputed by any receiver. It is not a PDF, a badge, or a letter from the vendor. If the artifact cannot be recomputed by a stranger, it is a certificate in name only.

What does an execution certificate prove?

It proves the saved result was not changed since it was saved, and it lets anyone read that saved result and recompute its digest. It does not prove the result was correct, and it does not prove an external event happened beyond what the record itself shows.

How do I check an AI agent execution certificate?

Open the receipt, take the saved result bytes exactly as they are saved, recompute the SHA-256 digest over those bytes, and compare it with the digest in the receipt. A match means the saved result is intact. The public verifier at zambo.dev/verify runs the same check in the open, free, with no account.

Is an execution certificate the same as an attestation?

No. An attestation is a statement by a party: someone asserts the work happened. A verifiable execution certificate is a record a receiver recomputes, so its force does not depend on believing the attester. Attestations can accompany a receipt, as its provenance class, but they cannot substitute for the recompute.

Related