This is an opinion column. In an article dated October 22, 2026, Anthropic argued that for many enterprise agents a single agent loop, which loads skills and tools as it needs them, can beat a multi-agent design on quality, cost and latency. Our view is simple: builders should treat one agent as the default, add subagents only when a measurement shows a specific problem, and stop treating orchestration as a sign of sophistication.
What Anthropic actually said
The article, “Building agents: When to fold subagents into your main agent loop,” is by Diane Sarkis of Anthropic. It does not claim that subagents are obsolete. It lists three situations where they still make sense: a single loop shows measurable quality loss from context bloat, several tasks must run in parallel with fresh context windows, or one agent struggles to choose the right tools or faces conflicting instructions.
Outside those cases, Anthropic describes failure patterns in large organizations. Teams each build their own agent and a platform team adds an orchestrator on top. Details are lost in handoffs, subagents multiply with no owner, and the system prompt turns into what the article calls a “Frankenprompt” of conflicting rules. It also notes that these architectures can end up mirroring the org chart, which it calls “Conway’s law at work.”
The numbers are modest and specific. One customer measured roughly twice the speed with a single loop compared with its multi-agent harness. Anthropic says it cut the Claude Code system prompt by more than 80% for more advanced models, partly through loading content on demand. And it says tool selection tends to degrade beyond about 30 to 50 tool definitions. The Decoder’s report on the piece, published October 25, adds that the point applies to newer models and notes a study from Vals, which the outlet says found agent teams can be faster but do not improve quality. We have not read that study, so we treat it as The Decoder’s characterization.
Why we agree with the direction
Complexity has a cost that rarely appears in a demo. Every handoff between agents is a place where context can degrade. Anthropic’s own wording is a “telephone game,” in which fidelity drops with each pass. Every extra prompt needs an owner, a test and a reviewer, and every extra model loop adds latency and spend.
We made a related point in our column on cheap tokens and expensive agents: agent bills are driven by steps, retries and re-read context, not by the headline price per token. A design that multiplies model calls multiplies all three. Models that can plan, call tools and revise in one context window remove a reason to build the scaffolding in the first place.
There is also an honesty argument. A pipeline of named specialists looks rigorous on a slide. A single loop with a good prompt and a handful of tools looks almost too plain. Plainness is not a defect. Fewer moving parts means fewer places for a failure to hide, and an easier time reading a trace when something goes wrong.
Measure before you change anything
The most useful part of Anthropic’s article is not the thesis but the method. It tells teams to build evaluations first, with about 10 golden examples as a starting point, then fold subagents in one at a time and compare results with and without each. It warns that blind merging can regress: in a sample support-agent test, folding in a subagent lowered latency but broke a process that had been passing, because the main agent answered an order question without consulting the shipping specialist. That failure showed up in only one of two runs, so it advises running each task more than once.
This is the discipline we would ask of any team, whichever direction it is moving. If you are adding agents, prove the single agent fails first. If you are removing them, prove the merged version holds up. Our guide to evaluating AI agents for workflow automation covers how to set up that kind of test, and our summary of a coding agent harness study shows how much of an agent’s behavior can come from the surrounding scaffolding rather than the model.
The counter-arguments
There are fair objections. First, the source has an interest. Anthropic sells models and the platform around them, and an argument that more capable models need less scaffolding is also an argument for its newer models. The company’s examples are customer anecdotes and its own tooling, not an independent benchmark, and we cannot verify them.
Second, the claim is conditional on model capability. Teams running smaller or cheaper models may still need decomposition, because a weaker model may not hold a long plan together in one loop. Third, parallel work is a real use case. Independent research paths and black-box verification are cases Anthropic itself names for subagents.
Fourth, organizations are not tidy. A central team that owns one system prompt, which the article recommends, is a governance choice as much as a technical one. Companies with many teams may find that a single loop moves the sprawl into the skill library instead of removing it. Anthropic acknowledges as much by calling for designated owners.
None of this changes our conclusion. It narrows it: one agent first, evidence before orchestration.
What to watch next
- Independent benchmarks that compare single-loop and multi-agent designs at equal cost.
- Whether other labs publish their own guidance on when to use subagents.
- Early reports from teams that run Anthropic’s migration kit on real systems.
- How well tool search holds up as skill libraries grow.
Key takeaways
- Anthropic’s October 22 article argues a single agent loop often matches or beats multi-agent setups on quality, cost and latency.
- The same article keeps subagents for context bloat, true parallelism and tool-selection problems.
- Handoffs lose context, and added prompts and loops add cost and latency.
- Build a small end-to-end eval, fold in one subagent at a time and run tasks more than once.
- The evidence is vendor-supplied, so verify it on your own workload.
Frequently asked questions
Does Anthropic say subagents are no longer useful?
No. Its article names three cases where they still make sense: measurable quality loss from context bloat, parallel tasks that need fresh context windows, and tool-selection or instruction conflicts a single agent cannot resolve.
How should a team decide between one agent and many?
Start with one agent and a small end-to-end evaluation. Add or keep a subagent only where results show it improves quality, cost or latency.
Is the single-agent advice independent research?
Not in the article we read. It comes from Anthropic’s own experience with customers and its own tools, so teams should confirm the results on their own tasks.
