Anthropic Warns: Single Agent with Skills Beats Complex Sub-Agent Architectures

Anthropic's Applied AI team, after comparing multiple enterprise agent deployments, concludes that a single agent equipped with Skills often delivers higher output quality, lower cost, and lower latency than complex sub-agent architectures. The team identifies three specific conditions where retaining a sub-agent is justified: (1) measurable performance degradation due to context bloat in a single loop, (2) high-concurrency tasks that each require a fresh, independent context window, and (3) tool overload or instruction conflicts where a single agent struggles to select among too many tools or where system prompts begin to contradict each other.

If none of these conditions hold, the article warns that blindly adopting multi-agent designs leads to five common failure modes: context loss during handoffs, sub-agent proliferation (hundreds of overlapping agents with no clear ownership), stitched-prompt conflicts, localized evaluations that miss end-to-end quality, and high latency — with one customer measuring the single-agent loop running roughly twice as fast as the multi-agent alternative.

Solution: Progressive Disclosure in a Single Loop

Instead of an orchestrator plus sub-agents, Anthropic recommends returning to a single agent that uses progressive disclosure — loading Skills and tools on demand via Tool Search. The agent initially sees only brief descriptions; full context is loaded only when needed. This works today for three reasons: shared context yields richer answers because the model sees every prior step; progressive disclosure prevents context bloat (Claude Code reduced its system prompt by over 80% using this technique); and newer models (Opus 4.5, Opus 5.5, Fable 5.1) handle far more work in a single loop, making rigid multi-agent structures a barrier to leveraging improved model capabilities.

Ideal Single-Loop Design

One model, one context window, running an open-ended tool loop; a harness enforces turn limits, cost budgets, and write-operation guards.

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 the next step.

The loop stops when the model answers or hits a budget; optional targeted checks or verifiers can run afterward.

The model writes its plan into context on the first turn and revises it as results arrive — planning and execution are done by the same model, enabling mid-course corrections.

Context loading is managed by the agent itself.

Four-Step Migration from Orchestrator + Sub-Agents

Step 1: Establish Task-Completion Evaluations

Build a shared end-to-end eval set (even 10 golden examples is a start). Track routing accuracy while the orchestrator exists; after consolidation, track whether the agent loads the right Skills or calls the right tools. Gradually shift to task-completion metrics as the primary quality signal. For hard-to-replay systems, timestamp key events and replay them for targeted evaluation.

Step 2: Merge Tightly Coupled Domain Agents First

Before the first merge, create a small end-to-end eval set. Identify sub-agents that share context — those whose outputs chain together, access the same data, or are frequently invoked in sequence — and merge them into a single domain agent. Prioritize the most frequently used sub-agents.

Step 3: Demote Retained Sub-Agents to Tools (Transition)

For sub-agents that meet one of the three retention criteria, have the main agent call them as tools. This preserves the main conversation flow; full handoff is only needed when the sub-agent must speak directly to the user. This step provides a baseline for task-completion evals without rewriting the sub-agents, though it retains per-agent prompts, lossy summaries, and added latency from nested loops.

Step 4: Fully Decompose into Skills and MCP Tools

One sub-agent at a time, convert its prompt into Skills and its API calls into MCP (Model Context Protocol) tools, folding them completely into the main agent. Compare retention vs. consolidation with evals, watching not just aggregate scores but which specific tasks flip outcomes. In a test on a sample support agent, merging two sub-agents cut latency but caused a previously passing flow to fail because the main agent held the order-lookup tool and answered without asking the delivery specialist for the arrival date. Ensure eval coverage includes every production call chain and every inviolable rule; run each task at least twice because flaky failures may appear only intermittently.

Organizational Collaboration: Multiple Teams Building One Agent

After decomposition, business teams deliver three asset types to a lean central team that owns end-to-end quality and the system prompt:

MCP Tools (actions, real-time data, fixed-structure returns)

Group tools by user intent, not one-per-API; beyond 30–50 tool definitions, model selection degrades. Use tool search with lazy loading; keep hard preconditions minimal and push required checks inside the tool (e.g., a tool that depends on another's output verifies the prerequisite and returns a model-readable instruction). Enforce user-level permissions inside each tool so a single loop serves all permission tiers without separate agents.

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

Skills capture how a team works. Anthropic lets the Skill authors maintain their own Skills, using Claude to build, test, and refactor them. To prevent sprawl, each team's Directly Responsible Individual (DRI) ensures Skills are well-designed, distinct, and accompanied by appropriate evals. Tooling includes /skill-creator for authoring, reviewing, deduplicating, and restructuring Skills, and /skill-doctor for cost and usage analysis to prune unused entries.

Knowledge Bases (occasional static reference material)

Store policies, metric definitions, product specs, and other factual references behind search or lookup tools, or as reference files attached to Skills. Avoid retrieving them via code and pasting into prompts.

Closing Principle

As models evolve, best practices will shift. The enduring engineering principle: establish a measurement baseline, change one variable at a time, and keep only what survives eval validation. Teams need not migrate all at once — start today with a 10-example end-to-end eval set, pick the most-used sub-agent, attempt consolidation, and repeat.