Verify an AI agent's records: transcripts, logs, traces, and run history.

The problem every record on this page shares

Transcripts, logs, traces, and run histories all fail verification for the same reason when they stand alone. The version the agent, or its operator, hands you is a document in that party's control. It can be edited after the fact by whoever holds it: a failed call can be removed, an output can be rewritten, steps can be reordered, and the edited version reads exactly as clean as the original. Nothing in the document itself lets a receiver recompute anything, so the strongest check available is reading it and deciding whether it sounds plausible. That is not verification. That is trust, dressed up as a file.

Per-step verifiable receipts change the material you are checking. Each step, as it is recorded, leaves a receipt carrying the saved result and a digest over that result. A workflow record then links the receipts for a run in sequence, so the set of steps is accounted for and a missing step shows up as a gap rather than a clean record. The receiver's check becomes mechanical: recompute each digest, read each saved result, compare both against the claim, and account for the sequence. The sections below apply that one check to each kind of record.

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 tool call transcript verification

What the record is. A tool call transcript is the readable account of a run: the calls the agent says it made, in order, with the arguments it says it passed and the results it says came back. It is the record most people are handed first, and the one most often quoted when someone asks what the agent did.

Why the handed-over version cannot check itself. The transcript is produced and held by the agent or its operator. Whoever holds it can edit it after the fact: drop a call that failed, tidy an argument, replace a result with a better one, or write a call in that was never recorded at the time. The transcript carries no digest over its contents and no per-call commitment, so nothing in it lets a receiver recompute anything. Re-reading it, or asking another model to grade it, produces an opinion about a story. It does not check the story against anything outside itself.

How receipts change the check. Treat the transcript as the claim, not as the evidence. For each call it lists, find the per-step verifiable receipt, recompute the digest over the saved result, and read the saved result itself instead of the transcript's version of it. Then use the workflow record to account for the sequence: a call in the transcript with no receipt is unverified, and a receipt in the sequence with no mention in the transcript is something the transcript left out. Both mismatches are findings. For the longer walkthrough of this pattern, see Did my agent lie? How to check what your AI actually did and how to audit AI agent tool calls. The full walkthrough, with a live run checked line by line, is in AI agent tool call transcript verification.

AI agent log verification

What the record is. A log is the running record a system writes as it works: timestamped entries for calls, results, errors, and retries. Logs are built for the operator who runs the system, for debugging and operations, and that origin shapes what they can and cannot show a second party.

Why the handed-over version cannot check itself. A log file, a log export, or a screenshot of a dashboard is still a copy in the holder's control. Whoever holds it can edit entries after the fact, delete the entries that look bad, or export only the slice that supports the claim, and the edited log gives no sign that anything changed. A plain log entry contains no commitment over its own bytes, so nothing in it lets a receiver recompute anything. The receiver is asked to trust the logger, the exporter, and the person who chose the slice, all at once.

How receipts change the check. A log entry that matters should point to, or be backed by, a verifiable receipt for that step. The check is then per entry: recompute the digest from the saved result, confirm it matches the receipt, and read the saved result rather than the log line's summary of it. Entries with no receipt stay in the log's original category: useful for debugging, unverified for anyone else. The workflow record across a run also makes deletions harder to hide, because a missing step leaves a gap in the sequence instead of a shorter, cleaner log. The side-by-side comparison is in AI agent execution log vs verifiable receipt, and the construction behind checkable entries is in tamper-evident AI agent logs.

AI agent log verification, step by step

The section above states the principle. This is the procedure, the way a receiver actually runs AI agent log verification on a finished run, in order:

1. Ask for the receipts with the log. A log on its own cannot be verified, because the party handing it over controls it. Verification starts when each important entry is backed by a verifiable receipt that was fixed when the step was recorded. If there are no receipts, say so in the report and stop: the log is a claim, not evidence.
2. Pick the entries the decision turns on. You do not need to check every line. Start with the entries behind the claims that matter: money moved, messages sent, files changed or deleted, data handed to a client. Those are the entries a dispute or an audit will ask about first.
3. Recompute one entry end to end. Take the saved result behind one entry, recompute its digest from the saved bytes, and compare it with the digest in the entry's receipt. A match means the saved result was not changed since it was saved. A mismatch, or a missing receipt, means that entry is unverified, whatever the log line says.
4. Sample across the run, then check the sequence. Repeat the recompute on entries spread across the run, not just the opening steps. Then check the checked entries against the workflow record that links the run's receipts in order: a step deleted from the log leaves a gap in the sequence instead of a shorter, cleaner record.
5. Write down what verified and what did not. The output of log verification is a split, not a vibe: these entries recompute and are checked; these entries have no receipt and stay unverified. A report that hides the second list is the log problem all over again, one level up.

