Handoffs Between Agents Are Contracts: What to Pass, What to Leave Behind

Multi-agent designs usually fail at the seams. Each agent may work well alone, yet the system misbehaves because the message passed from one to the next is vague, bloated, or missing something the receiver assumed it would have. A handoff is an interface, and interfaces deserve the same care as an API.

The receiver starts from zero

A sub-agent does not share your orchestrator's memory. It sees only what you put in its prompt. That sounds obvious, but the common failure is writing the delegation as if the receiver had been in the room: "Fix the issue we discussed in the config loader." The receiver cannot know which issue, which file, or what "fixed" means.

A useful handoff answers five questions explicitly:

1. Goal: what outcome is wanted, in one or two sentences.
2. Done criteria: how the receiver (and you) will know it is finished. Prefer something checkable, such as "the failing test test_reload passes and no other test changes status".
3. Inputs: the exact files, IDs, or data the task concerns, passed by reference where they are large.
4. Constraints: what must not change, which tools are off limits, and any budget on time or steps.
5. Return format: the shape of the answer you want back.

If you cannot fill in the done criteria, the task is probably not ready to delegate.

Pass facts, not conclusions you have not verified

Orchestrators love to summarize. The risk is that a summary silently turns a guess into a fact: "the bug is in the cache layer" may be a hypothesis from two steps ago. Label provenance. Separate what was observed (a stack trace, a failing command and its output) from what is inferred. A receiver told "suspected, not confirmed" will check; a receiver told "the bug is in the cache" will go and edit the cache.

Equally, do not pass everything. Dumping the full parent transcript into the child buries the task and costs tokens. Pass the minimum that makes the task unambiguous, plus pointers the child can follow if it needs more.

Make the return path a contract too

The reply deserves a schema as much as the request. Ask for a status (done, blocked, needs_decision), a short result, and a list of anything the receiver changed or could not verify. A free-text "all good!" forces the orchestrator to guess whether the work succeeded, and that guess is where silent failures hide.

Validate the reply in code before acting on it. If the status is missing or the format is wrong, treat that as a failure of the sub-task, not as something to interpret charitably.

A practical test

Take one real handoff from your system, strip it of any context except the message itself, and give it to a colleague. If they would need to ask clarifying questions, so will the model, except it will usually guess instead of asking. Rewrite the handoff until a stranger could act on it, and keep that template as the standard for every delegation in the system.