Anthropic Warns: Sub-Agents Hurt Performance — Single Agent + Skills Wins

Many enterprise teams building Agents — even those using Claude Code — habitually create dozens or hundreds of "expert sub-agents" organized by business unit or department, believing this yields clean architecture. Anthropic's Applied AI team, after comparing multiple production deployments, now advises against this trend: a single Agent equipped with Skills often delivers higher output quality, lower per-task cost, and lower latency than a complex sub-agent hierarchy.

Why Multi-Agent Architectures Become Complex and When to Simplify

Enterprise Agent designs often grow by layering: intent classifier → fixed multi-step reasoning → user-segment paths → separate recommendation branches → top-level multi-agent orchestrator. One customer-service Agent contained 12 expert sub-agents, causing inconsistent brand tone and significantly increased latency that damaged user experience. The feedback across such designs is that most architectures perform work "no longer necessary" for the model . Today, a clear system prompt, 4–5 lightweight data tools, and strict output constraints cover most use cases.

Organizations frequently mirror their org chart in Agent architecture — a manifestation of Conway's Law — splitting sub-agents by team or problem type rather than technical need.

Sub-agents are not without value, but should be retained only when at least one of three conditions holds:

Context bloat causing measurable performance degradation: a single Agent loop's context grows so long that quality drops detectably.

High concurrency with independent contexts: multiple tasks run in parallel, each needing a fresh, disposable context window.

Tool overload or instruction conflicts: a single Agent struggles to choose correctly among a massive tool set, or system-prompt instructions start contradicting each other.

If none of these apply, blindly adopting multi-agent architectures in large organizations leads to five common failure modes:

Context loss: deciding what information passes between agents; details disappear during handoffs.

Sub-agent proliferation: every team ships its own sub-agent, yielding hundreds of overlapping agents with no unified standards or clear ownership.

Prompt conflicts: each team adds rules to the system prompt; final rules clash and overall tone becomes fragmented.

Localized evaluation: teams over-optimize only their sub-task; no one maintains a full end-to-end eval set, so leadership sees diluted scores that don't reflect true end-to-end performance.

High latency: multi-agent hops are extremely slow. One customer measured the single-Agent loop running at roughly 2× the speed of the multi-agent architecture.

Solution: Progressive Disclosure in a Single Agent Loop

For cross-team collaboration, replacing "orchestrator + sub-agents" with a single Agent that uses progressive disclosure — loading context and tools on demand via Skills and Tool Search — is often more effective. The Agent initially sees only brief descriptions; full content loads when needed.

This works today for three core reasons:

Shared context yields better answers. For long-running Agents, keeping all prior step results in the main context window lets the model connect them, producing richer content and deeper insights than summaries returned from sub-agents. This also means fewer context windows and fewer lossy handoffs.

