The Handoff
In one line: an agent finishes with a rich internal state and passes on a paragraph, and everything not in that paragraph is gone.
The compression
A worker that researched a topic ends with a great deal: what it searched, what it found, what it discarded and why, what it was uncertain about, what it could not confirm.
What it hands over is a summary. And the receiving agent does not merely lack the rest — it does not know the rest existed. Absence is invisible.
This is why inter-agent misalignment is the second-largest failure category in the published taxonomy, at around 37%. It is not that agents disagree — it is that they are working from different pictures and none of them knows it.
What a handoff must carry
Which makes the interface a design artifact rather than a message format. Five things, and most implementations carry only the first.
The result. What was produced.
The assumptions. What the worker took to be true that it did not verify. "I assumed the user meant the 2024 filing" is the difference between a downstream agent catching an error and inheriting it.
The confidence. Not a number for its own sake, but a signal that changes behaviour: a low-confidence result should be treated differently by whatever consumes it, and without the signal it cannot be.
What was not done. The parts of the sub-task the worker could not complete, and why. A worker that found two of three requested figures must say so, or the supervisor will believe it has three.
Provenance. Where the result came from — sources, tool calls, the reasoning path — so a downstream check is possible and an error can be attributed later.
Typed, not conversational
The design decision that follows: handoffs should be structured objects against a schema, not natural-language messages.
Three reasons.
Structure is checkable. A schema with required fields makes a worker that omitted its confidence or its gaps a validation failure rather than a silent one. Free text makes that impossible.
Structure survives compression. A field labelled assumptions gets read as assumptions. The same content in the third paragraph of a summary may not be attended to at all.
Structure is attributable. When something is wrong, a typed record shows which field carried the error, which is what makes debugging tractable.
The conversational alternative is appealing because it is how the demo works and how people imagine agents collaborating. It is also how you get a system whose failures cannot be localised.
The specification problem
The largest failure category — around 42%, specification and design — mostly shows up here.
A sub-task handed to a worker is a specification, and the common failures are ordinary requirements failures wearing new clothes:
Underspecified. "Research the competitors" without saying which market, how many, what dimensions, or what depth. The worker produces something reasonable and unrelated to what was needed.
Missing acceptance criteria. The worker does not know what finished looks like, so it stops when it feels done — which is the termination problem from the single-agent chapter, now happening independently in several places.
Implicit context. The supervisor knows something it did not say, and the worker's output is wrong in a way the supervisor cannot see, because the supervisor is reading it with the context the worker lacked.
That third one is the most insidious. The supervisor reads the worker's output and it looks fine — because the supervisor supplies the missing context while reading. The error is only visible to someone who has neither.
The mitigation is to make the sub-task specification explicit enough that a worker with no other information could act on it — and then to check that literally, by giving the spec to something that has no other context and seeing whether the result is what was wanted.
Context that should not be compressed
Not everything needs summarising, and knowing what to pass whole is a real choice.
Identifiers, exactly. A document id, a URL, an order number. These must survive verbatim; a summarised identifier is useless or wrong.
The original request. Workers should generally see the user's actual words, not only the supervisor's interpretation. It is small, and it lets a worker notice that the interpretation missed something.
Constraints. Budget, deadline, policy limits. These must reach every worker or each will make locally reasonable choices that violate them.
Everything else can be compressed, and the guidance is the same as in the single-agent chapter's memory lesson: compress what happened, keep what is true.
The return path
One asymmetry worth naming.
The supervisor-to-worker direction is a specification, and it is under the designer's control. The worker-to-supervisor direction is a result, and it is produced by a model — so it is where fabrication, over-claiming and false confidence enter.
Which argues for the same treatment as any other model output crossing a boundary: validate it against the schema, check its claims where they are checkable, and do not let a worker's assertion that it succeeded be the only evidence that it did. That is the critic's job, and it is next.
Key takeaway
Every handoff compresses an agent's working state into a message, and what it drops becomes a blind spot rather than a gap, because absence is invisible to the receiver. Make handoffs typed objects carrying result, assumptions, confidence, what was not done, and provenance — and note that "what I couldn't do" is the field most often missing and most improving. The supervisor's sub-task is a specification, and the worst failure is implicit context, because the supervisor reads the result while silently supplying what it forgot to say.
Next: what happens when one of those errors travels.