Multi-agent systems
Several agents help when work is parallel and independent. They hurt when work is tightly coupled.
Words on this page (4)
- agent
- : A model run in a loop that chooses its own tools and steps until the task is done.
- subagent
- : A helper agent started by another agent for a focused job, with its own context.
- context window
- : The maximum number of tokens a model can look at in one call: your prompt, the conversation, tool results and the answer together.
- token
- : A piece of text the model reads and writes, usually a word or part of a word. About 4 characters of English on average.
When it helps
Research across many sources, audits of many files and independent verification all split cleanly. Each gets its own , so the lead 's context stays small. In Anthropic's multi-agent research system, a lead agent plans and spawns subagents that search in parallel, and the setup outperformed a single agent on broad research questions, using far more .
When it hurts
Coding tasks where pieces depend on each other, because agents make conflicting assumptions. Anything where coordination cost exceeds the work. Remember that token use multiplies with each agent. Rules of thumb: give each subagent a clear objective, output format and boundaries, scale the number of agents to the difficulty, and have the lead synthesize rather than relay.
A worked example: when it pays off
Question: "Compare five competitors' pricing." Five subagents each research one competitor and return a short structured summary. The lead agent merges them into a table. Time drops from one long run to five short ones in parallel. Token use goes up because each agent reads its own sources.
A case where it hurts
Two agents editing different parts of the same program must agree on the interface between them. If they decide separately, the pieces do not fit. Keep tightly coupled work in one context.
The token arithmetic
Invented numbers. One agent researches five competitors alone and uses 100,000 tokens in one long run.
With five subagents, each reads about 60,000 tokens of its own sources, so 300,000 in total. The lead adds 20,000 for planning and merging, which makes 320,000. That is 3.2 times the tokens. In return the five readings happen at once, so waiting time drops to roughly one subagent's run.
The lead does not see the 300,000. It sees five summaries of about 300 tokens each, 1,500 tokens in total.
What goes wrong: summaries lose detail
The lead can only use what a subagent chose to report. If the lead later needs a number that the subagent read but left out, it is gone. A second symptom is vague task wording. If you tell two subagents "research pricing", both may cover the same competitor while a third is skipped. Confirm it by reading the task text each subagent received, then checking the merged table for duplicates and gaps. Give each one a distinct slice, a fixed output format, and a list of the fields you need.
Common mistake
Choosing multi-agent because it looks impressive. Use it when the work splits cleanly.
A newspaper researching a big story splits it: one reporter checks the financials, one interviews former employees, one reads court filings. They work at once and an editor combines the findings. Multiple agents help in the same situation: independent pieces of research done in parallel. They do not help when the pieces depend on one another.
Check yourself
Which task suits several agents best?
Not quite. Independent subtasks parallelize with little conflict.
What is the main cost of multi-agent systems?
Not quite. Each agent carries its own context, so total tokens rise quickly.
Two agents edit different parts of a program that must agree on an interface. What goes wrong?
Not quite. Tightly coupled work belongs in one context.
You got 0 of 3 right.
Go deeper
- Article
Anthropic · Architecture, prompt lessons, evaluation and token cost.
- ArticleDon't build multi-agentsArticle
Cognition · The counterargument: shared context and conflicting decisions.
- CourseAI Agents in LangGraphCourse
DeepLearning.AI and LangChain · Stateful, controllable orchestration.
Spotted a mistake or something unclear? Report it on GitHub.