Official Anthropic Guide: As Models Improve, Many Sub-Agents Can Be Replaced with Skills and Tools

When an AI assistant needs to look up orders, track shipments, and handle returns, does every new capability require adding another sub-Agent?

An official guide from Anthropic recommends reconsidering this approach: as models become more capable of planning steps, selecting tools, and evaluating outcomes, much of the work previously delegated to sub-Agents can be consolidated back into a single main Agent.

Workflows originally written into sub-Agent prompts can be reorganized into skills loaded only when needed; operations like querying orders or checking shipments are handled through tools. The main Agent retains the user's original request alongside raw tool outputs, deciding which rule to consult or which data to query next.

This reduces intermediate dispatching and information handoffs while allowing business teams to maintain their specialized workflows. Real-world tasks should determine which sub-Agents can be merged and which are worth keeping.

As Models Improve, Why Build Fewer Sub-Agents?

A sub-Agent has its own context window—the set of information it can access while processing a task—along with dedicated tools and instructions. A dispatching orchestrator delegates tasks to it and collects the results.

The main loop refers to the same model repeatedly deciding the next step, invoking tools, reading results, and taking further action until providing an answer or reaching a budget limit.

Previously, teams wrapped models with external routing, planning, and verification steps to structure their work. Newer models are better at sequencing steps, communicating progress, and verifying as they go, making some of this external scaffolding redundant. Anthropic observed while helping customers migrate that rigid multi-Agent architectures sometimes constrain newer models rather than empower them. When upgrading models, it is worth re-evaluating whether legacy workflows remain necessary.

Even with stronger models, turn and cost budgets, write permissions, and result verification must still be retained. Whether to keep a given sub-Agent should be decided based on performance on specific tasks.

Anthropic's Applied AI team compared deployments across several enterprises: allowing a single Agent to use skills on demand often yielded better response quality than either stuffing everything into a single prompt or distributing work across multiple sub-Agents, typically with lower per-task costs and latency.

In one customer comparison, refactoring a multi-Agent framework into a single loop ran roughly 2x faster.

Original English animation: Hierarchical architecture vs. main loop

What Problems Arise When Agents Are Split Too Finely?

When the order team builds an Agent, the logistics team builds another, and a dispatching supervisor is placed on top, the system fragments with every added team until it mirrors the company's organizational chart. This reflects Conway's Law (system structures tend to mirror organizational communication structures) in Agent systems.

Splitting too finely typically introduces five categories of issues:

1. Details lost during handoffs: The system must decide which context to forward between Agents, and critical details easily slip through repeated paraphrasing.
2. Proliferation without ongoing maintenance: As separate teams deploy their own sub-Agents, organizations accumulate overlapping, unstandardized instances that no one actively maintains.
3. Growing rule conflicts: To safeguard specific business rules, teams append requirements to global prompts, creating conflicts and making it difficult to maintain a consistent tone and standards.
4. Isolated high scores without completing the end-to-end task: Each business unit tests only its own segment and may score high, while nobody checks whether the user's overall goal was achieved.
5. Cascading calls and longer latency: A single request passes through multiple independent model calls and handoffs, increasing user wait time.

Why do handoffs lose information? Dispatching Agents typically select a subset of information to hand off to sub-Agents; the sub-Agent processes it within its own context and returns a summary or final outcome. Using identical tools does not mean both sides see the complete execution history.

Anthropic compares this process of splitting by task type and relaying information layer by layer to the "Telephone Game": when handoffs rely on selective summaries, those summaries frequently omit background context needed in downstream steps.

In software development, writing features and writing tests often depend on the same design context.

If partitioned by problem type, a feature Agent writes code, hands off to a test Agent to write tests, which hands off to a review Agent. The test-writing Agent receives only initial implementation code and a summarized explanation without knowing why specific design trade-offs were made, easily missing critical boundary conditions.

When the same Agent writes both features and tests, it preserves the design rationale from implementation. An independent verifier (Verifier) then simply runs the test suite and reports results without needing the full derivation behind the code.

Original English diagram: Partitioning by context

Customer support exhibits the same dynamic. Consider a user request: "This order is urgent for a performance, please make sure to use express shipping; also, do not use plastic buckles in packaging." If the system splits into an order Agent and a logistics Agent, the order module generating a handoff ticket might extract only "express shipping," dropping constraints like "urgent for performance" and "no plastic buckles."

Keeping the original request and tool results within the same Agent reduces such handoff omissions. While long conversations can still overlook details and shared contexts have capacity limits, it eliminates at least one stage of filtering and paraphrasing.

