Anthropic now tells teams to fold subagents into one agent loop. One customer saw about 2x faster runs

The router, the planner and a dozen specialist agents may be doing work the model no longer needs done for it.

What happened

Anthropic published guidance on when to fold subagents back into the main agent loop. Its Applied AI team says that across several enterprise deployments, a single agent with skills frequently beat both the one-prompt-for-everything design and the subagent design on quality, often at lower cost and latency per task. One customer that compared its multi-agent harness against a single agent loop saw roughly 2x faster runtime.

The article names the failure modes: details lost at every handoff, subagent sprawl with no owner, and the "Frankenprompt", where every team adds a rule to the system prompt until the rules conflict. Its suggested design is one model and one context window running a tool loop, with turn and cost budgets and write gates set in the harness. Procedures move into skills, hard limits like validation and approval gates move into tools, and reference material sits behind a search tool.

Subagents still make sense when context bloat measurably hurts performance, when tasks need to run in parallel, or when one agent struggles to pick tools. Anthropic also notes tool choice tends to degrade past 30 to 50 tool definitions, and warns against merging blindly: in one support agent test, folding a subagent in lowered latency but broke a process that had been passing, and the break showed up in only one run out of two.

My take

A lot of client agent builds I see copy the org chart: a sales agent, a support agent, a billing agent and a router on top. Each handoff is a summary, and summaries drop the detail the next step needed.

What I would take from this for small business builds:

1. Start with one agent and a short system prompt. Add a second agent only when you can show the first one failing.
2. Group tools by job, not by API endpoint. Ten well named tools beat forty thin ones.
3. Put the rules that must never break inside the tool, not in the prompt. A refund tool should refuse a refund above the limit on its own.
4. Before you merge or split anything, build ten golden test cases and run each one more than once. A change that passes once can still fail on the second run.

Simpler loops are also easier to move to the next model, which matters when prices and models change every month.