Screenshots of five AI agents working side by side are everywhere right now. They look productive. What they don't show is the token bill, the merge conflicts, or the hour spent figuring out which agent broke the build.
Multi-agent setups can genuinely help with coding work. They can also make a simple task slower, pricier and harder to debug. This article is a decision guide: when one agent is enough, when subagents pay off, when a full agent team is worth it, and how to tell which situation you're in before you spend the tokens.
Start with when NOT to go multi-agent
The most useful question isn't "how do I set up multiple agents?" It's "what specific problem would a second agent solve?"
Cognition, the team behind Devin, made the case for staying simple in a post bluntly titled Don't Build Multi-Agents. Their two principles: share context (full agent traces, not just individual messages), and remember that actions carry implicit decisions. When two agents work on related pieces without seeing each other's choices, they make conflicting assumptions, and the result has to be reconciled by someone. Their conclusion is that a single-threaded linear agent, where context stays continuous, "will get you very far".
Anthropic's own docs for Claude Code agent teams say something similar: teams add coordination overhead and use significantly more tokens than a single session, and for sequential tasks, same-file edits, or work with many dependencies, a single session or subagents are more effective.
So the default is one agent. You add more when you hit a ceiling you can name.
The three ceilings that justify more than one agent
There are three common reasons a single agent stops being enough:
- Context ceiling. The task drags so much material into the conversation (search results, logs, long files) that the useful instructions get buried, or the window fills and has to be compacted.
- Serialization ceiling. The work splits into independent pieces that one agent does one after another, when they could run at the same time.
- Specialization ceiling. Different parts of the job need different tools, permissions or instructions, and cramming all of them into one prompt makes the agent worse at each part.
If you can't point to one of these, you probably don't need another agent. If you can, the ceiling tells you which setup to pick.
Option 1: One agent, done well
For most day-to-day coding (fix this bug, add this endpoint, refactor this module) a single agent with a good instruction file and the right tools is the right answer. Everything lives in one context, so the agent sees every decision it already made.
Before adding agents, try the cheaper fixes first:
- Trim the instruction file so the important rules aren't drowned out.
- Break a big task into a written plan, then work through it step by step in the same session.
- Start a fresh session for an unrelated task instead of piling it onto an old one.
These solve a surprising share of what looks like a context ceiling.
Option 2: Subagents, for side tasks that would flood the context
Subagents are the lightest multi-agent setup. In Claude Code, the subagents docs describe them as specialized assistants that run in their own context window, with a custom system prompt, specific tool access and independent permissions. The main conversation delegates a task, the subagent does the noisy work, and only a summary comes back.
The docs give the use case in one sentence: use a subagent when a side task would flood your main conversation with search results, logs, or file contents you won't reference again.
Good fits:
- "Find every place we call the old payments API and list the files." The search is noisy; the list is what you need.
- "Run the test suite and summarize which tests fail and why."
- A read-only code reviewer that checks a diff against your conventions.
A custom subagent is a Markdown file with frontmatter, saved in .claude/agents/ for one project or ~/.claude/agents/ for all of them. Here's a read-only reviewer in the shape the docs show:
---
name: code-reviewer
description: "Reviews a diff for readability, naming and project conventions. Use after code changes, before committing."
tools: Read, Grep, Glob
model: sonnet
---
You review code changes. Read the changed files, compare them with the
conventions in this repo, and report issues as a short list: file, line,
problem, suggested fix. Do not edit files.
Two details from the docs worth knowing. First, Claude decides when to delegate based on each subagent's description, so write it as "what it does, and when to use it". Second, those descriptions take up context in every session; Claude Code warns at startup when the combined descriptions of your custom subagents pass 15,000 tokens. Keep descriptions short and put the detail in the body, which only loads when the subagent runs.
Subagents also send their own requests, and the docs note those count toward the same usage limits as your main conversation. Cheaper than a team, but not free.
Option 3: An agent team, for parallel work that needs discussion
Agent teams go one step further. In Claude Code they're experimental and off by default; you enable them with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in your settings or environment. One session acts as the team lead, assigns tasks and synthesizes results, while teammates work independently, each in its own context window, and can message each other.
The docs list the strongest use cases as:
- Research and review: several teammates investigate different aspects of a problem, then share and challenge each other's findings.
- Cross-layer work: changes that span frontend, backend and tests, each owned by a different teammate.
The cost side is stated plainly: token usage scales with the number of active teammates. The docs say the extra tokens are usually worthwhile for research, review and new feature work, and that for routine tasks a single session is more cost-effective. They also list known limitations around session resumption, task coordination and shutdown, which is what "experimental" means in practice.
What the extra agents actually cost
The best public numbers come from Anthropic's write-up of how they built their multi-agent research system. In their data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems about 15× more than chats. Their conclusion: multi-agent systems need tasks where the value is high enough to pay for the extra performance.
The same post explains when that value shows up. A lead agent with parallel subagents outperformed a single agent by 90.2% on their internal research eval, especially on breadth-first queries that pursue several independent directions at once. They also note that domains where all agents need to share the same context, or where there are many dependencies between agents, are not a good fit today, and that most coding tasks involve fewer truly parallelizable pieces than research does.
That's the pattern to remember: parallel, independent, high-value work rewards more agents. Tightly coupled work, like editing the same files, punishes it.
A quick decision checklist
Run through these before you spin up a second agent:
| Question | If yes | If no |
|---|---|---|
| Does a side task fill the context with output you won't reuse? | Use a subagent for it | Stay with one agent |
| Can the work split into pieces that don't touch the same files? | Consider parallel subagents or a team | Keep it in one session |
| Do the pieces need to discuss or challenge each other? | Agent team | Subagents are enough |
| Is the task valuable enough to justify several times the tokens? | Go ahead | Use the cheaper setup |
| Could you tell which agent caused a bad result? | Fine | Add logging or simplify first |
The last row matters more than it looks. With one agent, a bad result has one transcript to read. With five, the bug often lives in a handoff: an instruction that was too vague, a summary that dropped a detail, two agents that assumed different things. Anthropic's post makes the same point about delegation: each subagent needs an objective, an output format, guidance on tools and sources, and clear task boundaries, or agents duplicate work and leave gaps.
Where to go next
If you're at the point of designing a real multi-agent system rather than just trying subagents, Multi-Agent Orchestration: The Complete Guide is the framework-agnostic version of this decision, in 40 pages. It starts with when not to go multi-agent, then covers the five coordination patterns (sequential pipeline, fan-out/fan-in, supervisor-workers, dynamic handoff, maker-checker), handoffs and shared state, the five common failure modes, the real cost of coordination, and a 30-day path from a single agent to a system you can actually debug.
This article was written with the assistance of AI and reviewed by the author.
Top comments (0)