What this proves is narrow and worth stating plainly: the saved results behind the checked entries were not changed since they were saved, and the sequence accounts for the run. It does not prove the agent chose the right steps, or that a saved result is correct. That judgment is yours, now made against records you checked instead of a file you were handed. On Zambo, every call leaves its receipt as it runs, so a finished run arrives with the evidence already attached: check one entry in the live demo, then run the same five steps on your own agent's next job with a Day Pass.

AI agent execution trace verification

What the record is. An execution trace is the ordered path of a run: which step followed which, what went into each step, and what came out. Where a transcript reads like a conversation and a log reads like a journal, a trace reads like a route, and it is the record people reach for when they need to find where a run diverged from what was expected.

Why the handed-over version cannot check itself. A trace handed over after the run is a document assembled after the fact, held by the agent or its operator, and it can be edited after the fact by whoever holds it: steps can be reordered to make a decision look earlier or later than the record shows, a branch can be trimmed, an intermediate result can be replaced. A trace document on its own carries no per-step commitment a receiver can recompute, so nothing in it lets a receiver recompute anything about any individual step. The route can look complete and coherent and still be a redrawn map.

How receipts change the check. Verify the trace one step at a time, then verify it as a sequence. Per step: match the step to its verifiable receipt, recompute the digest over the saved result, and read that saved result. As a sequence: check the steps against the workflow record, which accounts for the receipts in order, so a step the trace skips and a step the trace invents both stand out, one as a gap and one as a step with no receipt underneath it. What you end up trusting is not the trace document. It is the set of saved results, each checked, in an order the workflow record accounts for. Related reading: AI agent traceability and replaying an AI agent run from its receipts. The full walkthrough, with a live trace checked per step and as a sequence, is in AI agent execution trace verification.

AI agent run history verification

What the record is. Run history is the record across runs: what an agent did today, last week, and over the life of a job, usually presented as a list of runs, a history page, or an export. It is the record clients, managers, and auditors ask for when the question is not one run but a pattern: what has this agent been doing on our behalf?

Why the handed-over version cannot check itself. A history is a selection as much as a record. Whoever holds it can edit it after the fact: remove a run, edit the summary of a run, regenerate the list from a different starting point, or present only the runs that ended well. A list entry, like a log entry, carries nothing a receiver can recompute, so nothing in the history lets a receiver recompute anything about any run in it. The longer the history, the more authority it appears to carry, and the less checkable each entry in it actually is.

How receipts change the check. A verifiable run history is one where the history is built from receipts instead of written over them. Each run in the history resolves to its workflow record, and each step in that run resolves to its per-step verifiable receipt with a saved result a receiver can recompute and read. Checking a pattern then starts from checked units: sample runs from the history, or take the specific runs a dispute turns on, and run the same recompute-and-compare check. A run that resolves to receipts can be checked. A run that exists only as a line in a list cannot, and the history should say so plainly rather than smoothing over the difference. For the underlying history format, see AI agent tool call history.

Verify AI code changes executed

What the claim is. A coding agent finishes with claims a reviewer has to act on: a file was changed, a command was run, a test suite was run and the result was a pass. Those claims arrive as a summary in the agent's final message, and the code review that follows usually starts from that summary.

Why the summary cannot check itself. The final message is written by the agent, after the fact, from its own account of the session. The agent, or whoever operates it, holds that account and can edit it after the fact: a test run that failed can be described as the run that passed, a file write that was never recorded can be listed among the changes, a command's actual output can be paraphrased into something cleaner. Nothing in the summary lets a receiver recompute anything about any of it. Reviewing the diff alone helps, but the diff shows the end state of the files. It does not show what was saved for each call along the way, including the test output the agent says it saw.

How receipts change the check. Put the claim next to the receipt for the actual call. If the claim is that a test was run, read the saved result in that call's verifiable receipt, recompute its digest to confirm the saved result was not changed since it was saved, and compare what the saved result shows with what the summary claimed. If the claim is that a file was changed, compare the recorded call and its saved result against the state of the repository. Keep the scope narrow while you do it: the receipt shows the saved result for that call. It does not show that the test was a good test, that the change was a wise change, or that the code is correct. Those judgments are the review itself, now done against a record the reviewer checked instead of a summary the reviewer was handed. The full coding-agent treatment is in verifiable receipts for coding agents, and the task-level walkthrough is in How to verify your AI agent actually completed the task.

