One agent did the work. A different agent picks it up, receipts and all.

Multi-agent work usually changes hands as a paragraph: one agent's summary of what it did, which the next agent has to take on faith. Faith is the part that does not scale. Zambo is the verifiable work layer for AI, and as of the October 16, 2026 publish a handover can be addressed to an agent, not just a person: the package carries the steps and their receipts, and the receiving agent accepts it with a tool call whose acceptance is itself receipted. Below is a real one, run end to end for this page: two steps, one package, one acceptance, every receipt checked.

Worked example: two steps, one package, one acceptance

On October 16, 2026, two calls ran in one session: live_price returned BTC at $81,577.00 USD, recorded under the Claude label, receipt b327dae6-e8c2-4540-8721-b5cadfe56e80; live_price returned ETH at $2,411.80 USD, recorded under the Grok label, receipt ae762cbc-015f-45fc-95cb-1f8a5bd68144. The session was packaged with the recipient type set to agent, addressed to a receiving agent named Night-shift agent: handover 3ba7cb75-26f8-4071-ad49-b38cac656f75, summary receipt 60ea400c-00eb-4ec7-9eed-b2a69bebdb64. A separate session, acting as the receiver, called handover_accept and was handed the goal, the summary, both next steps, and the step receipts with their source links. Its acceptance was recorded as an agent_acceptance event with receipt 1600adb6-ba65-4b49-8d16-4b6fb9a36632, and the handover status reads accepted. The check: the public verify endpoint reports every receipt cited here verified: both source receipts, both published step copies, the summary, and the acceptance.

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

Published October 16, 2026. Updated October 20, 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.

Update, October 17, 2026: an independent implementation, WhiteMagic Labs' continuity-receipt, took a live AER-1 receipt it had never seen and ran its own probe checks against it cold. Every check passed. The run is listed in the AER-1 registry.

Agent-to-agent handover: the short answer

Package the session for a machine reader, and let the machine sign for it. Zambo's handover tool already packaged a session's steps, each with a verifiable receipt, into one link a client can check. Set the recipient type to agent and the same package is addressed to a receiving agent: it reads the goal, the summary, the next steps, and the step receipts, checks what it wants to check, and accepts with the handover_accept tool. The acceptance is not a chat message saying "got it". It is an event on the handover record with a receipt of its own, and the sender reads the flipped status, accepted, from their side. Work changes hands between two AIs, and both the work and the receipt for taking it are on the 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 AER-1 revision 23 has no issuer authentication, so which AI ran a step is what the producing session stated. Acceptance proves the receiver took the record as recorded. Nothing on this page claims more than that.

Why agent-to-agent handoff breaks today

The standard handoff between two agents is a paragraph. One agent summarizes what it did, the next agent reads the summary and starts from it. Every weakness of the arrangement is in that sentence: the summary is written by the agent whose work it describes, it rounds, it drops the step that failed, it states results nobody can recheck, and the receiving agent has no way to tell a faithful summary from a confident one. Multi-agent systems are built out of these paragraphs, chained. The failure mode is not that agents lie; it is that the record of the work and the description of the work are the same object, edited by the worker. A handover built on receipts separates them: the description can say anything, and the steps underneath it still check.

How it works

  1. Do the work in a session. Every call through https://zambo.dev/mcp returns a verifiable receipt: 153 tools behind the one endpoint, each step recorded with the AI label the session stated. In the worked example, two live_price calls ran under two labels, Claude and Grok, in one session.
  2. Package it for an agent. The handover tool takes the recipient, the goal, a summary, and next steps, and the recipient type: human or agent. Published copies of each step are made, each pointing back to its source receipt, and the package closes into one summary receipt under a Merkle root. The example package: handover 3ba7cb75, summary receipt 60ea400c, root ffa7f784285a195bc5c7c9f48b91efcfa6e2ff61507dbe9f2edb3d49d53c4d26.
  3. The receiver reads the record, not a retelling. The handover page and its JSON twin carry each step's saved result, output hash, and receipt link, plus what was not checked. A receiving agent can verify any step against the public endpoint before it builds on it.
  4. The receiver accepts, with a receipt. handover_accept hands the receiver the context bundle (goal, summary, next steps, step receipts with sources) and records an agent_acceptance event on the handover. In the example, that event's receipt is 1600adb6, verified, and the handover status reads accepted.
  5. Work continues on the record. The receiver's own calls join the same trail, and anyone reading later sees the seam: which steps came in with the handover, and which the receiver ran itself. The day's whole trail, sender and receiver together, reads back through the Today view.

Agent handover vs client handover

Same record, two readers. A human recipient gets the page: every step checkable in their browser, a box that lets them break a step and watch the check fail, and Accept or Flag buttons; that flow is covered in proof of delivery for AI work. An agent recipient gets the machine version: the JSON twin, the context bundle from handover_accept, and an acceptance that lands as an event with a receipt instead of a button click. Neither reader has to trust the sender's summary, because neither is asked to: the steps check the same way for both. The older problem of carrying context between AIs by hand, without the acceptance step, is covered in AI agent context handoff and cross-AI memory.

What acceptance does not prove

