ZAMBO.

Direct answer

How do you verify a handover inside an agent swarm?

One hop at a time, before the receiving agent starts work. Each agent in the swarm closes its hop with a handover record: the goal, the steps it ran, the receipts for those steps, and what is still open. The next agent opens the record, checks every receipt in it, and accepts the handover only if the saved results still match what was saved when the work ran. Do that at every hop and the whole swarm job can be walked back later, hop by hop, receipt by receipt.

See the record layer first: the live demo runs one real Zambo call and hands you its receipt in about 10 seconds, no signup. Check any receipt free at zambo.dev/verify. Handover itself lives at zambo.dev/handover.

Updated October 24, 2026.

Why a swarm makes verification harder, not easier

A single agent handing work to a person has one trust boundary. A swarm has one at every hop. Agent A researches, agent B drafts, agent C checks, agent D delivers, and each one mostly sees a summary written by the agent before it. If B quietly dropped a source, or C never actually ran its check, the summary still reads fine and the error compounds downstream. By delivery time nobody can say which hop introduced the problem, because the only record at each hop was prose the sending agent wrote about itself.

The fix is to stop verifying summaries and start verifying records. A summary is a claim. A receipt is a record saved when the call ran, which a third party can recheck later. Verification inside a swarm means the receiver checks records, not claims, before it accepts the work.

The verify-before-you-accept pattern

Run every hop in the swarm the same way:

1. The sender closes its hop with a handover. Using the handover tool, the sender packages the goal, the steps it ran, its outputs, and the open items into one record. Every step inside it carries the receipt that was saved when that call ran.

2. The receiver checks the receipts before accepting. The receiver opens each receipt, at zambo.dev/verify or through the verify flow, and confirms the saved result was not changed since it was saved. A missing step, a gap in the sequence, or a receipt that fails its check stops the handover here.

3. The receiver accepts or refuses, on the record. With handover_status the receiver can inspect the state of a handover, with handover_list it can see the handovers waiting on it, and acceptance itself is recorded. A refusal is not a dead end: it names what failed, so the sender fixes that hop instead of the receiver quietly patching over it.

4. The receiver works, and its hop leaves receipts too. The chain grows by one verified link instead of one hopeful summary.

HANDOVER is the flagship Zambo product, and this pattern is why: chains of handovers, a living handover that keeps updating as work continues, client sign-off at the end, and a dispute pack assembled from the same records if anyone later asks what actually happened.

Live receipts from a swarm style chain

These are real Zambo receipts, minted for this page on October 24, 2026. Open any of them and check it free:

Walking the whole job back

Because each handover names the work it received, the finished job reads in reverse. Start at the delivery, open its handover, and you see what the delivering agent was given. Open that handover and you see the hop before it. Keep going and you reach the first call of the swarm, with a checkable receipt at every step. That walk is what turns a swarm dispute from a blame loop into a short factual answer: this hop, this receipt, this saved result.

The receipt format underneath is AER-1, an IETF Internet-Draft (draft-zambo-aer1-26), with a public conformance corpus of 126 vectors and 129 checks in kit v1.5.7, so the check a receiver runs does not depend on taking Zambo's word for how receipts work.

Honest limits

Verification proves a narrow, useful thing: the saved result on a receipt was not changed since it was saved. It does not prove the result was right, the plan was wise, or the agent chose the best tool. A swarm still needs agents that read what they accept. What verification removes is the invisible failure mode, where work changes hands with no record anyone can recheck. It also only covers work that actually ran through a recording path: a hop an agent did entirely off the record has no receipt to check, and the honest response to that hop is to treat it as unverified.

Run it on a record instead

Work run through the Zambo MCP endpoint at zambo.dev/mcp (153 tools in total, 35 on the default surface) saves its result at execution and returns a verifiable AER-1 receipt for every call, rejected calls included. Start free: 20 free calls per day, then they upgrade. The Day Pass is $0.99 for 24 hours, the Pass is $29 for 30 days, one payment, and checking any receipt is always free at zambo.dev/verify.

Frequently asked questions

How do you verify a handover inside an agent swarm?

Verify it before the receiving agent does any work. The sender closes its hop with a handover record that carries the goal, the steps it ran, its outputs, and the open items. The receiver opens that record, checks each receipt inside it at zambo.dev/verify, and confirms the saved result on each receipt was not changed since it was saved. Only then does the receiver accept the handover and start its own hop, which will leave receipts of its own. If a receipt fails its check or an expected step is missing, the receiver refuses the handover and sends it back instead of building on work it cannot stand behind.

What does the receiving agent actually check?

Three things. First, that every step the sender claims is present, with a receipt for each step and no gaps in the sequence. Second, that each receipt still verifies, meaning the saved result matches the record that was saved when the call ran. Third, that the open items in the handover match the state of the outputs, so a step marked done has a result attached and a step marked open is not quietly half finished. Acceptance is recorded with the handover tools, so the accept or refuse decision itself becomes part of the chain.

Can you walk a whole swarm job back afterwards?

Yes. That is what the chain is for. Each hop points back to the hop before it, so starting from the final delivery you can follow the handovers in reverse: which agent produced this output, what it received, what the agent before it received, all the way to the first call. Any hop can be opened and its receipts checked on their own, so a question about one agent in the middle of the swarm does not require trusting the agents on either side of it.

What happens when a handover inside a swarm is rejected?

The rejected call still leaves a receipt. On Zambo, receipts issue for rejected calls too, so a handover that fails validation, for example a handover_list call sent without its session ID, is recorded as a rejection rather than vanishing. In a swarm that matters: the gap where work stopped is visible in the chain, the reason travels with the record, and the sender can fix the call and hand over again instead of the job silently stalling between two agents. The single-session version of the same mechanics, where one job passes between two AIs with its receipts attached, is the AI session handover guide: the record moves, not a retelling, and the receiver checks each receipt before continuing.

What does swarm handover verification cost?

Checking any receipt is free at zambo.dev/verify, with no signup. Running work through Zambo starts on the free tier: 20 free calls per day, then they upgrade. A Day Pass is $0.99, one payment, for 24 hours. The Zambo Pass is $29 for 30 days, one payment, or $290 for 365 days, and $19 for 30 days for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay with USDC on Base via x402.

Related

Verifying a swarm’s handover starts before the swarm runs: add Zambo to the agents doing the work so every step lands with a receipt the handover can point to.

A handover is only as strong as the receipt the receiving side can check. The AER-1 badge kit carries that same verifiable-receipt proof outward, as an embeddable badge for the pages and profiles where the work is shown.