You split the job because one agent was carrying too much. A single run was reading the failing test, deciding what to change, editing four files and rerunning the suite, all inside one context that by the end had lost track of why the first file was ever opened. So you cut it: one agent decides, one edits, one checks. Each of them now works in a window small enough to hold. They finish sooner than the single agent did. And the change they hand back is broken in a way the slow one would never have produced — broken at the seam, where nobody was standing.

Nothing crosses a handoff except paper

Two words first. A sub-agent is a second agent the main loop calls for one bounded piece of work, with its own context window, its own tools, and none of the thinking that led the caller to ask. Orchestration is everything that decides who gets called, in what order, and what they are handed when they are.

A car arrives at a repair shop in the morning with a noise nobody can reproduce on demand. The mechanic who drives it hears the rattle start only once the engine is warm, places it on the left side, and forms a hunch about a loose mount. He writes on the work order: intermittent rattle, check exhaust mounts. At two his shift ends. The afternoon mechanic inherits the car and the card. He does not inherit the drive, the sound, or the hunch. Everything that made the first diagnosis good stayed in the first head, and what crossed the boundary is the one line somebody had time to write.

The tempting fix is to hand over everything — the whole conversation, every tool result. Delegation patterns built around handoffs warn against exactly that: carrying it all costs on every pass, and it exposes the specialist to data and tool context it has no business seeing. So the interface stays narrow, and narrow means lossy. That is not a flaw in the implementation. It is the price on the tag.

You buy parallelism with context you lose

Sometimes the price is obviously worth paying. Independent steps run at the same time instead of queueing. Each role can get its own prompt, or its own model. And a checker that did not write the code is not grading its own homework: in the maker-checker arrangement the implementer works in an isolated worktree while a separate verifier runs the tests and the gates on what came out, and only then does anything reach a human. Reject, and the loop reruns the implementer or escalates. Notice where the verifier’s value comes from. It never saw the reasoning, so it cannot be talked into it.

The rest of the time the price is quietly enormous, and the practitioners closest to this are the loudest about it. Cognition’s “Don’t Build Multi-Agents” argues against splitting by default, and LangChain’s piece on how and when to build them treats it as a trade rather than an upgrade. Coordination overhead and duplicated context show up on the invoice: a CI sweeper pattern that wakes every five to fifteen minutes with several sub-agents working and checking each other is rated very high on token cost for precisely that reason. More agents is not more quality. The question worth asking is not whether to split, but where to put the cut so that what falls through it is cheap.

The plan was going to be written down anyway

One cut is reliably cheaper than the others. A planner takes the request and breaks it into verifiable steps. An executor takes one step at a time, writes and runs the code for it, and hands back the result along with whatever went wrong. The planner reads that and decides whether to continue, revise, or stop and ask. In TaskWeaver the planner turns “forecast QQQ over the next seven days” into sub-tasks, the code interpreter writes and runs the Python for each one, and when a detail is genuinely missing — which forecasting algorithm — the planner asks instead of guessing.

That split survives the handoff because a plan is the one artifact whose entire purpose is to be legible to somebody who was not there. Nothing good is left behind in the first head, because the step is the deliverable, and the return path is designed rather than hoped for. Compare it with a team of roles named at a whiteboard, where what gets lost is whatever nobody thought to write — which is reliably the part you needed. The risk that lives between agents is the subject of Multi-Agent Systems.

Cut where something was going to be written down anyway.