# Verify before you trust: the verify pass for agent work

Agents consume each other's output all day: a price from one agent, a summary from another, a finished job from a third. The results travel as retellings, and retellings drift: a digit changes, a qualifier drops, a confident sentence replaces the actual output. The verify pass is the habit that catches the drift before you forward it. Take the claim plus its receipt link, check the receipt at the verify endpoint, open the saved record, compare the claim against what was actually saved, and record your verdict as its own receipted step. Zambo is where the record lives: every call at https://zambo.dev/mcp returns a verifiable receipt, and this guide teaches the checking side of it, with a real two-agent run in which a wrong retelling was caught.

- HTML version: https://rambozambodotdev.gitlab.io/aer1-hub/verify-pass-package.html
- Start free: https://zambo.dev/add/
- Endpoint: https://zambo.dev/mcp
- Verify any receipt: https://zambo.dev/verify/

Updated November 2, 2026. First published November 2, 2026. The worked example is a real run executed against the live service on November 2, 2026, with every receipt read back the same day. Author: Brennan Zambo.

## New to verifying? Start here, no code

Add the Zambo endpoint to one chat AI (the one-step setup at https://zambo.dev/add/), then paste the verifier block into its chat. From then on, every claim another agent hands you goes through the pass before you rely on it. The agent saves the identity (its caller handle) the endpoint issues inside its own conversation, and its verdicts are recorded under that identity.

### The paste, for the verifier

```
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.
A receipt proves the saved result was not changed since it was saved. It does not prove the answer was right, and your verdict must never claim it does.
```

That is the whole pattern at hand scale. Everything below is the same pass at full depth: the endpoint's checks read honestly, the verdict vocabulary used exactly, and the receipts of a run executed by code, including the catch.

## Why retellings drift

**The number changes.** Somewhere between the tool call and the chat summary, $2,242.99 becomes $2,354.10. Nobody lied; a figure was retyped, rounded, or regenerated from memory instead of copied from the record. Every downstream decision now rests on a number no tool ever returned.

**The summary replaces the work.** "Done, checked, all clear" is a claim about work, not the work. When the next agent builds on the summary, it builds on the claim. The saved record (the steps, the outputs, the receipts) is the only version that cannot quietly edit itself.

**The check nobody can audit.** An agent that "verified" something in its head leaves nothing behind: no receipt checked, no record opened, no verdict written. The verify pass ends with the verdict saved as its own receipted step, so the checking itself is checkable.

## The pattern

**Step zero**: the verifier connects once, is issued a caller handle, saves it, and presents it on every call. Its verdicts key to that identity.
**1. Demand the receipt**: every claim arrives with a receipt link, or it is recorded as absent and is not forwarded as checked.
**2. Check the receipt**: GET https://zambo.dev/api/v2/receipt/{id}/verify returns verification_status and the checks. The binding checks recompute whether the saved result changed after it was saved.
**3. Open the saved record**: read the output the work actually saved, from the receipt itself, not from the summary that carried the claim.
**4. Compare**: the claim verifies only if the endpoint says verified AND the claim matches the saved record. A wrong claim over an intact record is a mismatch.
**5. Record the verdict**: save it with memory_remember under the verifier's own handle: claim, receipt, endpoint status, what the record says, verdict. That save is itself a receipted step.

## The real run: one finding, two retellings, one catch

Executed November 2, 2026, against the live endpoint. Two fresh identities under one shared job id, verify-pass-2026-11-02: a producer (verify-producer) and a verifier (verify-verifier), each issued its own caller handle. The producer checked ETH with live_price: $2,242.99, down 0.75 percent in 24 hours, saved at 20:43:50 UTC: https://zambo.dev/run/26084974-6c2e-42ef-b4bc-0707bb3c8413. It saved the finding to memory (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 (wrap receipt https://zambo.dev/run/4d42b8b8-95d3-4dd5-9caa-fbf9bcbb60cc).

The verifier picked the handover up free, read the price and the work receipt from the pickup record, and ran the pass on the work receipt. The v2 verify endpoint returned verification_status **verified**, with commitment_matches, canonical_payload_matches, provenance_binding, and metadata_binding all pass, and issuer_authentication, signature, schema, and chain reported as not_checked (read as not checked, never as passed). The saved record's output says ETH at $2,242.99.

### The two verdicts

- **True retelling.** Claim: "ETH at $2,242.99". The claim matches the saved record and the record verifies. **Verdict: verified**, recorded as a receipted step: https://zambo.dev/run/5a45e50e-6591-46f0-8df1-e699a7eb88b3
- **Wrong retelling (the teaching case, labeled as such in the run and in its verdict record).** Claim: "ETH at $2,354.10", the number deliberately changed from $2,242.99 for teaching. The record itself is untouched and still verifies; the saved output says $2,242.99, not $2,354.10, so the claim does not match the saved record. **Verdict: mismatch**, recorded as a receipted step: https://zambo.dev/run/f5209c13-7d3c-4196-a8ee-da7a970a82d5

No receipt was fabricated or altered anywhere in this run. The mismatch lives in the retelling, not the record, which is exactly the failure the pass exists to catch: an intact record under a wrong story. The runnable form of this pass ships in the zambo-verify-pass package: https://github.com/zambodotdev/zambo-verify-pass, also on PyPI (https://pypi.org/project/zambo-verify-pass/) and npm (https://www.npmjs.com/package/zambo-verify-pass) as zambo-verify-pass. Its verify.py walks a handover's steps and verifies each receipt; run against this run's handover above, it reports both receipted steps verified.

## Audit this run

Do not take this page's word for any of it. Open the work receipt (https://zambo.dev/run/26084974-6c2e-42ef-b4bc-0707bb3c8413) and check it at https://zambo.dev/verify/, or read the verify endpoint's own answer at https://zambo.dev/api/v2/receipt/26084974-6c2e-42ef-b4bc-0707bb3c8413/verify. A receipt proves the saved result was not changed since it was saved, and the check recomputes that from the record itself. Then open the two verdict receipts and see the pass judging a true claim and a changed one. If a receipt from this run ever fails to verify, that is news, and we want to hear it: write to brennanzambo@zambo.dev.

## The pass, at depth: reading the endpoint honestly

The v2 verify endpoint returns more than a stamp. Its checks map names what was actually evaluated: commitment_matches (the saved output's hash recomputes), canonical_payload_matches (the stored output and call context reconstruct the committed payload), provenance_binding and metadata_binding (the record's provenance and metadata are bound to the same commitment). Checks the endpoint did not evaluate come back marked not_checked, and a careful verifier reports them exactly that way: an unevaluated check is not a passed check. The response also carries the receipt itself, whose committed output is the saved record you compare against. Read the output from there, never from the human-readable preview alone and never from the claim's own summary.

## The verdict vocabulary, used exactly

- **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, whatever the endpoint status.
- **verification failed**: the endpoint's checks fail on the record itself.
- **not checked**: the pass was not run, or a specific check was not evaluated.
- **absent**: no receipt was produced for the claim.

Never upgrade a verdict. Not checked is not a pass, and a verified record under a wrong claim is a mismatch, not a verification.

## The same pass, run over the swarm

The verify pass is not only for pairs. Run with the package's own verify.py over the swarm run published the same day, it walked the swarm's final handover, [the four-agent market scan](https://zambo.dev/handover/a154789b-0588-43c7-a31c-d108eb59406b), and verified all six step receipts at the v2 endpoint. Every one returned verification_status verified: the three live_price receipts ([11dfd131](https://zambo.dev/run/11dfd131-9768-4cc5-9167-5800d6b8f405), [f1501167](https://zambo.dev/run/f1501167-63fb-4ef7-8a58-a22490714d61), [b8771195](https://zambo.dev/run/b8771195-6dd5-4183-9f09-5cd1d77c371d)) and the three memory_remember receipts ([dbc351da](https://zambo.dev/run/dbc351da-6def-4437-90da-47cb54fac2c8), [b1110da5](https://zambo.dev/run/b1110da5-2994-4931-8be5-05ff73c6b8ad), [83d2ba9c](https://zambo.dev/run/83d2ba9c-c92a-468e-bdc0-d8509f2640fd)). The swarm's wrap receipt, [61ee822c](https://zambo.dev/run/61ee822c-3f8e-44a4-aac4-1cf405566a58), verifies as well, and the tool exited 0. Six workers' claims, checked against their own records, none of them taken on trust.

## The accounting: what a verify pass costs

The free tier is per agent: **20 calls + 1 wrap-up free every day** for each agent's own caller handle, **picking up in another AI is always free**, and reading the verify endpoint costs no quota at all. Counted from the run above: the producer spent 2 counted calls (the price check and the memory save) plus its free daily wrap-up; the verifier spent 2 counted calls, the two verdict records. The whole pass, both verdicts included: 4 counted calls across two separate allowances, zero paid calls. Verification is cheap because the expensive part, the work, already happened; the pass is a read and a record.

Quota rule, in the placement that works: put `_caller_handle` inside the tool arguments on every call, as a field of the arguments object itself, not in `_meta` and not in a header. That argument placement is what meters your own daily bucket. Presenting a handle only at `_meta` level or in a header can route you onto a shared network bucket and wall you early.

The scaling line, for agents that outgrow free: a **Day Pass is $0.99 per agent** and makes that agent unlimited for 24 hours; the **Zambo Pass is $29 per agent for 30 days** ($290 for a year, $19 for $ZAMBO holders). Both are one-time payments, never subscriptions. Start at https://zambo.dev/add/.

## Standing instructions, at depth

### For the verifier

```
1. Connect to https://zambo.dev/mcp, initialize once, and save the caller handle the endpoint issues in your own state file. Present it as _caller_handle on every call, with your agent name as the caller label. Your verdicts are recorded under this identity.
2. For every claim you are handed, demand the receipt link. No link: the claim is absent. Record that and do not forward the claim as checked.
3. GET https://zambo.dev/api/v2/receipt/{id}/verify. Read verification_status and every check. Report not_checked checks as not checked.
4. Read the saved output from the receipt in that response. Compare the claim against it exactly: numbers, names, outcomes.
5. Verdict: verified only when the status is verified AND the claim matches the saved record. Any other combination gets its exact word: mismatch, verification failed, not checked, absent.
6. memory_remember the verdict under the job: the claim, the receipt link, the endpoint status, what the record says, and the verdict. The verdict record is the deliverable of the pass.
7. For a handover: pick it up with handover_accept (always free), read its steps and receipts, and run steps 3 to 6 on the load-bearing receipt before relying on the handover's summary.
```

## What Zambo is not here

The verify pass checks fidelity, not truth. It settles whether the record is intact and whether the claim matches the record; it cannot settle whether the producer did the right work, picked the right tool, or read the right source. A wrong price saved honestly verifies perfectly, and the pass will say so. That limit is the point: the pass removes one whole class of failure (drift between work and retelling, and records altered after the fact) so that human and agent judgment can spend itself on the class that remains. Zambo also does not run your agents or choose what gets verified; your workflow does that. Zambo is the record the pass reads: the saved outputs and their receipts, checkable by anyone, at any time, without asking the producer.

## Frequently asked questions

### What is a verify pass, in plain words?

It is the short routine an agent runs before relying on another agent's result: take the claim plus its receipt link, check the receipt at the verify endpoint, open the record of what was actually saved, compare the claim against that record, and write down the verdict. It takes seconds, costs almost nothing, and catches the most common multi-agent failure: a retelling that drifted from the work.

### What does a receipt actually prove?

A receipt proves the saved result was not changed since it was saved: the verify endpoint recomputes the record's checks from the record itself. It does not prove the answer was right. A producer can save a wrong number with a perfectly valid receipt, which is why the pass has two halves: the endpoint check (the record is intact) and the comparison (the claim matches the record).

### What is the difference between verified and mismatch?

Verified means the receipt's verification_status is verified AND the claim matches the saved record. Mismatch means the record was opened and the claim does not match what was saved, even when the record itself verifies fine. In the run on this page, the record verified perfectly while the retelling said $2,354.10 against a saved $2,242.99: verdict mismatch. The record was intact; the story about it was wrong.

### What does a verify pass cost?

Almost nothing. Reading the verify endpoint is a plain HTTPS read that costs no quota, and picking up a handover is always free. The only counted calls are the verdict records you save: the verifier in the run on this page spent 2 counted calls recording its two verdicts, inside the free tier of 20 calls + 1 wrap-up per agent per day. A Day Pass ($0.99, unlimited for 24 hours) and the Zambo Pass ($29 for 30 days) exist for agents that outgrow free; both are one-time payments, never subscriptions.

### Can I run a verify pass with no code?

Yes. Add https://zambo.dev/mcp to a chat AI, paste the verifier block from the start-here section of this guide, and the agent runs the pass by hand: it demands the receipt link, opens the verify endpoint, reads the saved record, compares, and records the verdict in memory. The zambo-verify-pass package also ships verify.py for agents that run code; it does the same pass from one command.

## Related

- [This guide as HTML](https://rambozambodotdev.gitlab.io/aer1-hub/verify-pass-package.html)
- [Run the swarm on one work layer](swarm-coordination-on-zambo.html): the pattern whose coordinator runs this pass at every pickup
- [The loop by use case](the-loop-by-use-case.html): one routine, pre-built for every daily job
- [The scheduled agent heartbeat](scheduled-agent-heartbeat.html): pick up free, work, wrap the proof
- [Start in one AI, pick the work up in another](pick-up-your-work-in-another-ai.html), free
- [AI agent handover, the signature product](https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b)

## The package family

One pattern per package, each teaching by doing, with Zambo as the mechanism inside. The family so far:

- Swarm coordination (zambo-swarm): many agents, one shared job, per-agent receipts, and a coordinator who verifies instead of trusting. Install: `pip install zambo-swarm` or `npm install zambo-swarm`. Guide: https://rambozambodotdev.gitlab.io/aer1-hub/swarm-coordination-on-zambo.html, PyPI: https://pypi.org/project/zambo-swarm/, GitHub: https://github.com/zambodotdev/zambo-swarm-coordination
- Verify pass (zambo-verify-pass): this guide. Check any agent's work against its own record before relying on it. Install: `pip install zambo-verify-pass` or `npm install zambo-verify-pass`. PyPI: https://pypi.org/project/zambo-verify-pass/, npm: https://www.npmjs.com/package/zambo-verify-pass, GitHub: https://github.com/zambodotdev/zambo-verify-pass

- [The daily loop (zambo-loop)](daily-loop-package.html): recall, work, remember, wrap. One standing agent whose memory compounds across sessions. Registry release in progress (see that guide for the source route that works today).
- [Delivery proof (zambo-delivery)](delivery-proof-package.html): client work wrapped as one handover the client opens and checks, with the pickup and sign-off as the acceptance record. Install: `pip install zambo-delivery` or `npm install zambo-delivery`.
- [Signal watch (zambo-watch)](signal-watch-package.html): a baseline remembered, a threshold rule stated, every reading saved, and a digest wrapped whether the rule fires or not. Install: `pip install zambo-watch` or `npm install zambo-watch`.

For work that runs past one day: a Day Pass ($0.99) is unlimited for 24 hours. Ongoing access is the Zambo Pass: $29 for 30 days or $290 for a year, and $19 for $ZAMBO holders, on the same endpoint, with a verifiable receipt on every call. One-time payments, never subscriptions. See the Pass on the pricing page: https://zambo.dev/pricing/

Zambo, the verifiable work layer for AI. https://zambo.dev, MCP endpoint https://zambo.dev/mcp