How Can a Single Agent Use Skills, Tools, and Knowledge Bases on Demand?

Consolidating work into a single Agent requires avoiding stuffing every business rule and tool definition in from the start. Overly long prompts increase token consumption, dilute model attention, and increase tool selection errors.

Instead, provide a concise "directory" and load full instructions only when a capability is required. This is progressive disclosure (Progressive Disclosure). Stated user requirements and retrieved results remain in context, while unneeded business rules, tool parameters, and reference documents stay unloaded until called.

Skills instruct the Agent on how to proceed. For instance, return and exchange procedures, criteria, and decision trees can be extracted from sub-Agent prompts into skills. The main Agent views only concise summaries by default and loads the complete text only when the task requires it.

Tools query data, execute actions, or return structured responses. Examples include order lookups and logistics checks. Once the main Agent identifies the required action, it loads specific parameter definitions via tool search.

When designing tools, organize data around user goals rather than mapping one tool to every backend API. Paired with on-demand search, this prevents the model from sifting through exhaustive lists of low-level interfaces.

Knowledge bases store reference material queried infrequently. Business policies, metric definitions, and product specifications can be read via search or query tools, or referenced within skill files. Querying only as needed avoids external orchestration code injecting large background text into prompts upfront.

Anthropic found that when directly loaded tool definitions in system prompts exceed 30–50, models make selection errors more frequently. This serves as a warning to manage simultaneously loaded definitions, not an upper limit on total tools in a repository. When Claude Code streamlined its system prompt for advanced models, it achieved a reduction of over 80%, partly due to on-demand loading of skills and tools. Similarly, the 4–5 data tools shown in the original architecture diagram illustrate a specific scenario rather than a universal recommendation; actual counts depend on business needs.

If a task requires simultaneously querying basic data, checking inventory, and calculating shipping fees—and these three calls are independent without sequential dependencies—spawning three sub-Agents is unnecessary. The model can issue this batch of tool calls in a single inference step; the runtime executes them concurrently and returns raw results together to the same model.

With raw results in hand, the model decides next actions: asking follow-up questions, providing a final answer, or adjusting subsequent plans. Running tools in parallel is only possible when calls are independent, providing concurrency speed while keeping all original information in one context.

The runtime program hosting the Agent enforces maximum turn limits, cost budgets, and write permissions. Once the model delivers its final answer or exhausts its budget, the loop terminates.

Shared contexts still face capacity limits. For very long tasks, memory mechanisms, scratchpads, and proactive context management remain necessary to prevent attention degradation.

Which Tasks Are Still Well-Suited for Sub-Agents?

Anthropic identifies three scenarios where retaining sub-Agents remains worthwhile:

First, context grows too long and degrades performance. Rely on actual evaluations: when tasks run too long and information accumulates, models start missing earlier requirements and completion rates fall. Delegating relatively self-contained exploratory or data-gathering work to sub-Agents relieves burden on the main loop.

Second, tasks are well-suited for independent parallel execution with discardable context. Examples include testing multiple code modification paths simultaneously, investigating different research angles independently, or deploying dedicated verifiers (Verifier). A verifier needs only to execute tests independently and return test-result details and error messages without loading the entire implementation history, after which its session can be closed to prevent intermediate trial-and-error noise from polluting the main context.

Third, the Agent repeatedly selects incorrect tools, or instructions fundamentally conflict. If rules across business domains genuinely clash, or if tool search still yields incorrect selections, dedicated sub-Agents can isolate them. Note that the 30–50 tool threshold is an empirical heuristic, not an automatic trigger to partition into sub-Agents.

Prioritize identifying which steps require shared context before setting sub-Agent boundaries. If retaining a sub-Agent, assign it an independent task with minimal dependencies on the rest of the system that returns compact outputs. Steps that require frequent exchange of intermediate reasoning and deep sharing of underlying data belong together in the main loop.

How to Incrementally Migrate an Existing System and Verify Progress?

Existing systems can be adjusted incrementally. Begin with an evaluation suite that compares before-and-after performance, changing one element at a time.

A central team can start by curating roughly 10 golden examples (Golden Examples: representative tasks with clear expected outcomes), testing from initial user request through task completion. While checking answer quality against rubrics provides a starting point, comparing architectures requires verifying whether the underlying task was genuinely completed.

While a dispatcher is retained, check whether it selects the correct sub-Agent; after merging, check whether the main Agent loads the right skill and calls appropriate tools. These execution logs help pinpoint root causes of failure.

