Handoffs: passing work between agents without losing the plot

Watch what actually happens when work moves between agents. A first agent breaks a feature into tasks. You hand one task to a second agent to build. It builds something plausible, and it rebuilds a decision the first agent had already made and rejected, because that decision never traveled with the task. Now you are reviewing code that solved the wrong version of the problem, and the reason is not that any agent was bad. It is that the handoff carried the what and dropped the why.

Handoffs are where multi-agent work leaks. Every time work crosses a boundary, between two agents, between two sessions of the same agent, between last night’s run and this morning’s, there is a chance the context does not make it across. And the thing that gets lost is almost never the code. The code is right there in the branch. What gets lost is everything that is not code: the decisions already made, the constraints that must hold, the paths already tried and rejected, the question still open. That is the plot, and it is what a good handoff has to carry.

Why a transcript is not a handoff

The default handoff is “here is the chat, catch up.” It does not work, for the same reason handing someone a three-hour meeting recording is not a briefing. The information might technically be in there, but the receiver has to reconstruct it, and reconstruction is expensive and lossy.

Worse, a transcript is mostly noise. It contains every dead end the first agent explored, every tool call, every correction, with no signal about which parts still matter. A fresh agent reading it cannot tell the decision that stuck from the idea that was tried and dropped. So it either re-explores the dead ends or, worse, treats an abandoned approach as the current plan. The longer the transcript, the worse this gets, which ties directly to managing the context window: dumping a full history into a fresh session does not transfer understanding, it transfers noise and eats the budget you needed for the actual work.

A handoff is not the raw history. It is the distilled state: what is true now, what must stay true, and what is still open.

What has to travel

A clean handoff carries a small, deliberate bundle. In my experience operating agents across sessions, it is roughly this:

• The contract. What we are building and what counts as done, stated as criteria the receiver can check, not vibes it has to infer. This is the same portable artifact I argue for in software specifications should be portable: a contract that travels is worth more than one trapped in the session that wrote it.
• The current state. Where the work actually is. What is done and verified, what is in progress, what has not been touched. Not “read the diff and guess.”
• The decisions already made, with reasons. The choices that are settled and why, so the receiver does not reopen them. A decision without its reason gets re-litigated on contact.
• The dead ends. What was tried and rejected, and why. This is the part transcripts bury and the part that saves the most time, because it stops the next agent from walking the same wrong path with confidence.
• The open question. The one thing the handoff is actually asking the next agent to resolve. If a handoff does not name what it wants, the receiver guesses.

Notice what is not on that list: the full history. The bundle is a summary of state, not a replay of events. That is the difference between a handoff that lets the next agent continue and a transcript that makes it start over.

Handoffs, recovery and memory are one problem

Once you see the bundle, you see that three things you might treat separately are the same thing.

A handoff between agents passes that bundle sideways, from one agent to another. Recovering a dead run passes it forward in time, from last night’s failed run to this morning’s resume, which is exactly why recovery is a first-class workflow and not heroism: a run you can resume is a run that handed off cleanly to its own future. And memory is the same bundle persisted, so it survives when no one is actively passing it. In each case the question is identical: does the state that matters live somewhere outside the session, in a form the next reader can act on? When it does, all three work. When it does not, all three collapse into reading a transcript nobody wants to read.

Anthropic’s writeup of a multi-agent research system lands on a related point from the orchestration side: coordinating multiple agents is largely a problem of what each one is told and how their outputs combine, not of any single agent’s raw ability. The handoff format is that coordination made concrete.

Designing handoffs you can trust

You can make handoffs reliable today, without special tooling, by treating the bundle as an artifact instead of a vibe:

• Write the handoff, do not point at the chat. A short, structured note that carries the five things above beats “scroll up” every time. If it feels redundant to write, that is because you are the one who still remembers. The receiver does not.
• Keep the contract outside the session. If the acceptance criteria live in a file or a task rather than in one agent’s context, every handoff inherits them for free instead of re-deriving them.
• Record decisions as you make them, not at the end. A decision captured with its reason at the moment it is made survives the handoff. One reconstructed afterward is half-invented.
• Name the open question explicitly. End every handoff with the single thing the next agent is meant to resolve. Ambiguity here is where the plot gets lost.

This is not new discipline. It is the same thing good teams do at shift change and good engineers do in a pull request description. Agents just make the cost of skipping it show up faster, because they will confidently run with whatever you failed to hand them.

Where PaellaDoc fits

A handoff loses the plot when the state that matters lives only in a transcript, and a clean one works when the contract, the decisions and the open question travel as an artifact the next agent can act on. That is the mechanism. It is also the same machinery recovery and memory need, which is why I treat them together rather than as three features. PaellaDoc keeps the contract, the decisions and the run state as first-class artifacts that persist outside any single session, so passing work between agents, resuming a dead run, and remembering across days are the same operation instead of three separate acts of heroism. The person doing that reconciliation by hand right now, holding the plot across every boundary, is the runtime.

FAQ

What should an AI agent handoff include?

Five things: the contract (what is being built and what counts as done, as checkable criteria), the current state (what is done, in progress, or untouched), the decisions already made with their reasons, the dead ends already tried, and the single open question the next agent should resolve. Notably not the full transcript, which is mostly noise the receiver has to re-filter.

Why not just give the next agent the full chat history?

Because a transcript is a replay of events, not a summary of state. It contains every dead end and correction with no signal about what still matters, so the receiving agent either re-explores rejected paths or mistakes an abandoned approach for the plan. It also burns context budget you need for the real work. A distilled handoff transfers understanding; a raw transcript transfers noise.

How are handoffs related to recovery and memory?

They are the same problem in three directions. A handoff passes state sideways between agents, recovery passes it forward in time to resume a dead run, and memory persists it so it survives when no one is actively passing it. All three depend on the state that matters living outside the session in a form the next reader can act on.