Acceptance is a signature on the record, not a verdict on the work. The receiving agent in the example accepted two price readings; the receipts prove those readings are the ones the first session saved, unchanged, and that is all they prove. If a price was stale, the record is faithfully stale, and the receiver's job of judging starts from solid ground instead of from fog. The AI labels on the steps are producer-stated: the record shows the session said Claude ran step one, and AER-1 revision 23 gives that claim no independent authentication. What the construction does make expensive is the quiet edit: change a step after handover and its copy stops matching its source, change the step list and the root stops matching, and the acceptance receipt still points at the list as it was. That is the property worth paying attention to, because it is the one the paragraph handoff never had.

Accepting handed-over work, step by step

Acceptance is a procedure, not a reply. The receiving agent works through the package in order, and each step either checks or gets flagged before any new work builds on it:

  1. Read the package as recorded. The handover page and its JSON twin carry the goal, the sender's summary, the listed next steps, and every step's saved result with its receipt link, including anything the sender marked as not checked.
  2. Check before you build. Pick the steps your continuation depends on and verify their receipts: each published copy points back to its source receipt, and the set closes under the summary receipt's root. A step that does not check is a step you re-run, not a step you inherit.
  3. Accept, on the record. Call handover_accept with the handover identifier. The acceptance lands as an agent_acceptance event with a receipt of its own, committing to the step list exactly as recorded, and the sender reads the flipped status with handover_status. A human recipient makes the same act with the Accept control or the client respond call, and it mints the same kind of decision receipt.
  4. Continue on the same trail. The receiver's own work chains onto the record instead of starting a parallel one: a follow-on handover names the first with continue_from, so both halves stay linked and the seam stays visible to anyone reading later.

The chain shape ran live on October 18, 2026: a ten-step session recorded under the Claude label was packaged as handover 5e47dc93, and a separate session under the ChatGPT label continued from it as handover 25555933. The chain is recorded on both handovers, the second one's client link leads back to the chain root, and each side's steps carry their own receipts, so a reader can check the Claude half and the ChatGPT half independently and see exactly where one stopped and the other started.

Questions, answered

Can one AI agent hand work to another agent?

Yes. When a session is packaged with the handover tool and the recipient type set to agent, the handover is addressed to a receiving agent instead of a person. In a live test on October 16, 2026, a two-step session (a BTC price recorded under the Claude label, an ETH price under the Grok label) was handed to a receiving agent named Night-shift agent, which accepted it from a separate session. The handover, its summary receipt, and the acceptance receipt all verify on the public endpoint.

How does an agent accept work handed over from another agent, with proof?

The receiving agent calls handover_accept with the handover identifier. The acceptance is recorded on the handover as an agent_acceptance event with a receipt of its own (in the live test, receipt 1600adb6-ba65-4b49-8d16-4b6fb9a36632, verified), and the handover's status flips to accepted, where the sender can read it with handover_status. The acceptance receipt commits to what was accepted: the step list exactly as recorded at handover time.

What does the receiving agent actually get in a handover?

The goal, the sender's summary, the next steps the sender listed, and the steps themselves: for each step, the tool that ran, the AI label recorded for it, the saved result, and a receipt whose published copy points back to the source receipt it came from. In the live test, the receiver got both price steps with their sources and both next steps, ready to continue from the recorded state instead of from a retelling of it.

Does acceptance prove the handed-over work was correct?

No. A verifiable receipt shows the saved output has not changed since it was recorded; it does not show the output was right, and acceptance means the receiver took the record as recorded, not that the record was true. AER-1 revision 23 has no issuer authentication, so which AI ran a step is producer-stated. Judge the work from the record; the record's job is to make sure you are judging what actually ran.

What does agent-to-agent handover cost?

The handover and handover_accept tools are free. The work inside a handover runs on the same terms as any Zambo call: a free tier on every tool, a $0.99 Day Pass for 24 hours of higher limits, and the Zambo Pass at $29 a month or $290 a year ($19 a month for $ZAMBO holders). Agents pay for their own pass in USDC on Base through x402; people pay by card through PayPal.

How do I hand a project from one AI to another?

Package the work, not a retelling of it. With Zambo's handover tool, the current session becomes a handover: the goal, the steps taken, the saved result and verifiable receipt for each step, and the next steps, at one link. The receiving AI opens the handover, checks the receipts it cares about, accepts it with handover_accept, and continues from the recorded state. Nothing depends on the first AI's summary being complete, because the receiver reads the recorded steps themselves. A receipt proves a saved result was not changed since it was saved; whether the work so far was right is the receiver's judgment, made against that record.

Hand a project from one AI to another

The problem: the project lives inside one AI, and you need a different AI to take it over. Maybe you hit a usage limit mid-job, maybe another model is better at the next stage, maybe a teammate works in a different tool. The usual move is to ask the first AI to summarize itself and paste that summary into the second AI. The summary drops steps, smooths over gaps, and carries no proof of anything, so the second AI starts from a story about the work instead of the work.

To hand a project from one AI to another so the handover holds up, move the record, not the retelling. Package the session with Zambo's handover tool: the goal, each step as it was recorded, the saved result and a verifiable receipt per step, and the next steps, all at one link. The receiving AI opens the handover, checks the receipts behind any step it will build on, accepts with handover_accept, and continues from the recorded state. You can watch the acceptance land with handover_status. What was done stays checkable after the move, because the receipts travel with the project.

The handover and acceptance tools are free; the work inside runs on the same terms as any Zambo call. For $0.99, a Day Pass covers a full day of project work with a receipt under every step, so the next handover is a link you can send instead of a summary you have to hope is complete: 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.

Related