Original English animation: Three migration approaches

The following three approaches can be combined without following a rigid sequence:

1. Merge sub-Agents that frequently work together: Identify sub-Agents with high invocation frequency, sequential handoffs, and shared data access. When real user requests frequently jump from one specialist straight to another, merge those two first to eliminate handoffs.

2. Invoke sub-Agents as tools: If rewriting internal sub-Agent logic is not immediately feasible, let the main Agent maintain direct dialogue with the user while wrapping sub-Agents as tools called on demand. This allows standardizing return schemas and validating data within the main loop. When wrapped as tools, each sub-Agent still retains its own prompt, context, maintenance team, and local evals; each invocation requires an extra model turn, adding latency; returned summaries can still lose information. Consequently, full conversation handoffs (Full Handoff) where a sub-Agent takes over the user dialogue are recommended only when prolonged multi-turn interaction is necessary; most other cases are better served by folding into skills and tools within the main loop.

3. Fold sub-Agents into skills and tools: Convert workflows, troubleshooting steps, and rules from sub-Agent prompts into skills, and transform backend APIs into MCP data tools. Fold one sub-Agent at a time, comparing task performance on benchmark evaluations before and after; remove the legacy sub-Agent only when performance matches or improves.

After gaining speed, verify that previously successful tasks haven't broken.

When comparing architectural performance, look beyond aggregate evaluation scores and inspect whether specific test cases changed from pass to fail or fail to pass.

When Anthropic tested an example customer support Agent by merging one sub-Agent into another, latency improved, but a previously passing task failed: the main Agent answered the user directly using the order lookup tool, skipping the step to confirm delivery dates with logistics.

This regression occurred in only one out of two runs. Workflows and inviolable business rules must have targeted tests, and runs should be repeated multiple times to surface intermittent regressions.

How Should Multiple Business Teams Divide Responsibilities?

Teams continue maintaining their domain logic, shifting from "each owning an Agent" to two distinct responsibilities:

• Small Central Team: Maintains the globally unified system prompt and end-to-end evaluation benchmarks, oversees overall response style and quality, and reviews incoming skills, tools, and evaluations before deployment. Keeping this team small minimizes coordination overhead and accelerates iteration.
• Business Teams: Transform domain expertise into skill files and MCP tools, providing local evaluation sets alongside skills. The skill's directly responsible individual (DRI) maintains quality and uniqueness, periodically reviewing and deprecating duplicate or unused skills. Teams can use /skill-creator to audit, streamline, and deduplicate skills, and /skill-doctor to analyze skill costs and usage, preventing skill bloat over time.

Business constraints and permission checks can be enforced by tools and runtime harnesses:

• Tool prerequisite dependency checks: If tool B depends on output from tool A, tool B can perform internal validation. If prerequisites are missing, tool B returns an explicit message; upon reading it, the model can decide whether to invoke tool A. Note that tool validation only fires when a tool is called and cannot prevent the model from bypassing tools to output text directly; end-to-end evaluations help surface these loopholes. In production, output checks before returning a response can verify required steps: if a task mandates confirming delivery dates, ensure the step occurred; if missing, withhold the answer and prompt the Agent to complete it or state that it cannot yet be confirmed.
• User-based dynamic permissions: Systems do not need bespoke Agents for different permission tiers. Tools can directly inspect the requesting user's permissions, returning clear plain-text denial reasons when unauthorized actions are attempted. The main loop explains this directly to the user, allowing a single loop to safely serve different permission levels.

Anthropic also provides a Migration Kit that can be tested in simulated environments before applying to production Agents. It links four assistive skills:

• /claude-api build-eval: Assists in building end-to-end evaluation sets owned by the central team or generating local evaluation sets accompanying business skills;
• /claude-api prompt-audit: Audits prompts, skills, and tool descriptions for legacy rules written for older models, providing diff-based streamlining suggestions;
• /claude-api hillclimb: Iteratively tunes existing evaluation benchmarks to compare performance between folding into skills/tools and retaining sub-Agents;
• /claude-api cost-optimize: Analyzes token distribution and expense drivers, offering recommendations for Prompt Caching, trimming redundant inputs and outputs, and optimizing model selection.

As model capabilities expand, responsibilities previously handled by sub-Agents can be consolidated into the main Agent. Decide what to merge and what to keep using actual task performance: establish a compact end-to-end evaluation suite, change one piece at a time, and retain the architecture that completes tasks better.