One Anthropic customer pitted its multi-subagent harness against a single agent loop, and the single loop finished in roughly half the time. On the back of that result and what it has seen across enterprise deployments, Anthropic's Applied AI team published guidance on October 22, 2026 with a pointed recommendation: check which subagents can become skills and tools inside one agent, and use an open-source kit to make that move one measured step at a time.
This is not a "subagents are dead" piece. It is a warning for anyone who built an orchestrator with one specialist per team and is now paying for that structure in latency, cost and context lost between agents.
Why piles of subagents go wrong
The pattern Anthropic describes will look familiar: every product team builds its own agent, and a platform team puts an orchestrator on top. It looks modular on paper. In practice, four problems show up:
- Context lost at every handoff. Someone has to decide what passes between agents, and detail gets dropped in the back and forth. Anthropic calls it a "telephone game".
- Subagent sprawl. Every team ships one, and you end up with hundreds of overlapping agents with no standards and no clear owner. One customer had a dozen specialist subagents in its customer-facing agent and struggled to keep a consistent brand voice.
- The "Frankenprompt". Every team adds a sentence to the system prompt until the rules contradict each other.
- Local evals. Each team tunes its own for its subtask, and nobody measures the system as a whole.
It is Conway's law for agents: the architecture ends up mirroring the org chart.
The alternative: one loop that loads context on demand
The proposed design is one model and one context window running an open-ended tool loop. Each turn the model emits a batch of tool calls, the harness runs them in parallel and hands the raw results back to the same model, which picks the next step: another batch, a question for the user, or the answer. Limits such as turn and cost budgets and write gates live in the harness, and a verifier can check the answer at the end.
Progressive disclosure is what makes it work. The agent only sees short descriptions of skills and tools and pulls in the full content when it needs it, through skills and tool search. That removes the main reason teams split work across subagents in the first place: everything would not fit in one prompt. Anthropic offers its own data point: it cut Claude Code's system prompt for its most capable models by more than 80%, partly by loading skills and tools only when needed.
The other argument is the models themselves. According to the guide, starting with Opus 4.5 models could handle far more in a single loop than most teams expected, and current models narrate their progress and check their own work, which makes some harness layers redundant. The model that writes the plan is the one carrying it out, so it can change course mid-task.
| Orchestrator with subagents | One loop with skills and tool search | |
|---|---|---|
| Context | One per subagent; summaries get passed around | One shared window; nothing lost between steps |
| Plan | Fixed by the orchestrator or by code | Written and revised by the model itself |
| Team knowledge | In each subagent's prompt | In skills loaded on demand |
| Latency | A nested model loop per call | A single loop; one customer measured roughly 2x faster runs |
| Ownership | Each team owns an agent | A small central team owns the prompt and the eval; each team owns its skills |
One limit worth designing around: Anthropic says tool choice tends to degrade once you pass 30 to 50 tool definitions in the prompt. Hence its advice to group tools by user intent rather than one per API, and to defer the rest behind tool search.
When a subagent still earns its keep
The guide names three clear cases: the single loop shows measurable degradation from context bloat, tasks can run in parallel in fresh context windows that are thrown away afterwards (research, independent verification), or the agent struggles to pick the right tool or the system prompt carries conflicting instructions. Even then, it suggests the main agent call the subagent as a tool with a shared response schema instead of handing over the conversation.
The rule for splitting changes too: divide by context, not by problem type. A subagent should get work that needs little from the rest of the system and return a compact result.
Migrating without breaking what works
Anthropic's order is to measure first (ten golden examples are enough to start), merge the subagents that always run in a chain, then fold the rest in one at a time against the same eval. The most useful warning in the article comes from its own test on a support agent: folding one subagent in cut latency but broke a flow that had been passing. The main agent held the order lookup tool and answered on its own, without asking the shipping specialist for the delivery date. The failure showed up in only one of two runs, so every eval task needs more than one run.
That is what single-agent-loop-kit is for, under the Apache-2.0 license. It ships a Claude Code skill that audits your subagents and gives each a verdict (fold, merge, call as a tool or keep), scripts to compare runs, and a sample support agent with a router and six subagents. The first check needs no API key and spends no tokens:
git clone https://github.com/anthropics/single-agent-loop-kit
cd single-agent-loop-kit/examples/support-desk
KIT_MODEL=fake python3 evals/run_eval.py --variant smokeTo use it on your own system, copy the skill folder into .claude/skills/single-agent-loop in your agent's repo and ask Claude Code to run it. It stops after the audit, before every paid run (with a token estimate) and after each change.
What doesn't carry over
The 2x figure comes from a single customer, and Anthropic does not publish the comparison or the workload. The kit is candid about its own maturity: it is an unmaintained reference implementation, tested only on the bundled example, by one person on one model, and the merge and upkeep steps have not been run against a real model. What does line up with outside data is the direction: a Vals study cited by The Decoder found agent teams can be faster but not better, and that going from 10 to 30 or 100 agents raised costs with no quality gain.
My take: if your agent is an org chart with an orchestrator on top, the question is no longer how many specialists to add, but which ones survive an honest eval against a skill.
Sources
- Building agents: When to fold subagents into your main agent loop, Anthropic, October 22, 2026.
- single-agent-loop-kit, Anthropic on GitHub.
- Anthropic says one AI agent beats many subagents now that models can handle complexity alone, The Decoder, October 25, 2026.