Anthropic Advises Cutting Half Your Subagents: One Loop Ran Twice as Fast

Anthropic has published an article on when to fold subagents back into an agent's main loop. The authors are the Applied AI team, which sees enterprise deployments from the inside. Their conclusion is provocative: a single agent with skills often beats both the "one prompt for everything" setup and an architecture with a pile of subagents on quality. It is also cheaper and faster. At one client, a single loop ran about 2 times faster than a multi-agent harness. At another, a dozen specialist subagents in a customer-facing agent broke the brand's consistent tone and added latency.

Why subagents mirror the org chart

The central observation sounds almost like Conway's law: an agent's architecture copies the structure of the company. Each team builds its own subagent, and a platform team puts an orchestrator on top. A set of predictable problems then piles up:

• context gets lost when it is handed off between agents;
• hundreds of overlapping subagents appear, with no standards and no owner;
• the system prompt turns into a "Frankenstein prompt" to which every team has added a sentence;
• each team's local evals become the basis for management decisions, even though they do not show system-level quality;
• latency grows, because every hop between agents is a separate model call.

From a token-economics standpoint, the picture is simple. Every handoff means retelling the context, duplicating instructions and running an extra round of inference. You pay for all of it twice: in money and in response time.

One loop instead of an orchestra

The recommended setup looks modest. One loop, one context window, hard limits on the number of turns and on budget. On top of that come four engineering techniques:

• Progressive disclosure. The model sees only short descriptions of skills and tools and loads the full texts as needed. This is how Anthropic cut Claude Code's system prompt by more than 80%.
• Grouping tools by user intent, not by API. Tool selection starts to degrade after 30–50 tool descriptions, so three dozen thin wrappers around REST methods perform worse than a dozen tools that match real tasks.
• Permission checks inside the tools. If access is missing, the tool returns a clear refusal to the model. That lets one loop serve users with different access levels, with no need for separate agents for each role.
• Central ownership of quality. One small team owns the system prompt and the overall quality. The other teams own skills and tools, not agents.

Subagents are not outlawed, though. Anthropic names three cases where they are justified:

• there is measurable degradation from bloated context;
• you need parallel tasks with a fresh context;
• the agent gets confused by tools and contradictory instructions.

There is one condition: split subagents by context, not by task type. Splitting by task type produces a "game of telephone" in which each link slightly distorts the original request.

Migration: from examples to skills

The article describes the steps quite concretely:

• First, collect examples. Even 10 is enough; they become your before-and-after comparison set.
• Merge the most-used and most tightly coupled subagents.
• Call the remaining ones as tools, not as standalone agents.
• Turn them into skills one at a time, comparing the results against the reference examples after each step.

For this, Anthropic has put a migration kit on GitHub, including a skill that helps walk through the process.

If you run an orchestrator with a dozen specialists in production, start by measuring: response time, number of model calls and cost per typical request, then compare against a single loop on the same 10 examples. Separately, check whether your tool descriptions are bloated: if there are more than 30–50, grouping by intent will pay off even before any architectural rework. The organizational takeaway is as blunt as the technical one: teams stop being owners of agents and become owners of skills and tools.

The story is telling for the whole industry. Last year, orchestrators and multi-agent systems were the dominant trend; now they are being rebuilt like legacy code. The author of the Telegram write-up notes that OpenAI reached similar conclusions in its post about its Forward Deployed Engineers.