Multi-agent systems
It is tempting to design agents like an org chart. A planner agent, a researcher agent, a writer agent and a critic agent, passing work between them. The diagram looks sophisticated. Then the bill arrives at ten times the single agent version, the writer contradicts what the researcher found, and nobody can tell which agent made the decision that broke the output.
Multi-agent systems are genuinely powerful for some tasks and an expensive mistake for others. This chapter is about telling which is which.
Give one task where splitting work across several agents clearly helps, and one where it clearly hurts. What is the difference between them?
What it actually means#
In practice, "multi-agent" almost always means one lead agent that hands pieces of the work to sub agents. Each sub agent gets a short brief and its own fresh context window, does its piece (often in parallel with the others), and returns a short result. The lead never sees the sub agents' working, only their conclusions.
Where it helps#
Breadth. Research questions that split into independent threads: compare five vendors, survey what ten papers say, check a policy against eight regulations. Each thread can be explored separately, in parallel, and the threads do not need to agree on anything until the end.
Context isolation. A sub agent can read an entire codebase or forty web pages, burn its whole window doing it, and hand back one paragraph. The lead keeps a clean context focused on the actual task. This is often the main reason to split, even when nothing runs in parallel.
Speed. Five sub agents searching at once finish in roughly the time of the slowest one.
Anthropic described their multi-agent research system in 2025: a lead agent spinning up parallel sub agents beat a single agent clearly on research that needed to cover a lot of ground. They also reported the cost honestly. Agents used around four times the tokens of a normal chat, and their multi-agent setup around fifteen times.
Where it hurts#
Tightly connected decisions. Writing one feature is a long chain of small decisions that depend on each other: a name chosen here, a data shape there. Split it across agents that cannot see each other's reasoning and they make conflicting assumptions. One writes the API returning a list, another writes the caller expecting an object. Cognition, the team behind the Devin coding agent, argued exactly this in a 2025 essay: every action carries implicit decisions, and agents that do not share full context will contradict each other.
Cost. Every sub agent re-reads its own instructions and does its own exploring.
Multi-agent is a trade of money for breadth, speed and clean context. It is worth it when the task is valuable and wide. It is waste when one agent could have done the job in sequence, which is most of the time.
Making it work#
Delegating to a sub agent is delegating to a very capable new joiner who has seen nothing. Everything that makes a good brief for a person makes a good brief for a sub agent:
- the objective, in one or two sentences, and why it matters
- the boundaries: what is in scope and what to leave alone
- the output format: exactly what to return, and how short
- the tools it may use, and roughly how much effort the task deserves
Vague briefs are the most common failure. "Research the competition" sends three sub agents to read the same five websites. "Find the published delivery fee for Bengaluru on each of these three apps, return a table with source links" does not.
Then keep the structure shallow: one lead, one layer of sub agents, a cap on how many it can start, and a cap on what each can spend.
| Choice | What you gain | What you pay | Pick it when |
|---|---|---|---|
| Single agent | One context holds every decision, so nothing contradicts. Cheapest and easiest to debug. | Its window fills up on large tasks, and it works one step at a time. | The default, and almost always right for coding a single change. |
| Lead plus sub agents | Parallel breadth, and a lead with a clean context. | Many times the tokens, and sub agents that cannot see each other. | Wide research, or reading large material that can be summarised. |
| Peer agents talking to each other | Looks flexible on a diagram. | Hard to debug, loops easily, and nobody owns the final decision. | Rarely. Prefer a clear lead. |
Splitting by job title (planner, coder, reviewer) feels natural because it mirrors a team of people. But people share context in meetings and hallway chats, and agents share only what you pass them. Split by independent piece of work, not by role.
Checkpoint#
1. What is usually the strongest reason to use a sub agent?
2. Two sub agents build the front end and back end of one feature in parallel. The parts do not fit. Why?
3. Your sub agents keep doing overlapping work. What is the first fix?
- Multi-agent means a lead plus sub agents with their own contexts.
- It helps with breadth and context isolation. It hurts tightly coupled work.
- It multiplies tokens: reported around 15x a chat, against around 4x for a single agent.
- Split by independent piece of work, not by job title.
A multi-agent system is usually a lead agent that delegates pieces to sub agents, each with its own context, which return short results. It helps when the work is wide and the pieces are independent, like comparing many sources, and when a sub agent can read a large amount and hand back a summary so the lead stays focused. It hurts when decisions are tightly connected, like writing one feature, because agents that cannot see each other's reasoning make conflicting assumptions. It also multiplies cost many times over. So I default to one agent, use sub agents for isolated reading or parallel research, write each a clear brief with objective, boundaries and output format, and keep it to one shallow layer with caps.