Related: Anthropic's Claude Managed Agents dynamic workflows go the other direction, fanning out to up to 1,000 subagents. This post explains when that is the wrong move.
Anthropic's Applied AI team published a piece on October 22, 2026 with a blunt message for anyone running multi-agent systems on Claude Platform: a lot of enterprise agents have too many subagents. Their finding across several enterprise deployments is that a single agent with skills frequently beat both the one-giant-prompt design and the subagent design on quality, often with lower cost and latency per task.
This is not an anti-subagent post. Anthropic still uses them in its own multi-agent research system. The point is narrower and more useful: stop adding a subagent for every team or problem type, and fold routers, planners and domain specialists back into one loop where the model can see everything. This guide walks through the argument, the migration path, and the checks to run so you do not break what works.
TL;DR: fold or keep? #
| Situation | Anthropic's suggestion |
|---|---|
| Router, intent classifier, fixed multi-step pipeline in front of the model | Fold into the loop; let the model plan |
| One subagent per team or problem type | Fold into skills plus tools; one team owns quality |
| Two specialists that chain on each other's output or touch the same data | Merge first, then consider folding |
| Context bloat measurably hurts a single loop | Keep a subagent |
| Independent tasks that benefit from fresh, disposable context windows | Keep subagents (parallel work) |
| Agent picks wrong tools or follows conflicting instructions | Keep a subagent |
| Subagent must talk to the user directly | Full handoff is acceptable; otherwise call it as a tool |
Why enterprise agents drift into subagent sprawl #
Anthropic describes a familiar path. Several teams each own a capability, so each builds an agent. A platform team then adds an orchestrator on top, either as an orchestrator-subagent structure or by exposing the team agents as MCP tools. It looks like the simplest answer, and it brings five problems:
- Context management. You must decide what gets exchanged between agents, and details are lost in the back and forth.
- Subagent sprawl. Every team ships its own, leaving hundreds of overlapping subagents with no standards and no owner.
- The Frankenprompt. Every team adds a sentence to the system prompt, producing conflicting rules and no consistent voice.
- Overly local evals. Everyone optimizes a subtask score, no one owns the whole set, and leadership reads watered-down numbers.
- Latency. One customer that compared its multi-agent harness against a single loop saw roughly 2x faster runtime with the single loop.
Anthropic's summary is that the architecture ends up as a copy of the org chart, which is Conway's law applied to agents. One company it mentions found that a dozen specialist subagents inside a customer-facing agent made an on-brand experience hard to keep consistent and added latency that hurt users.
The case for one loop with progressive disclosure #
The alternative is a single agent that sees short descriptions of skills and tools and loads the full content only when it needs it. Anthropic gives three reasons this works.
Shared context beats summaries
For longer-running work you want the results of several steps in the same window. An agent that has seen every earlier result can connect them, which produces richer output than a set of summaries returned by subagents. Anthropic also describes the "telephone game": when agents are split by problem type, each handoff degrades fidelity. A ribbon passing through a window with its far end fading, illustrating a shared agent context window
Progressive disclosure prevents bloat
Context bloat was the main historical reason to split work across subagents. Skills and tool search remove it, because the system prompt does not have to carry everything. Anthropic says it cut Claude Code's system prompt for more advanced models by over 80%, including cuts tied to progressively disclosing skills and tools. For the mechanics, see our guide on thin prompts and thick artifacts and the Claude 5 context engineering notes.
Models can hold more of the plan
Anthropic argues models since Opus 4.5 manage far more in one loop than most teams expected, and says thinking cannot be turned off on Opus 5.5 and Fable 5.1. Recent models narrate progress and check their work, which makes some harness elements redundant. Rigid multi-agent structures were often what stopped a new model from doing more of the work during migrations Anthropic has helped with.
What the target design looks like #
Anthropic's suggested end state is one model and one context window running an open-ended tool loop, with limits set in the harness (turn and cost budgets, write gates):
- Each turn, the model emits a batch of tool calls.
- The harness runs them in parallel and returns raw results to the same model.
- The model decides the next step: another batch, a question to the user, or an answer.
- The loop stops when the model answers or hits a budget. An optional goal or verifier check can run afterwards.
The model writes its plan in context on turn one and revises it as results arrive. That is the key change from an orchestrator setup: the planner and the executor are the same model, so it can change the plan mid-turn.
A green dot traveling around a circular loop of steps, showing the single agent loop
Where things move:
| Old home | New home |
|---|---|
| Code that rewrites the plan from a rules catalog | The model decides each step |
| Ordering and domain procedure | Skills |
| Hard limits, validation, approval gates, memory lookup | Inside tools |
| Cheap, almost always relevant data (e.g. entity resolution) | Code step before the loop |
| Payload construction, stream parsing | Inside tools the loop calls |
How to migrate in stages #
Step 1: build a small end-to-end eval first
Ownership matters here. Anthropic suggests one shared end-to-end set owned by a central team, plus small evals shipped by each team with its skill. Even 10 golden examples is enough to start.
Grade the final message against a rubric. While an orchestrator still exists, also track routing accuracy. After folding, check whether the agent loaded the right skill or called the right tool. For environments that are hard to replay, Anthropic records timestamps on important events so they can be replayed later as targeted evals.
Step 2: merge coupled specialists
Fold by shared context, starting with the most used subagents. If a large share of production traffic is one specialist followed by a second, or two specialists touch the same data, merge them into one domain agent.
Step 3: call remaining subagents as tools
If a subagent survives, let the main agent call it as a tool so the main agent keeps the conversation. Reserve full handoff for subagents that must talk to the user directly. This lets you define a shared response schema, verify conclusions against real data, and gives you a baseline on the eval without rewriting anything. Failure modes remain: separate prompts and owners, lossy summaries, and nested loops that add latency.
Step 4: fold one subagent at a time
Turn each subagent's prompt into a skill and its API calls into MCP tools, then compare eval results with and without it.
A long folded cream ribbon passes through a wide green ring, depicting long context in one loop
Do not look only at the average. Anthropic tested this on a sample support agent, and folding one subagent into another lowered latency but broke a process that had been passing: the main agent held the order lookup tool and answered by itself, without asking the shipping specialist for the delivery date. Its advice: make sure the eval has a task for every chain of agents that runs together in production and for every rule the agent must not break, and run each task more than once. The break showed up in one of two runs.
Tools, skills and knowledge bases: what goes where #
Tools fit actions, live data and fixed-shape results. Group them by user intent, not one per API, because tool choice tends to degrade past about 30 to 50 definitions. Use tool search with deferred . Put hard preconditions inside tools: if Y needs X's output, Y's tool checks and returns an instruction the model can act on. Per-user permissions work the same way, with each tool returning a plain refusal when the caller lacks access, so one loop can serve users with different permissions without a separate agent per level.
Skills fit how a team does the work: steps, rules and judgment calls that a specialist prompt used to hold. Anthropic's approach to growing a library is to have the owning teams maintain it, with Claude doing the heavy lifting. A DRI per team owns each skill and ships it with evals. Anthropic points to /skill-creator for authoring well-formed skills and auditing existing ones, and /skill-doctor for seeing what each skill costs and how often it is used.
Knowledge bases fit reference material needed only some of the time: policies, metric definitions, product specs. Keep them behind a search or lookup tool, or as reference files in a skill, rather than having code paste them into prompts.
Who should own what #
The recommended split is a small central team that owns end-to-end quality and the system prompt and vets every new tool, skill and eval. Product teams shift from owning agents to owning skills and tools. Keeping the central team small helps iteration speed and lowers coordination cost.
If you do go multi-agent, start with the simplest pattern that could work (generator-verifier or orchestrator-subagent) and divide by context: give each subagent work that needs little from the rest of the system and returns a compact result, such as independent research paths, components with clean interfaces, or black-box verification.
Anthropic's migration kit #
Anthropic ships a set of Claude API skills and a migration kit that chains them in a guided workflow, with a demo on a mock system:
| Skill | Use |
|---|---|
| `/claude-api build-eval` | Create the first end-to-end eval or per-skill evals |
| /claude-api prompt-audit | Flag instructions written for older models and propose diffs |
| /claude-api hillclimb | Iterate on prompts, skills and tool descriptions against an eval; useful for the folded vs kept comparison |
| /claude-api cost-optimize | Profile calls and propose savings: caching, trimmed tokens, effort, model choice |
explainx.ai's read #
The advice is credible because it ends on measurement, not ideology. "Fold one, compare, keep it as a subagent only if the folded version scores worse" is a rule anyone can run this week. Two cautions. First, the evidence is Anthropic's own account of enterprise deployments, with no public numbers beyond the roughly 2x latency figure from one customer and the over-80% system prompt cut, so treat the size of the gains as unverified for your workload. Second, Anthropic sells the model that makes this advice work. If you run a weaker model, the planning you move into the loop may not hold.
If you are choosing between patterns, our write-up on Managed Agents dynamic workflows with up to 1,000 subagents shows the parallel case where subagents clearly earn their place. When agents act with real permissions, a single loop also concentrates risk, so put the write gates Anthropic describes in the harness; see Microsoft's agentic insider guidance and how the Claude Code team does code review. For agent action-gating, explainx.ai's team also builds AgentBeam, an agent security platform.
Sources #
- Anthropic Claude Resources, "Building agents: When to fold subagents into your main agent loop" (Diane Sarkis, October 22, 2026)
Details reflect Anthropic's article as published on October 22, 2026; model names, skill commands and guidance may change.