AI agent tool call transcript verification: the transcript is the claim, the receipts are the check.

Your agent finished a run and handed you a transcript. It reads clean: every call in order, every result plausible. Nothing in it lets you check any of it, because the transcript is a document the agent or its operator holds, and whoever holds it can edit it. Zambo is the verifiable work layer for AI, and the instrument for this problem is the per-step verifiable receipt: a record fixed at execution time, carrying the saved result under a digest a stranger can recompute. Transcript verification is the discipline of checking the story against those records, line by line, and then accounting for the sequence in both directions.

Worked example: one transcript, checked line by line

On October 16, 2026, a three-call run executed in one session. The transcript a receiver would be handed reads: (1) live_price BTC returned $82,786.00; (2) live_price ETH returned $2,485.23; (3) live_price SOL returned $106.95. Now check each line against the record fixed when the call ran. Line 1: receipt 1f2d89d5-158e-487f-9ce4-bd6526807975, minted 11:28:27 UTC, provenance EXECUTED BY ZAMBO, inputs committed under input hash sha256:f31bbad42b432c0b7f24f27c59b2f00379ee381cef8aae0ce9623eade2cebdc3. Its saved result is BTC $82,786.00 USD, up 2.25% in 24 hours, market cap $1663.90B, committed under output digest sha256:a7bfc9b615238d22a4234a9369382b95300b91ac4bcd4ed789a143192678059f. The public verify endpoint reports the receipt verified, with the commitment, canonical payload, provenance binding, and metadata binding checks all passing, and the saved result matches the transcript line exactly. Line 2: receipt 26f90083-b492-4187-9a5a-5402a3c37e48, minted 11:28:30 UTC, saved result ETH $2,485.23 USD, up 5.23%, market cap $303.54B, output digest sha256:92f58843efc52449f4a19b3efa1ac7714c479db5ce7cb8c48c93c83f0dd940eb, verified, all binding checks passing, matches the line. Line 3: receipt e14febe1-bd72-4dce-8ac0-bec0f630bf68, minted 11:28:44 UTC, saved result SOL $106.95 USD, up 4.60%, market cap $63.03B, output digest sha256:0f6510830122dcf56433922574d8c6e5be29c81b9dab79ca794ba877c6630198, verified, matches the line.

Then the sequence, in both directions. The run closed as workflow receipt 1478b576-543f-40d1-b559-c4549d7fbc78 at 11:28:47 UTC, accounting for exactly those three receipts, in that order, under root c4e91f2359a333a1812fd47cccc17ee18f8385b344cf67a94e4960b56d9eb7ff. Recomputing the root from the three receipt identifiers under the construction in Section 8.1 of the draft reproduces that root exactly. Every transcript line has a receipt, and every receipt in the sequence has a transcript line: this transcript passes. Had line 2 quoted a different ETH price, the receipt would still verify and the mismatch would sit in the comparison step, in the open. Had the transcript quietly dropped line 3, the workflow record would still account for three receipts, and the gap would be a finding instead of an invisible absence.

Hold one yourself: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 16, 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 tool call transcript verification

The short answer. 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. Verifying it does not mean reading it harder, and it does not mean asking another model to grade it; both produce an opinion about a story. Verification means checking the story against records that were fixed outside the storyteller's control, at the moment each call ran: for each line, the per-step verifiable receipt, its digest recomputed, its saved result read directly. Then the sequence check, run in both directions against the workflow record, so the lines the transcript added and the calls it dropped both stand out.

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. Transcript verification inherits that scope exactly: it settles whether the transcript matches the records, nothing more, and nothing less.

The transcript check, step by step

  1. Pin down each line's claim. For every line in the transcript, write out what it asserts: which tool was called, with what inputs, producing what result. A line too vague to pin down is already a finding, because an uncheckable claim is doing the work of a checked one.
  2. Find the receipt for each line. The receipt is the executing system's record of the call, written at execution time, not the agent's account of it afterward. If a line has no receipt, stop there: that line is unverified, whatever the rest of the transcript shows.
  3. Recompute the digest and read the saved result. The public verify endpoint recomputes the digest from the saved result and compares it with the committed digest, then reports the provenance and metadata bindings separately. Read the saved result itself. The transcript's version of the result is the thing under examination, not a source.
  4. Compare the saved result with the line. Match means the line describes the record. Mismatch means the line is wrong, and the record shows what the call actually returned, with the inputs it actually received.
  5. Account for the sequence in both directions. Check the transcript's lines against the workflow record's ordered set of receipts. A line with no receipt underneath it is an invention or an out-of-band call. A receipt in the sequence with no line in the transcript is a call the transcript left out. Both are findings, and neither is visible from inside the transcript.

