Last year almost every agent demo I saw had a little team inside it, with a planner, a researcher, a writer, and some boss agent above them giving out tasks. It looked smart on a diagram, and I get why we drew it like that, it’s how we organize people.
So on a new project the question comes fast, one agent or many, and for a while the popular answer was many. On October 22, the Applied AI team at Anthropic put out a guide about when to fold subagents back into the main agent, and they also released a small open-source kit to help with that move. In my words, many teams split too early and pay for it.
Two older posts look at the same question from other sides, so I’ll use those too.
The default I take from the guide is simple to say. Begin with a single agent that has good skills and tools, and only add another agent when you have a real reason you can measure.
Anthropic looked at several big company deployments, and they say one agent with skills “frequently outperformed” the alternatives. It beat both one huge prompt and the many-subagents 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. Another company had something like twelve specialist subagents sitting behind one agent that talks with customers, and they had trouble keeping the tone consistent, plus each extra jump between agents made users wait longer.
The guide also describes a pattern it keeps seeing in proposals. Teams design a classifier that guesses the user’s intent, then a fixed chain of reasoning steps, then different groups of users, different branches for recommendations, and one orchestrator to rule all of it. Anthropic’s feedback is that today’s models can do most of that by themselves. A good system prompt, a handful of small tools that just fetch data, and strict rules on what the output may look like usually cover it.
When one agent hands work to another, it can’t pass everything it saw, so it writes a summary, and the next one works from that and summarizes again. Anthropic calls this a “telephone game”. Say you have a support bot where agent A reads the chat and sees the customer already got one refund, but its note to agent B just says “customer wants refund”. B approves a second one.
Cognition, the company behind the Devin coding agent, made the same argument back in 2025 in a post called “Don’t Build Multi-Agents”. Their view was that agents need the full history, and that every action quietly contains decisions. If two agents work at the same time without seeing each other, they make different silent choices, and then the pieces don’t fit. They said that kind of setup “only results in fragile systems”.
Then there is a human reason, and to me it is the most interesting part of the guide. In a large company every team wants its own piece, so every team gets a subagent, and the architecture slowly turns into a copy of the org chart. Anthropic points to Conway’s law here. The result: overlapping agents nobody owns, one system prompt where every team has added its own line until the instructions fight (they call this the “Frankenprompt”), and tests that each team runs only on its own slice so nobody checks if the whole thing works.
Then cost. In Anthropic’s 2025 post about their multi-agent research system, they wrote that an agent burns about 4x the tokens of a normal chat, and a multi-agent system about 15x.
Easy to forget when you draw boxes. Each new box means more model calls and context sent again, so you pay with money and your users pay with time.
Now it gets less black and white. That 2025 research post is actually a strong case for multiple agents. In Anthropic’s Research feature a lead agent starts several subagents that search at the same time. On their own internal eval, Opus 4 as lead with Sonnet 4 helpers did 90.2% better than one Opus 4 working alone. They also found that how many tokens were used explained 80% of the difference in performance, and parallel agents each get a fresh context window, so together they can spend far more tokens on a problem.
They were clear about where this fits, though. It pays off for valuable tasks with a lot of work that can run side by side, when the information doesn’t fit in one context window, or when there are many complicated tools. And they noted that most coding work has less real parallelism than research. The two posts just describe different jobs.
People used to split because one prompt with every instruction grew huge. The fix today is progressive disclosure. The agent only gets a short line about each skill or tool, and it loads the full instructions at the moment it needs them. Anthropic says this is how they shrank the Claude Code system prompt for their newer models by more than 80%.
The models also improved. The guide says that from Opus 4.5 on, one loop could handle far more than most teams assumed, and newer models report on themselves and double check results, so much scaffolding became useless and sometimes even held a stronger model back.
The guide gives three cases where a subagent still makes sense, and I keep them in my head as three checks.
First, is the work truly parallel, with separate parts that each run in a fresh context you throw away after? Say you need short profiles of five unrelated companies, that fits.
Second, can you actually see quality drop because one context window is too full? A feeling that it’s long doesn’t count.
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 these is true, keep one agent. There is one more case. If a specialist has to speak with the user directly, handing over the whole conversation can be right. In every other case, it’s better if the main agent calls the specialist like a tool and stays in charge of the chat. And when you do split, cut along context, not along topics. A good subagent job needs almost nothing from the other parts and returns something small, like checking a result without knowing how it was made, or one component behind a clean interface.
What does the single loop look like then? One model with one context window runs in a loop with tools. Each turn it may request many tools, which the harness executes at once, then it reads the raw output and adjusts its own plan. Skills now carry the house know-how that specialist prompts once held. Tools do the actions, bring live data and enforce hard rules, such as asking for approval before a write. The harness sets limits on turns and money. So you still get parallel work, it just happens in tool calls now.
The warning in the guide is the part I would print out. 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. It only failed in one of two runs, easy to miss if you test once.
That’s why their kit works in three steps:
If the folded version scores lower, keep the subagent. Look at which specific tasks changed result, not only the total, and run each task several times. The kit says it plainly, “keeping a subagent is a fine outcome”. People on X noticed the catch: knowing when to undo a fold needs a whole-system eval, and many teams have none. Fair, so build that first.
For your next project, start with one agent, good skills, a few clearly named tools and a budget. Bring in a second agent only for real parallel work, a context that is visibly too full, or tools getting mixed up, and only once an eval shows it helps. One agent that remembers everything is usually faster and cheaper, and it doesn’t lose details on the way. Kill Your Agent Swarm: Why Anthropic Now Says One Agent Is Enough was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.