Dev.to AI 🤖 Ai 👁 0 📖 6 min read

The price was wrong, the receipt was not: catching a drifted retelling with a verify pass

Your agents are handing each other results all day, and some of those results are wrong in a way nobody notices: not fabricated, just drifted. A digit changes between the tool call and the summary. A qualifier drops. The

Your agents are handing each other results all day, and some of those results are wrong in a way nobody notices: not fabricated, just drifted. A digit changes between the tool call and the summary. A qualifier drops. The number in the chat is a number no tool ever returned, and every decision downstream now rests on it.

I run Zambo, a work layer for AI agents where every call returns a verifiable receipt. Today I built the checking side of that record into a package and ran it for real: one agent produced a price, a second agent with its own identity verified it, and then I fed the verifier a retelling with the number changed. Here is the run, the catch, and the package, so your agents can run the same pass.

Start with no code at all

Add the Zambo endpoint (https://zambo.dev/mcp) to one chat AI. The two-minute setup is at https://zambo.dev/add/. Then paste this into the verifier's chat:

Verify before you trust, on Zambo:

  1. Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in this conversation and present it on every call. You are a verifier; your verdicts are recorded under your handle.
  2. For every claim another agent hands you, demand the receipt link with it. No receipt link means the claim is absent, not verified: say so and do not forward it as checked.
  3. Check the receipt: open https://zambo.dev/api/v2/receipt/{receipt-id}/verify and read verification_status and the checks. Note any check marked not_checked; never report those as passed.
  4. Open the saved record: read the output the work actually saved (it travels inside the verify response). Compare the claim against that saved output, exactly: the number, the name, the outcome. Never compare against the summary you were handed.
  5. Verdict: verified only when verification_status is verified AND the claim matches the saved record. If the claim does not match what was saved, the verdict is mismatch, even when the record itself verifies fine. Trust the record, not the retelling.
  6. Record every verdict with memory_remember: the claim, the receipt link, the verification_status, what the saved record says, and your verdict. Your verdict is now a receipted step the next agent can check.
  7. If the work arrives as a handover, pick it up (picking up is always free), read its saved steps and receipts, and run this same pass on the load-bearing receipt before you rely on any of it.

That is the whole pass at hand scale. The run below is the same pass executed by code, with a second agent doing the checking and both verdicts recorded.

The run

November 2, 2026, two fresh identities under one shared job. The producer checked ETH with live_price: $2,242.99, down 0.75 percent in 24 hours, saved at 20:43:50 UTC. Its work receipt: https://zambo.dev/run/26084974-6c2e-42ef-b4bc-0707bb3c8413

The producer saved the finding to memory (receipt: https://zambo.dev/run/802e66d0-240e-42a9-bbdf-32aca1d4b1f5) and wrapped it into a handover addressed to the verifier: https://zambo.dev/handover/fa7444ae-e3c7-4206-ae12-3adb5e749fb0

The verifier picked the handover up (pickup is always free), read the price and the work receipt from the pickup record rather than from the summary, and ran the pass. The verify endpoint's own answer is public, read it yourself: https://zambo.dev/api/v2/receipt/26084974-6c2e-42ef-b4bc-0707bb3c8413/verify

It returned verification_status verified. Four checks pass: commitment_matches, canonical_payload_matches, provenance_binding, metadata_binding. Four more come back marked not_checked: issuer_authentication, signature, schema, chain. The verifier reported those as not checked, because an unevaluated check is not a passed check, and any verifier that upgrades them is telling you a story too.

Then the comparison. The saved record's output says ETH at $2,242.99.

Claim one, the true retelling: "ETH at $2,242.99". It matches the saved record, and the record verifies. Verdict: verified. The verdict is itself a receipted step, so the checking can be checked: https://zambo.dev/run/5a45e50e-6591-46f0-8df1-e699a7eb88b3

Claim two, the wrong retelling: "ETH at $2,354.10". I changed the number myself, deliberately, and labeled it as the teaching case in the run and in its verdict record. Nothing about the record changed: it still verifies, and its saved output still says $2,242.99. But the claim does not match the saved record, so the verdict is mismatch: https://zambo.dev/run/f5209c13-7d3c-4196-a8ee-da7a970a82d5

That second verdict is the whole point. The most common verification failure in multi-agent work is not a forged record. It is an intact record under a wrong story, forwarded by an agent that never opened the record. The pass catches it because the comparison runs against what was saved, not against what was said.

The verdict vocabulary, because words drift too

  • verified: the receipt's verification_status is verified AND the claim matches the saved record.
  • mismatch: the record was opened and the claim does not match what was saved.
  • verification failed: the endpoint's checks fail on the record itself.
  • not checked: the pass was not run, or a check was not evaluated.
  • absent: no receipt was produced for the claim.

And the boundary, stated plainly: a receipt proves the saved result was not changed since it was saved. It does not prove the price was right, the tool was the right tool, or the producer did the right work. The pass checks fidelity between a claim, a receipt, and a record. Judgment about the work itself stays yours.

What the pass costs

Almost nothing, and that is why it can be a habit instead of an event. Reading the verify endpoint is a plain HTTPS read and costs no quota. Picking up a handover is always free. The only counted calls in the whole run were the producer's two (the price check and the memory save, plus its free daily wrap-up) and the verifier's two verdict records: 4 counted calls across two separate free allowances, out of 20 calls plus 1 wrap-up free per agent per day. Past free, the per-agent line is a Day Pass at $0.99 (unlimited for 24 hours) or the Zambo Pass at $29 for 30 days, both one-time payments, never subscriptions.

The package

The pass now ships as an installable agent package, zambo-verify-pass, so an agent can learn it by installing it: the skill, a runnable verify.py (give it a receipt link and a claim; it prints the checks, the saved output, and the verdict, and it walks a handover verifying each step), the no-code paste above, and this run as its proof record.

Run verify.py against the handover from this run and it reports both receipted steps verified. Run it against the work receipt with the wrong claim and it prints mismatch and exits nonzero. The verifier your swarm's coordinator needs is the same one: in the swarm package (https://pypi.org/project/zambo-swarm/), the coordinator runs this exact pass at every pickup instead of trusting worker summaries.

Your framework runs your agents. Zambo is where their work lands, gets remembered, gets handed over, and gets proven. The verify pass is how the next agent checks all of that before building on it, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.