Progressive disclosure prevents context bloat. Teams can let one Agent handle many task types without stuffing all context into a massive system prompt up front. This removes the primary historical reason for splitting work across sub-agents. The Claude Code team reduced their system prompt for newer models by over 80% (see https://claude.dev/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models/), partly by applying progressive disclosure to Skills and tools.

Models are more capable. Starting with Opus 4.5, models handle far more work in a single loop than most teams expect. Opus 5.5 and Fable 5.1 cannot disable thinking. Recent models increasingly self-report progress and self-check during work, making some harness mechanisms redundant. Each new generation lets you shift more decisions from harness to model. Simpler loops also migrate more easily to the next model generation; rigid multi-agent structures often block new models from taking on more work.

A single Agent loop requires careful design and maintenance: system prompt must be curated, Skill/tool descriptions must trigger at the right moments, and context window, memory, and scratchpad must be managed well. A small central team should own end-to-end quality and the system prompt, reviewing every new tool and eval before release; a lean central team enables fast iteration and reduces coordination overhead in large orgs.

If you choose the multi-agent route, start with the simplest viable pattern — e.g., generator + verifier, or orchestrator + sub-agents. When drawing boundaries, split by context : work given to each sub-agent should barely depend on the rest of the system and return a concise result. Independent research paths, cleanly interfaced components, and black-box verifiers are good candidates. Splitting by problem type forces agents to play telephone; each handoff degrades fidelity.

Ideal Single-Loop Design

Many teams already run an orchestrator with expert sub-agents in production. Applied AI recommends evolving toward this single-loop design:

One model and one context window run an open-ended tool loop; the harness enforces turn limits, cost budgets, write-operation limits, and other constraints (see https://platform.claude.com/docs/en/build-with-claude/task-budgets).

Each turn, the model emits a batch of tool calls; the harness executes them in parallel and returns raw results to the same model, which then decides whether to call more tools, ask the user, or answer.

The loop stops when the model answers or hits a budget. Optionally, a targeted checker or verifier can run after answer generation.

The model writes its plan into context on turn one and revises it as results arrive. This is the key difference from orchestrator + expert agents: the same model plans and executes, so it can modify the plan mid-execution.

No more code rewriting plans from a rule checklist — every step is model-decided.

Execution order and domain workflows move into Skills.

Hard constraints (validation, approval gates, mid-conversation needs like memory lookup) move into tools.

Code still loads low-cost, almost-always-relevant content (e.g., entity resolution steps) and handles mechanical work inside loop-called tools (request building, stream parsing, resuming after clarification).

Context still loads, but the Agent manages it itself.

This design also supports the end state many teams want: an Agent that understands high-level user goals and acts autonomously, because all accumulated information stays in one context.

Practical Guide: Migrating Sub-Agents Back into the Main Loop

If you're running "orchestrator + expert sub-agents" in production, migrate in four phases:

Step 1: Use Task-Completion Evaluation to Decide Sub-Agent Fate

Build an eval suite to judge whether a given sub-agent belongs in the main loop. Applied AI sees a working structure: a central team owns a shared end-to-end eval set; each team contributes a smaller eval set for its own Skills. Even 10 golden examples are enough to start. Scoring the Agent's final reply with a rubric is a good quality baseline. While the orchestrator exists, track routing accuracy to confirm it picks the right sub-agent; after consolidation, check whether the Agent loads the correct Skills or calls the right tools. Gradually shift to task-completion eval because "task finished" matters most when comparing architectures. In environments where internal systems are hard to replay or user interactions hard to simulate, Anthropic timestamps key events and later replays them for targeted evals.

Step 2: Merge Tightly Coupled Domain Agents First

Evolve toward a single loop by folding sub-agents back into the main loop, replacing them with tools and Skills. Before the first merge, establish a small end-to-end eval set. Then determine merge candidates by shared context, starting with the most frequently invoked sub-agents . Merge expert agents whose outputs chain together, that access the same data, or that are often called in sequence. For example, if production traffic shows a significant fraction of calls go to expert A then immediately to expert B, those two are tightly coupled and can become a single domain agent.

Step 3: Transition Retained Sub-Agents to "Tools" During Transition

If a sub-agent meets one of the three retention conditions, let the main Agent call it as a tool. This keeps the main Agent in continuous dialogue with the user. Full handoff (sub-agent takes over conversation) is only recommended when the sub-agent must speak directly to the user; all other cases can be handled by Skills + tools in the main loop. This lets you define a uniform response structure for sub-agents, lets the main Agent verify conclusions against real data, and trims the final summarization input. It's a good first step because you don't have to rewrite the sub-agent yet, and you can capture a baseline task-completion eval score before deciding which to fold in. However, three problems remain: each expert still has its own prompt, context, owning team, and eval set; each call returns a lossy summary; each call is a nested model loop adding latency.

Step 4: Fully Decompose — Convert Sub-Agents into Skills and Tools

Process one sub-agent at a time: turn its prompt into Skills, turn its API calls into MCP tools , and fold it completely into the main Agent. Compare eval results for the retained-sub-agent version vs. the folded-in version before deciding. Look beyond aggregate scores — check which tasks flip outcomes. In a test on a sample customer-service Agent, merging one sub-agent into another reduced latency but caused a previously passing flow to fail: the main Agent held the order-lookup tool and answered without asking the delivery expert for the delivery date. Before each change, ensure the eval set covers every Agent call chain that runs together in production and every rule the Agent must never violate. Run each task at least twice because the above regression appeared in only one of two runs.

Organizational Collaboration: How Multiple Teams Build One Single Agent

After decomposition, business teams deliver "knowledge bases, Skills, and MCP tools" instead of independent Agents, all reviewed by a small central team before release. Maintenance standards for the three asset types:

MCP Tools (execute actions, read real-time data, return fixed structures)

Use tools when the Agent must perform actions, fetch live data from systems, or return results in a fixed schema. During migration, you can still call a sub-agent via a tool. Group tools by user intent, not one tool per API — beyond 30–50 tool definitions in the system prompt, models struggle to pick correctly. Use tool search and lazy-load tools. Minimize hard preconditions; keep necessary ones inside the tool. Example: if tool Y depends on X's output, Y's tool checks for that output and returns a model-readable instruction. User-level permissions work the same way: each tool checks caller rights and returns a clear refusal the model understands, so one loop serves all permission levels without per-level Agents.

Skills (carry business steps, rules, judgment methods — formerly expert Agent prompts)

Use Skills when the Agent needs to know how a team works — the steps, rules, and judgment methods that used to live in expert sub-agent prompts. Anthropic scales its Skills library by letting Skill authors maintain their own Skills; Claude can build, test, and refine other Skills, doing the heavy lifting. To prevent uncontrolled Skill growth, assign each team's Directly Responsible Individual (DRI) to manage their Skills, ensuring they are well-designed, clearly distinct, and accompanied by appropriate evals. Two helper commands: /skill-creator helps write well-structured new Skills and reviews existing ones for simplification, deduplication, and reorganization. /skill-doctor shows cost and actual usage frequency for each Skill entry and removes unused ones.

Knowledge Bases (store occasionally needed static reference material)

Knowledge bases suit facts and references the Agent needs only occasionally — policies, metric definitions, product specs. Place them behind search or query tools for on-demand model access, or embed them as reference files in Skills. Avoid retrieving via code and pasting into prompts.

Conclusion

As models evolve, best practices will keep refreshing. Engineering principles matter more than any single architecture: establish a measurement baseline, change one variable at a time, keep only what survives eval validation.

Simplifying a multi-agent architecture doesn't require a big bang. You can start today: build a tiny end-to-end eval set with 10 examples, pick the most-used sub-agent, and try folding it into the main loop. Only keep it if the folded-in version scores demonstrably lower; otherwise replace it with Skills and tools. Then repeat.