When a second agent helps, and when it just costs more

What a subagent actually is

Strip the diagrams away. A subagent is a fresh message list, with its own tools, its own budget and its own loop, whose final message comes back to the parent as a tool result.

That is the entire mechanism. There is no new capability, no emergent teamwork, no division of expertise beyond the two prompts you wrote. A “team of five specialist agents” is five prompts and five while loops.

Saying it plainly matters, because the diagrams imply an organisation and the code is a function call.

The one thing it buys

Context isolation. A parent needs five suppliers researched. Done in one context, that is five sets of search results (perhaps 150,000 tokens) dragged through every remaining step. Done as five subagents, each burns its 30,000 tokens in its own window and returns 400 words. The parent’s transcript grows by 2,000 tokens instead of 150,000.

That is real, it is large, and it is the main honest reason to split. Genuine parallelism is the second: five independent lookups can run at once, and wall-clock time drops accordingly.

What it costs

Tokens multiply. Each subagent re-sends its own growing transcript, and the parent still pays for orchestration. One published account of a multi-agent research system reported it using on the order of fifteen times the tokens of an ordinary chat interaction. Budget for a multiple, not a margin.

The handoff loses the evidence. The parent receives a summary, not the material. It cannot tell a confident summary of nothing from a good one, and it has no way to check a figure. Whatever the subagent got wrong is now laundered into a clean sentence.

Errors compound the same way they always did. Five subagents at 90% each give you a fully correct set about 59% of the time. Splitting the work did not change that arithmetic; it only made it harder to see.

Three patterns worth knowing

Orchestrator and workers. Parent decomposes, workers execute independently, parent assembles. Works when the subtasks do not depend on each other. Fails badly when they do, because workers cannot see each other’s findings.

Pipeline. Fixed stages, each with its own prompt: extract, then verify, then draft. This is a workflow rather than a multi-agent system, and being a workflow is why it is the most reliable of the three.

Critic. A second call reviews the first. This helps when the critic has something the author did not: the test output, the schema, the original document, the validator’s complaint. A critic with exactly the same information as the author mostly agrees with the author, at double the price.

When not to split

• The subtasks share state or must happen in order.
• A subtask can fail in a way the parent must handle precisely, rather than as a sentence.
• The split mirrors your org chart. A researcher agent, a writer agent and an editor agent is a description of a newsroom, not a system design.

The rule

Split when the reason is context isolation or parallelism, and write that reason down. If you cannot state it in one sentence, you have a workflow, and a workflow will be cheaper, faster and easier to debug.