Anthropic Now Says One Agent Is Enough, So Kill Your Agent Swarm
Anthropic advises starting with one capable AI agent and adding subagents only when measured, to avoid cost, latency, and context loss.
Key Takeaways
- Anthropic recommends starting with a single AI agent—good skills, clearly named tools, and a budget—and adding subagents only when evaluations justify the split.
- In several deployments, one well-designed agent outperformed multi-agent setups while being faster and cheaper.
- Splitting agents can cause handoff problems, loss of detail, inconsistent behavior, and higher token costs.
- Multiple agents are still useful for truly parallel work, tasks exceeding one context window, or complex tool sets.
- Before adding a second agent, teams should check whether work is parallelizable, whether context limits measurably reduce quality, and whether tool or instruction conflicts are causing errors.
Meta description: Anthropic's October 22 guide and kit tell teams to start with one AI agent, not a swarm, and add subagents only when measured results justify the split.
Tags: AI agents, Anthropic, multi-agent systems, software architecture
On October 22, the Applied AI team at Anthropic published a guide about when teams should fold subagents back into a main agent, and released a small open-source kit for making that change. The message for teams building AI agents is blunt: start with one agent, good skills, a few clearly named tools and a budget, and bring in a second agent only when an evaluation shows the split is worth it. For a while, the popular answer was many, and agent demos often showed a planner, a researcher, a writer and a boss agent above them. The practical takeaway is that many teams split too early and pay for it.
One agent first, measured second
The guide's default is simple. Before adding a team of agents, build a single agent that can use tools well and keep its own context. Anthropic says it looked at several large company deployments and found that one agent with skills frequently outperformed the alternatives. It beat both a very large prompt and a multi-subagent setup, and was often cheaper and quicker per task. In one customer test, the single loop finished roughly two times faster than the multi-agent version.
A different customer had about twelve specialist subagents behind one customer-facing agent. That setup made it hard to keep tone consistent, and each extra jump between agents made users wait longer. Anthropic also sees a familiar design pattern in proposals: a classifier guesses intent, a fixed chain of reasoning follows, user groups branch into different recommendations, and one orchestrator rules the whole system. The company's feedback is that today's models can often handle much of that with a good system prompt, a handful of small data-fetching tools and strict output rules.
Why subagent teams can lose details
Splitting agents creates a handoff problem. When one agent gives work to another, it cannot pass everything it saw, so it writes a summary. The next agent works from that summary and may summarize again. Anthropic calls this a telephone game. In a support bot example, agent A reads a chat and sees the customer already received one refund, but its note to agent B only says "customer wants refund." B then approves a second refund.
Cognition, the company behind the Devin coding agent, made a similar case in its 2025 post "Don't Build Multi-Agents." Its argument is that agents need full history, and every action contains decisions. If two agents work at the same time without seeing each other, they can make different silent choices, and the pieces may not fit. Cognition said that setup only results in fragile systems.
There is also an organizational reason. In large companies, each team wants its own piece, so each team gets a subagent, and the architecture can become a copy of the org chart. Anthropic points to Conway's law. The result can be overlapping agents with no clear owner, a system prompt where every team adds a line until instructions fight, a pattern the guide calls the Frankenprompt, and tests that each team runs only on its own slice, leaving nobody checking whether the whole system works.
Cost matters too. Anthropic's 2025 post about its multi-agent research system said an agent uses about 4 times the tokens of a normal chat, and a multi-agent system about 15 times. Tokens are the units of text a model processes, so each new agent box means more model calls and context sent again. Teams pay with money, and users pay with time.
When parallel agents still help
The same company also has a strong case for multiple agents. In Anthropic's Research feature, a lead agent starts several subagents that search at the same time. In an internal evaluation, Opus 4 acting as lead with Sonnet 4 helpers did 90.2% better than one Opus 4 working alone. Anthropic also found that token use explained 80% of the performance difference, because parallel agents each get a fresh context window, or working memory, and can spend more tokens on a problem.
The guide is clear about where this fits. It pays off for valuable tasks with lots of work that can run side by side, when information does not fit in one context window, or when there are many complicated tools. Anthropic noted that most coding work has less real parallelism than research. The two cases describe different jobs, not a single rule.
Two older reasons for splitting have weakened. One was prompt size: putting every instruction into one prompt grew huge. The modern fix is progressive disclosure, where the agent sees only a short line about each skill or tool and loads full instructions when it needs them. Anthropic says this is how it shrank the Claude Code system prompt for newer models by more than 80%.
Model capability also changed. The guide says that from Opus 4.5 onward, one loop could handle far more than most teams assumed. Newer models can report on themselves and double-check results, so a lot of scaffolding became useless and could even hold a stronger model back.
The three checks before adding a second agent
The guide gives three cases where a subagent still makes sense. First, is the work truly parallel, with separate parts that each run in a fresh context you throw away afterward? Short profiles of five unrelated companies fit that pattern.
Second, can teams actually see quality drop because one context window is too full? A feeling that the conversation is long is not enough.
Third, does the agent pick the wrong tools or get confused by instructions that clash? The guide mentions that tool choice tends to get worse after about 30 to 50 tool definitions.
If none of those checks is true, keep one agent. There is one extra case: if a specialist has to speak with the user directly, handing over the whole conversation can be right. In other cases, it is better for the main agent to call the specialist like a tool and stay in charge of the chat. When teams do split, they should cut along context, not along topics. A good subagent job needs almost nothing from other parts and returns something small, such as checking a result without knowing how it was made, or one component behind a clean interface.
The single-loop alternative is not primitive. One model with one context window runs in a loop with tools. Each turn it may request many tools, and the harness — the loop that runs the model and executes tools — runs them at once. The model then reads raw output and adjusts its own plan. Skills now carry the house know-how that specialist prompts once held. Tools perform actions, bring live data and enforce hard rules, such as asking for approval before a write. The harness sets limits on turns and money. Parallel work still happens, but it happens in tool calls.
How to fold a swarm without breaking it
The warning in the guide is important. Anthropic tried folding a sample support agent. It got faster, but a case that passed before started to fail. The main agent could look up orders on its own, so it replied alone and never asked the shipping agent when the package would arrive. The failure happened in only one of two runs, which is easy to miss if a team tests once.
That is why the open-source kit works in three steps. First, measure: build one evaluation for the whole system, with around ten good examples enough to start. Second, combine agents that are always called as a pair anyway. Third, fold the rest one by one into a skill with tools, and compare scores each time. If the folded version scores lower, keep the subagent. The guide says teams should look at which specific tasks changed result, not only the total, and run each task several times. The kit states plainly that keeping a subagent is a fine outcome.
People on X noticed the catch: knowing when to undo a fold needs a whole-system evaluation, and many teams have none. The practical answer is to build that evaluation first.
What teams should do next
For the next AI agent project, the guide's advice is to start small: one agent, good skills, a few clearly named tools and a budget. Add a second agent only for real parallel work, a context that is visibly too full, or tools getting mixed up, and only once an evaluation shows it helps. In the cases Anthropic describes, one agent that remembers everything is usually faster and cheaper, and it does not lose details on the way.
Comments (0)