The pattern, run live on October 16, 2026. A commitment went into the public append-only journal first: job code-change-verify-run-20261016, entry 8af6f91d-4020-459f-a042-770de7d57537, logged at 10:23:55 UTC under entry hash sha256:fa937c6bae6ca0a69f533982b8fa0f57116f0437d1c4fe2d03bece97d7807d7e, stating the check and its acceptance test in advance. The check followed two seconds later: a provibe_audit call against the public repository github/gitignore minted receipt e26cc297-5afd-4733-9c7e-83e3e02a183f at 10:23:57 UTC, provenance class EXECUTED BY ZAMBO. Its saved output is the audit result (score 87, 319 files in the tree, 1 finding), committed under output digest sha256:a4ac4809d05506d252872cae87a72bd023b1de77bb650fb68bb8f71a2cfae909, and the public verify endpoint reports it verified, with the commitment, canonical payload, provenance binding, and metadata binding checks all passing. The audit was run a second time in the same session (receipt 8c393b02-e4da-4fa7-a33c-9312a956b2a2) and returned the same score; its full result names the finding (a high-severity testing gap: no test files detected) and states its own method, deterministic static analysis over directly observed repository signals. Read against the commitment, the claim "the repository was audited and scored 87" is not a summary anymore. It is two records, written before and during the work, that a reviewer can open and recompute.

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

Check AI agent tool execution

The direct check. To check AI agent tool execution, take one call the agent claims it made and find the verifiable receipt recorded for that call. Recompute the digest over the saved result and confirm it matches the receipt. Then read the saved result itself, not the agent's summary of it. If the call has no receipt underneath it, the execution is a claim, however confident it sounds.

A worked example, checked tonight. On October 15, 2026, a live_price call for BTC was recorded as receipt e7ca2113: the saved result reads BTC $82,246.00 USD, up 0.48% in 24 hours, as of 2026-10-15T21:33:40Z. Anyone can rerun the check at the public verifier and reach the same answer, with no account and no cooperation from whoever ran the call. That is the whole pattern: one call, one receipt, one recompute. Zambo is the verifiable work layer for AI, and this check is what the phrase means in practice.

AI agent execution logs explained

What an execution log is. An AI agent execution log is the running record a system writes while an agent works: timestamped entries for each tool call, its arguments, its result, and its errors. Execution logs are explained by their origin: they are written by the system that ran the agent, for the people who operate that system, to debug and to operate it. They are a journal, and a journal is only as trustworthy as the person keeping it.

Where the explanation ends. A plain log entry carries no commitment over its own bytes, so a log can be edited, trimmed, or regenerated after the fact and nothing in it shows the change. The fix is not a better log format. It is a different object underneath the log: a per-call verifiable receipt, fixed at execution time, whose saved result a receiver can recompute. Read the log for the story; check the receipts for the facts. The side-by-side comparison is in AI agent execution log vs verifiable receipt.

Verify AI agent tool calls

The method in one paragraph. To verify AI agent tool calls, work per call, not per report. For each call that matters: match it to its verifiable receipt, recompute the digest over the saved result, confirm the digest matches, and read the saved result. Across a run, check the calls against the workflow record so a call with no receipt and a receipt with no mention both stand out. Calls that verify are facts. Calls that do not are claims, and the record should label them that way.

This is the same check whether the calls came from a coding agent, a research agent, or a swarm: the unit never changes. One call, one receipt, one recompute. How to verify an AER-1 receipt walks the three checks end to end on a real receipt.

Verifiable AI agent logs

The problem: you are handed a log and asked to trust the system that wrote it. A normal agent log is a file its keeper controls. Entries can be edited, trimmed, or regenerated after the fact, and nothing inside the file lets a reader tell. Verifiable AI agent logs are built to remove that trust step: every entry is backed by a verifiable receipt fixed when the step ran, carrying the tool, the time, the recorded inputs, and the saved output under a hash commitment computed at execution time.

Checking one is a procedure, not an opinion. Pick the entries that carry weight, the sends, the purchases, the file changes, the claims a client will rely on. For each one, find its receipt, recompute the digest over the saved result, and read the saved result itself instead of the log line about it. Then check the sequence against the run's workflow record, so a dropped entry shows as a gap. What you report is the split: entries that recompute are verified as recorded, entries with no receipt or a failed recompute are claims. An entry can be checked this way by a client, an auditor, or your future self, with no account on the system that produced the log.

Logs only become verifiable when the work runs where each call leaves a receipt, and yesterday's unrecorded run cannot be upgraded after the fact. Zambo is the instrument for the next run: every tool call through zambo.dev/mcp leaves a verifiable receipt, and multi-step jobs close under one workflow record, so the log for a whole job is one checkable record instead of an export you have to take on faith. For $0.99, a Day Pass covers 24 hours of work logged this way: zambo.dev/day-pass. Ongoing use is the Zambo Pass at $29 a month or $290 a year, $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.