The sibling records get the same treatment with the same instrument: logs, traces, and run history are covered together in AI agent record verification, and the trace has its own full walkthrough in AI agent execution trace verification.

The three ways a transcript fails the check

  • The edited result. The call ran and has a receipt, but the transcript quotes a better result than the one saved: a price that makes a trade look timely, an error rewritten as a success, a partial answer presented whole. The receipt verifies cleanly, because the record is intact; the failure lives in the comparison between the saved result and the quoted one. This is the most common failure and the easiest to miss without the check, because the transcript reads better than the run did.
  • The dropped call. A call ran, failed or embarrassed, and never made it into the transcript. Inside the transcript there is no hole to notice; the remaining lines read as a complete account. The workflow record still accounts for the dropped call's receipt in sequence, so the count and the order expose it the moment the sequence check runs in the receipts-to-transcript direction.
  • The invented call. A line describes a call that never ran: a check that was supposedly performed, a source supposedly consulted. It has no receipt, because there was no execution to fix a record at the time. The transcript cannot distinguish this line from a real one; the absence of a receipt can, and the honest verdict is unverified until a record appears.

A fourth, quieter edit is reordering: presenting the calls in an order that makes a decision look earlier or later than it was. The per-line checks all pass, because each call did run; the sequence check catches it, because the workflow record commits to the order the receipts were fixed in. Order is a claim too, and it gets checked like one.

What transcript verification does not do

It does not grade the work. A transcript that matches its receipts line for line can still describe a badly chosen call, a misread result, or a wrong conclusion drawn from accurate records; verification settles fidelity, not quality. It does not authenticate the issuer by itself: the verify endpoint reports issuer authentication as not checked, and the provenance binding establishes that the stated class is consistent with the record's bytes, not who operates the system. And it only reaches the calls that were recorded: work an agent did outside the recorded path has no receipt, and a transcript line about it stays a claim. These limits are what make the pass meaningful: a transcript that survives this check has earned exactly one thing, that it faithfully reports the recorded run, and that is the thing receivers actually need before judgment starts.

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 transcript 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. The verification discipline on this page is the operating pattern around the format: records at execution time, recompute at receiving time, claims judged against records.

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 operational side, auditing the calls themselves, is in how to audit AI agent tool calls.

Questions, answered

What is AI agent tool call transcript verification?

It is checking a transcript of tool calls against records fixed at execution time instead of trusting the transcript itself. For each call the transcript lists, find the per-step verifiable receipt, recompute the digest over its saved result, and compare the saved result with what the transcript claims. Then check the sequence in both directions: a call in the transcript with no receipt is unverified, and a receipt in the run with no line in the transcript is something the transcript left out. A transcript with no receipts underneath it cannot be checked this way, because whoever holds the transcript can edit it after the fact and nothing in it lets a receiver recompute anything.

Can a tool call transcript be edited after the fact?

Yes, when it is a document the agent or its operator holds, and that is the normal case. Calls can be dropped, arguments tidied, results replaced, and lines reordered, and the edited transcript reads exactly as clean as the original, because the transcript carries no digest over its contents and no per-call commitment. Editing is only detectable from outside the transcript: against per-step receipts fixed at execution time and the workflow record that accounts for the steps in order.

How do I verify a transcript, step by step?

Pin down what each line claims: which call, with what inputs, producing what result. For each line, find the receipt for that call and recompute the digest over the saved result. Read the saved result itself, not the transcript's version of it, and compare the two. Then account for the sequence against the workflow record, in both directions, so a dropped call and an invented call both surface. Lines that verify and match are checked. Lines that do not are findings, and the record shows exactly which line failed and how.

What if a call in the transcript has no receipt?

Then that call is a claim, not a checked step. It may have run somewhere outside the recorded path, or it may never have run at all; the transcript alone cannot distinguish the two, and the honest verdict is unverified. The reverse mismatch matters just as much: a receipt in the run's sequence with no line in the transcript is a call the transcript left out, which is why the sequence check runs in both directions instead of only confirming the lines that are present.

Does transcript verification prove the agent did good work?

No. A verifiable receipt proves the saved result was not changed since it was saved, and transcript verification proves the transcript matches those saved results, line by line and in sequence. Neither proves a result was correct, a price was the right price to act on, or a call was the right call to make. What it removes is the earlier uncertainty: whether the account you are judging from is the work that actually ran. Judgment still happens, but it happens against the real record.

Related