AI agent handoff: transfer the work, not a summary

Every multi-agent system hands work off. The receiving agent starts blind, retries what already failed, and trusts whatever the sender wrote down. A handoff is only as good as what travels with it: context helps the receiver start, receipts let the receiver check. Here is the pattern, where the usual version stops, and what a complete handoff carries.

See a transfer with the evidence attached: an open handover whose steps any receiving agent can check before continuing.

Published October 19, 2026. Updated October 19, 2026. Written against draft-zambo-aer1-23.

The definition

The short answer

An AI agent handoff is one agent transferring a task to another agent: the goal, the current state of the work, and responsibility for finishing it. In agent frameworks the handoff is a routing call that moves the conversation to a specialist. In work that crosses apps, sessions, or people, the handoff is the whole package the job travels in. Either way, the handoff is only as good as what travels with it: a self-written summary asks the receiver to trust the sender, while a receipt-backed handoff gives the receiver a record it can check before it continues.

The framework sense: handoff as routing

Inside one system, handoffs are how specialist agents divide work. The OpenAI Agents SDK documents handoffs as tools: hand the conversation to a Refund Agent and that agent takes over. LangChain and CrewAI builders use the same word for the same move, one agent delegating to another mid-run. Routing is genuinely useful: the right specialist gets the task, with the conversation context attached.

Routing has a boundary, though. It moves the conversation. It does not, by itself, preserve a checkable record of the work already done: which tools ran, what they returned, which step failed and why. When the run ends, or the work leaves that one system for another app or a person, the routed conversation is all that survives, and a conversation is the agents' own account of events.

The handoff file pattern, and where it stops

Experienced builders already patch this by hand: before any agent-to-agent transfer, the sending agent writes a handoff file. The good versions carry the task summary, the steps completed, the steps that failed (with an explicit do-not-retry note, the single most valuable field in the file), the live context, and the suggested next step. It works, and it prevents the worst failure mode, the receiving agent looping on an approach that already failed.

Where it stops: every field in that file is the sender's own claim. The receiver cannot recompute any of it. A step marked completed might never have run; a failed step's error is whatever the sender chose to write. The pattern gives the receiver a story to start from. It cannot give the receiver evidence to check, because the file is written at transfer time, by the party being checked.

Honest limits: a receipt-backed handoff proves the saved record of each step was not changed since the step ran. It does not prove the sender's plan was wise, and it does not prove the work was correct. It settles what was recorded, so the receiver judges the plan against evidence instead of against the sender's notes.

What a receipt-backed handoff adds

  • Evidence per step, made at run time. Each finished step carries a verifiable receipt saved when the step ran, under AER-1, an open IETF Internet-Draft (draft-zambo-aer1-23). The record predates the transfer, so the sender cannot tidy it up on the way out.
  • Failures on the record. Failed and refused steps are recorded the same way as successful ones, so the do-not-retry knowledge is a checked fact, not a note the sender remembered to write.
  • A receiver that verifies before it continues. The receiving agent recomputes the step receipts first. A gap or a changed byte stops the pickup instead of building on it.
  • The pickup itself is recorded. When the receiving agent accepts the handoff, that acceptance lands on the same record, so the transfer has a before and an after that anyone can inspect.

The pieces are live, not theoretical. An outside agent studio wired AER-1 receipts into its deliveries, and one of its public records, receipt 28c79cde, shows what a checked step looks like: 2,078 bytes of saved record that recompute to exactly the committed output hash, sha256:5f06acfb, checkable by anyone with no account. And when a job genuinely crosses systems, the same record chains: the job started in one AI and continued in another stays one record with two hops, the pattern walked through in transferring agent state between frameworks.

Running handoffs this way

Work run through Zambo's 153 tools leaves the receipt per step automatically, so the handoff package assembles itself: goal, done, next, decisions, receipts, and the receiver's acceptance, under one link. Checking is free for the receiver. The recording runs on the free tier on a normal day; a $0.99 Day Pass covers a heavy day of the full machine, and the $29 Pass ($19 for $ZAMBO holders, $290 for the year) fits agents that hand work off daily. Start with agent-to-agent handover, worked end to end, or open the handover docs.

Questions, answered

What is an AI agent handoff?

An AI agent handoff is one agent transferring a task to another agent: the goal, the current state of the work, and responsibility for finishing it. In agent frameworks the handoff is a routing call that moves the conversation to a specialist agent. In work that crosses apps, sessions, or people, the handoff is the whole package the job travels in. Either way, the handoff is only as good as what travels with it: a self-written summary asks the receiver to trust the sender, while a receipt-backed handoff gives the receiver a record it can check before it continues.

What is the agent handoff pattern?

The agent handoff pattern is the discipline of writing the transfer down before it happens: before agent A hands a task to agent B, A writes a structured handoff record, typically the task summary, the steps completed, the steps that failed with a do-not-retry note, the context the receiver needs, and the suggested next step. It beats the implicit alternative, where the receiving agent starts blind and retries what already failed. Its limit is that every field is the sender's own claim: nothing in a self-written handoff file can be recomputed or checked by the receiver.

What is the difference between a handoff and a handover?

The two words name the same act: work passing from one pair of hands to another. Handoff is the spelling builders use inside agent systems, for the moment one agent routes a task to another. Handover is the spelling used for the complete package when a job moves between AIs, tools, or people, ending in the receiver's recorded decision. The spelling is a dialect difference. The substance is identical: what travels with the transfer, and whether the receiver can check it.

What should travel with an agent handoff?

The goal; the state of the work, meaning what is done and what is next; the decisions already made, with reasons, so the receiver does not re-argue them; the failures, marked clearly so they are not retried; and the evidence: a verifiable receipt for each finished step, saved when the step ran. Context written by the sender helps the receiver start. Receipts let the receiver verify the start is real. A complete handoff carries both.

How do I hand off a task from one AI app to another?

Do not copy the chat. Hand off the job's record: goal, done, next, decisions, receipts. If the work ran through Zambo, the handoff already exists as a link: the receiving AI opens it, checks the step receipts, and continues from the record, and its pickup is recorded as an acceptance on the same record. If the switch is forced by a usage limit, zambo.dev/continue is the entry built for exactly that moment. Work that never ran through a recording layer has no record to hand off, which is why the recording has to start before the handoff is needed.