A handoff is a contract, not a transcript.
When one agent passes work to another, the context that matters is rarely the conversation. We design handoffs as explicit contracts that state the goal, the evidence, the limits, and who owns the result.
Most multi-agent systems pass work along the same way. One agent finishes its part, takes everything it has seen, and forwards it to the next. The research agent hands its full history to the writing agent. The planner hands its whole scratchpad to the executor. It feels safe, because nothing is lost.
It is not safe. A transcript is a record of how the first agent thought, not a statement of what the second agent should do. The receiver has to reverse-engineer the goal from a pile of tool calls, dead ends, and half-formed plans. It picks up the first agent's mistakes along with its findings. It inherits instructions that were meant for a different step. And when something goes wrong, nobody can say which agent decided what. We treat the handoff as its own interface, and we design it the way we would design an API between two services: as a contract.
Say what done looks like
The first field in every handoff is the goal, written for the receiver. Not the original request, and not the sender's summary of everything it tried. A short statement of what the next agent is being asked to produce, and how anyone will know it is finished.
This sounds obvious, but it is the field most often missing. A transcript makes the receiver guess at the goal, and a guessed goal drifts. If the sender cannot write the goal in a few plain sentences, the work is not ready to hand off. That is a useful signal on its own: it usually means the sending step has not actually finished.
Pass evidence, not conclusions alone
A receiver needs to know what the sender found, and it needs to know why the sender believes it. We separate the two. Findings go in as claims. Each claim points to the evidence behind it: the document, the tool result, the user's own words.
This matters because the receiver should be able to check the work without redoing it. A conclusion with no source forces a choice between trusting it blindly and starting over. A conclusion with its source attached can be spot-checked, weighed against new information, or thrown out cleanly if the source turns out to be wrong. It is the same discipline we apply to memory, applied at the boundary between agents.
Scope does not grow in transit
Every agent in our designs runs with a defined set of permissions: which tools it can call, which systems it can read, what it is allowed to change. A handoff must never widen that set.
The failure mode here is subtle. A sender with broad access writes a handoff that says, in effect, "go ahead and finish this." The receiver, scoped more narrowly, now holds an instruction that implies authority it was never given. Or the reverse: a narrowly scoped agent forwards content it read from an untrusted source, and the next agent treats that content as a directive. Our rule is that a handoff carries data and a goal, never authority. Permissions come from the harness, not from the message. Anything the sender read from outside, such as web pages, emails, or shared files, is marked as untrusted, and the receiver treats it as material to reason about, not instructions to follow.
State the limits out loud
A good handoff includes what the sender did not do. Which questions remain open. Which paths it tried and abandoned, and why. Which actions it deliberately stopped short of because they needed a human decision.
That last part is the one we care about most. When a step ends at an approval gate, such as a message that needs sign-off before it sends or a change that cannot be undone, the handoff says so explicitly. The next agent should never discover a pending approval by accident, and it should never route around one because the context that explained it was buried on page four of a transcript. An open approval is part of the state, not a footnote.
One owner at a time
Every piece of work has exactly one owner at any moment. The handoff is the moment ownership moves, and it should be visible as an event: who held it, who holds it now, and when.
Without that, two failure modes appear. Work gets done twice, because both agents believe they own it. Or work gets dropped, because each believes the other does. Explicit ownership also gives the receiver a clear way to refuse. If a handoff is missing its goal, or asks for something outside the receiver's scope, the right move is to hand it back with a reason, not to improvise. A rejected handoff is a cheap failure. A guessed one is an expensive failure that shows up later.
Keep the transcript, just don't send it
None of this means throwing history away. Full transcripts are valuable for audit, for debugging, and for evals that replay a run to see where it went wrong. We keep them, and the handoff links to them.
The distinction is between what is stored and what is sent. The record stays complete and inspectable. The receiver gets a contract it can act on, with a pointer back to the record if it needs more. That keeps each agent's context focused on its own job, which tends to make the work better and the behavior easier to predict across model swaps.
Agents will keep getting more capable, and the models behind them will keep changing. The boundaries between them are where an operating layer either holds together or comes apart. We put the engineering there: explicit goals, sourced evidence, fixed scopes, visible approvals, and one owner at a time.