Agent Handoff Patterns: Passing Work Without Losing It
AI Agents

Agent Handoff Patterns: Passing Work Without Losing It

Every handoff between agents is a compression step. Four patterns for transferring control, what each one drops, and how to build a handoff packet.

A handoff looks trivial. Agent A finishes, agent B starts, you pass along a summary. In practice the summary is where the run dies.

The researcher spent forty tool calls learning that the auth middleware runs before the rate limiter, that two config files disagree, and that the obvious fix was already tried and reverted in March. It writes three paragraphs. The implementer reads them, does not know about the revert, and does the obvious thing.

Nothing failed. The handoff was lossy, and the loss was invisible until the output was wrong.

Four shapes of handoff

Sequential pipeline. Each stage runs once, in order, and passes forward: research to plan to implement to review. The simplest shape and the one with the clearest failure attribution, because a bad output can be traced to the stage that first went wrong.

Delegate and return. A parent pauses, hands a bounded subtask to a child, and resumes with the result. This is the shape covered in subagent delegation, and it is the only handoff where the receiver never needs the full picture, because the parent still holds it.

Escalation. A cheap or narrow agent hands upward when it hits something outside its competence. The handoff must carry what was already tried, or the expensive model repeats the cheap one's work at ten times the cost.

Continuation. The same logical agent resumes in a fresh context because the old one filled up. Formally a handoff to yourself, and the hardest to get right, because there is no second party to notice that the packet is missing something.

The handoff packet

Treat what crosses the boundary as a data structure with named fields, not a paragraph of prose. Prose lets the sender omit things without noticing; fields make omissions visible.

A packet that survives production usually carries the objective in output terms, the facts established with their sources, the decisions already made and why, the approaches ruled out and why they failed, the constraints that apply, and the explicit next action. The ruled-out list is the field people forget and the one that saves the most tokens.

Note that decisions and rejected approaches are the two fields no summariser will preserve on its own. A model asked to compress a transcript keeps the narrative and drops the negative space, and the negative space is what stops the receiver relitigating settled questions.

Keep artefacts out of the packet. Pass file paths, commit ranges and record identifiers; let the receiver read what it needs. A packet that inlines three files is a packet nobody can afford to send twice.

Who writes the packet

The sender writing its own summary is the default and it is weak. The model that just did the work is the worst judge of what mattered, because everything it did feels load-bearing.

Better: have the sender emit structured findings as it goes, so the packet is assembled from records rather than recalled at the end. This is the same discipline that makes shared state between agents workable, and it costs almost nothing if the fields are part of the tool results already.

Better still for high-stakes transitions: have the receiver ask. A short clarification round before work starts is cheap compared with a wrong implementation, and it surfaces exactly the assumptions the sender did not know it was making.

Where handoffs go wrong

The receiver inherits confidence it has not earned. A packet that says the schema uses snake_case reads as established fact even if the sender inferred it from one file. Mark provenance: observed, inferred, assumed. An agent that knows a claim was assumed will check it before building on it.

The chain grows and each link compresses again. Three handoffs in sequence is three lossy encodings, and by the third the original constraints are gone. Keep chains to two or three stages, and where you need more, have every stage read from a common record rather than from its predecessor's summary.

Failure attribution collapses. When the output is wrong, the question is which packet was ambiguous, not which agent erred, and you can only answer that if the packets were logged verbatim alongside the runs that produced them.

Loops form. Agent A escalates to B, B decides this is A's problem and hands back, and you have burned a thousand tokens per round trip. Handoffs need a direction and a depth limit, in the same way loop detection needs a step ceiling.

Continuation: handing off to yourself

When context fills, the naive move is to summarise the transcript and carry on. That preserves the conversation and loses the working set.

The better move is to write the packet deliberately before you are forced to: current objective, what is done, what is next, the facts and decisions, the open questions. Then start clean with that packet as the opening context. You are choosing what survives rather than letting a summariser choose for you.

Do it early. A continuation written at eighty percent context is thoughtful; one written at ninety-eight percent is a panic dump. The same argument shows up throughout agent memory management — the decision quality drops exactly when you need it most.

Testing a handoff

The useful test is adversarial and takes five minutes. Give the packet alone to a fresh agent, with no access to the sender's transcript, and see whether it can state the objective, name the constraints and describe the next action correctly.

If it cannot, the packet is incomplete, and you have found that out for the price of one cheap call rather than one wrong implementation. Run this against real packets from real runs, not invented ones — the gaps that matter are the ones your senders actually produce.

A rule to work from

Hand off when the receiver needs materially less context than the sender holds. If the receiver needs almost everything the sender has, do not hand off — keep it in one loop and give it a bigger step budget, because the compression will cost you more than the fresh context buys.

And log every packet. When a multi-stage run produces a bad result, the packets are the evidence, and without them you are guessing which brief was wrong.

Common questions

What should a handoff between agents include?

The objective in output terms, established facts with sources, decisions already made, approaches ruled out and why, applicable constraints, and the explicit next action. The ruled-out list is the field most often omitted and the one that prevents the most repeated work.

Should the sending or receiving agent write the summary?

Prefer assembling it from structured records the sender emitted during the work, rather than a recalled summary at the end. For high-stakes transitions, let the receiver ask clarifying questions before starting.

How many handoffs is too many?

Each one compresses again, so quality degrades quickly past two or three stages. If you need a longer chain, have every stage read from a shared record rather than from the previous stage's summary.

Similar articles

Map-Reduce With Agents: Splitting Work That Actually Splits
AI Agents
AI Agents·9 min read

Map-Reduce With Agents: Splitting Work That Actually Splits

Map-reduce over an LLM is not the same as map-reduce over data. Where the shape works, where the reduce step quietly loses information, and how to fix it.

Read
Agent Concurrency Control: Pools, Locks and Fair Slots
AI Agents
AI Agents·9 min read

Agent Concurrency Control: Pools, Locks and Fair Slots

Unbounded agent spawning turns a fast run into a retry storm. Worker pools, semaphores, resource locks and the fairness problem nobody plans for.

Read
Agent Fan-Out Limits: How Wide Is Too Wide
AI Agents
AI Agents·9 min read

Agent Fan-Out Limits: How Wide Is Too Wide

Fan-out looks free until the orchestrator stops reading results properly. The four ceilings that cap parallel agents, and how to find yours before production does.

Read