Check an AI Agent's Work Without Redoing It: Read the Record, Not the Job

The short answer

Read the run, do not repeat it

Every check on this page is a reading task. Split the output into the claims it makes. For each claim that matters, find the recorded step behind it: the tool that ran, the inputs it was given, the saved result that came back. Recompute that step's verifiable receipt and compare. Then count the steps in the record against the shape of the job you asked for. Claims that trace to steps are checked. The slice of the job with no step underneath it is the only slice that ever needs redoing, and it is usually small.

Why redoing feels safe, and what it costs

Redoing is the default check because it needs no setup: you just do the job again and compare. It has three costs that compound quietly:

It doubles the price of delegation. A two hour research run costs two more hours to redo. At any real volume, checking by redoing costs as much as the work itself, so the agent saved you nothing.
It does not scale past you. You can redo one job. You cannot redo the forty jobs your agents ran this week, so most of them go unchecked, which is worse than a fast check on all of them.
It checks the wrong thing. Your redo produces a second answer, not evidence about the first one. When the two answers disagree, you have a tie, not a verdict. The record breaks the tie: it shows what the first run actually did.

The alternative is not trust. It is a cheaper check aimed at the evidence: the record of calls the run left behind it.

The record check, in four moves

Split the output into claims. List the load bearing claims: the numbers, the named sources, the findings the rest of the output stands on. Most outputs rest on three to six. Sentences that would not change your decision if wrong do not need checking.
Map each claim to its recorded call. Open the job record and find, for each claim, the step whose saved result the claim rests on. A grounded claim resolves to a step with a tool, inputs, and output bytes. A claim that resolves to nothing was assembled at writing time.
Recompute the receipts on the steps that matter. Each step carries a verifiable receipt: the exact saved bytes and their SHA-256 digest, in the open AER-1 format (draft-zambo-aer1-26). Recompute the digest, or run the receipt through zambo.dev/verify. A match means the saved result you are reading is the result the run produced, unchanged since it was saved. One real receipt, opened and readable: zambo.dev/run/ef28b4c2.
Count the steps against the job's shape. Coverage is the check summaries cannot fake. A job that required reading forty sources should show forty source steps. A comparison of five products should show five product reads. If the count is short, the missing slice is named by the gap, and only that slice needs a rerun.

Four moves, all reading. The step by step flow for the receipt recompute itself lives on how to verify AI work.

A worked example: the forty source report

What redoing would cost

You asked for a market scan across forty sources. The agent returns a tidy report in twenty minutes. Redoing the scan yourself is most of a day, so the practical choices look like: trust it, or burn the day. Neither is a check.

What the record check costs

Open the job record. Count the source steps: forty fetches, or six. Read the saved result behind the three claims the report's conclusion stands on, and recompute their receipts. Spot check two more sources at random against their saved bytes. If the count is forty and the receipts recompute, the report is checked, in the time a coffee takes. If the count is six, you have learned something no summary would have told you, and the rerun is scoped to the thirty four sources that were never read.

The check did not repeat the job. It read the job's own record, which is the only place the truth about the run lives.

When a step is missing

A missing step is a precise finding, not a general suspicion. It tells you which claim has nothing underneath it, or which slice of the coverage never ran. Redo exactly that slice, or send it back with the gap named: the record gives you the words ("sources 12 through 40 have no steps in the record") that a vague feeling of doubt never could. And when the pattern repeats, the fix is structural: run the work through a record layer so the next job arrives checkable. The failure mode this prevents, an agent reporting completion for work that never ran, is measured on AI agent lying about done.

Run the work so it can be checked

Route the calls through a record layer. Point your agent at the Zambo MCP endpoint, https://zambo.dev/mcp. It works with the agent you already run: Claude, ChatGPT, Gemini, Cursor, Grok, and other MCP clients. Setup is one step at zambo.dev/add.
Let the receipts accumulate. Every call through the endpoint leaves a verifiable AER-1 receipt as it runs, including calls that fail or get refused, gathered under the job in order. Zambo is the verifiable work layer for AI: 153 tools behind the one endpoint, 20 free calls per day, then they upgrade, a $0.99 Day Pass for 24 hours, or the Zambo Pass at $29 for 30 days, one payment.
Check the record, hand it over with the output. Run the four moves on the claims that matter. When the output goes to a client or a teammate, send the record with it, closed as one link with HANDOVER, so they can run the same check instead of redoing your job or taking your word. Where the trail lives and why placement matters is on the agent audit trail page.

The fixed target underneath the check

A checking method is only as good as the format it checks against, which is why the receipts follow an open, published one. AER-1 (draft-zambo-aer1-26) ships with a public conformance corpus of 126 vectors and 129 checks, kit v1.5.7, published at zambo.dev/aer1/corpus.json and archived on Zenodo under DOI 10.5281/zenodo.23677115. Any verifier can run the same vectors and get comparable results, because the inputs and expected outcomes were fixed in advance. The receipt you recompute at home and the receipt a stranger recomputes are the same check, which is what makes the trust transferable instead of personal.

What the check settles, and what it never settles

It settles whether the work ran, whether the claims rest on the results the run actually produced, and whether the record was adjusted after the fact. It does not settle whether the agent chose well or reasoned fairly. Stated exactly: a verifiable receipt proves the saved result was not changed since it was saved, not that the result was right. What the record removes is the need to redo the job to find out what happened in it. The judgment stays yours. The archaeology goes away.

Questions, answered

How do I check an AI agent's work without redoing it myself?

Check the record the run left, not the job itself. Split the output into its load bearing claims, map each claim to the recorded tool call behind it, recompute the verifiable receipt on the saved result for the claims that matter, and count the steps in the record against the shape of the job you asked for. A claim that traces to a saved result whose receipt recomputes is checked. A claim with no step underneath it is the only part that needs redoing, and only that part.

If I cannot check everything, what do I check first?

The load bearing claims and the coverage count. Check the three to six claims the rest of the output stands on: the numbers, the named sources, the statements the decision depends on. Then count steps against the job's shape: a job that required visiting forty sources should show forty source steps, whatever the summary says. Those two checks catch the two common failures, invented specifics and skipped work, in minutes.

Can I check work from an agent that kept no record?

Not after the fact. With no record there is nothing to check against: the summary is the only artifact, and the summary is the thing in question. Your options are to redo the work, or to rerun it through a record layer so the next run can be checked. Route the calls through an endpoint that leaves a verifiable receipt for every call, and checking becomes a reading task instead of a second job.

How long does checking take compared with redoing the job?

Minutes, because you are reading a record instead of repeating the work. Redoing scales with the job: a two hour research run costs two more hours to redo. Checking scales with the claims that matter, and most outputs rest on a handful. You open the job record, test the load bearing claims against their saved results, count the steps, and stop. The full job stays done once.

What does a verifiable receipt prove about the work?

It proves the saved result was not changed since it was saved. A receipt carries the exact saved bytes of a call and their SHA-256 digest, so anyone can recompute the digest and confirm the record they are reading is the record the run produced. It does not prove the result was right or the work was good. It fixes the evidence so your checking is about the real results, not about a summary of them.