What is AI agent verification?

The agent says the work is done. Verification is how you find out whether that is true, without taking the agent's word for it. It is a check on the finished work, run against a record saved while the work ran, by someone other than the agent that did it. This page defines it, separates it from the identity checks it gets confused with, and shows a real check, including the part where the record argues with itself.

Run a check yourself: paste any receipt into the verifier and watch it recompute, free, no signup.

Published October 19, 2026. Updated October 19, 2026. Written against draft-zambo-aer1-23.

The definition

The short answer

AI agent verification is checking that an AI agent's finished work matches the record saved while it ran. Each step of the job was preserved as a verifiable receipt at run time, and the checker, who is not the agent that did the work, recomputes the record and compares: the saved bytes against their commitments, the steps in order, the gaps named instead of hidden. It answers one question: did the agent do what it says it did, and can you show me?

Two senses of the term, and they are not interchangeable

Identity verification: who is this agent?

Credentials, authentication, authorization, know-your-agent programs: checks on the agent itself, run before or while it acts. Necessary, and a whole industry sells it. It can tell you an agent is exactly who it claims to be. It cannot tell you the agent did the job.

Work verification: what did this agent do?

A check on a finished job, run against its record. This is the sense this page owns, the sense a client means when they ask you to prove a delivery, and the sense an operator means at 2am reading what the overnight run actually did. A fully identified, fully authorized agent can still do the wrong work, half the work, or no work at all, and only work verification will ever say so.

What the check actually checks

  1. The record exists and resolves. The job's receipts sit at public links anyone can open, not inside the doer's console.
  2. The bytes match the commitments. Each step's saved result recomputes to the SHA-256 hash committed when the step ran, under AER-1, an open IETF Internet-Draft (draft-zambo-aer1-23). One changed byte and the step fails, out loud.
  3. The set is complete. Steps in order, the whole job present, and anything nobody checked named as not checked, in the record, instead of quietly missing.
  4. Failures are still there. Failed and refused steps recorded the same way as successful ones. A record with the failures edited out is not a verified record; it is a brochure.
  5. The decision is the receiver's. Accept or flag, recorded by whoever received the work. The agent that did the work cannot accept its own delivery; the system refuses it.

A check that can say no: a real record, checked

Verification that always passes is a rubber stamp, so judge the idea by a record that argues with itself. An outside agent studio wired AER-1 receipts into its deliveries; one public record is receipt 28c79cde. The byte check passes: 2,078 bytes of saved record recompute to exactly the committed output hash, sha256:5f06acfb. And on the same record, the studio's own audit flags three of its claims as having no supporting evidence above weak, and reports issuer authentication as not checked. Both facts travel together, in public, for anyone to recompute.

That combination is the point. The commitment check proves the record was not changed after the fact. The claims audit then judges what the record actually supports, and in this case it declines to support some of it. A check that cannot fail proves nothing; this one fails parts of its own delivery record and publishes the failure.

Honest limits: verification proves the saved record was not changed since it was saved, and shows what the record supports. It does not prove the work was correct, complete, or wise, and it does not prove who produced it. Judgment stays human. Verification gives the judgment a record that cannot quietly change underneath it.

Verification, monitoring, audit trail: the three are a set

Monitoring watches the agent while it runs: health, spend, errors. The audit trail is the ordered record the run leaves behind. Verification is the act of checking finished work against that record, afterward, by someone with no stake in the answer. Teams buy the first and believe they own all three. The gap stays invisible until the day a client, an auditor, or a dispute asks the only question verification answers, and a dashboard screenshot is what they have.

Producing the record is the setup, and it is small: work run through Zambo's 153 tools mints the receipt per step automatically, an independent outside validator will check any AER-1 receipt keylessly, and checking is free for whoever holds the link. On a normal day the free tier carries it; a $0.99 Day Pass covers a heavy day of the full machine, and the $29 Pass ($19 for $ZAMBO holders, $290 for the year) fits agents whose work gets checked daily. Wear the result: the Verified with AER-1 badge is how services show their deliveries ship with receipts attached.

Questions, answered

What is AI agent verification?

AI agent verification is checking that an AI agent's finished work matches the record saved while it ran. Each step of the job was preserved as a verifiable receipt at run time, and the checker, who is not the agent that did the work, recomputes the record and compares: the saved bytes against their commitments, the steps in order, the gaps named instead of hidden. It answers one question: did the agent do what it says it did, and can you show me?

Is AI agent verification the same as verifying an agent's identity?

No. Identity verification asks who an agent is and whether it is authorized: credentials, authentication, know-your-agent checks. Work verification asks what an agent did and whether the record of it holds up. A perfectly identified agent can still do the wrong work, half the work, or no work, and identity checks will never tell you. The two disciplines solve different problems; if your question is about a finished job, you need the second one.

What does verifying an AI agent's work actually check?

Five things: that the job's record exists and resolves at its public link; that each step's saved bytes recompute to the hash commitment made when the step ran, so nothing was edited afterward; that the steps are complete and in order, with any unchecked work named as not checked rather than silently absent; that failed and refused steps are present in the record, not removed; and that the receiver's decision, accept or flag, was recorded by the receiver and not by the agent that did the work.

Who can verify AI agent work?

Anyone holding the receipt link: the client the work was done for, an auditor, the next agent picking the job up, or you at 2am wondering what your agent did overnight. The check needs no account on the system that produced the record and no trust in its operator, because it recomputes the record itself. Independent implementations run the same check: a public keyless validator maintained by an outside lab will verify an AER-1 receipt for anyone who asks.

How do I start verifying my AI agents' work?

Start before the work runs, because verification cannot be retrofitted: there has to be a record saved at run time to check. Run the work through a layer that mints a verifiable receipt per step, the way Zambo does for every call through its MCP endpoint, then check receipts as work lands: open the link, recompute, read the gaps. Checking is free and takes seconds per receipt. The setup is one connection, made once, not a logging project your team maintains.