This summary offers guidance on when and how to consolidate systems with multiple subagents into a single main agent loop. Anthropic has recently found that single loops can perform better in enterprise settings on quality, cost, and latency. The document explains when subagents remain useful, the benefits of moving to one loop, and how multiple teams can contribute effectively to a single agent.

1. The Role of Subagents—and a New Perspective 👀

Subagents, each with its own context window, tools, and instructions and managed by a coordinator, have been a central element of agent design. They are especially useful for verification, parallel work, and modular permissions. Anthropic has used them in many agents, including its multi-agent research system.

Recently, however, its Applied AI team has observed a pattern: folding routers, planners, and domain subagents into the main loop can deliver substantial benefits in enterprise deployments. Across several deployments, a single agent with skills 🧑‍💻 significantly outperformed both "one prompt for everything" and subagent designs in quality, often with lower costs and latency.

For example, one company had dozens of specialized subagents inside a customer-facing agent. This made a consistent brand experience difficult and introduced delays that harmed the user experience. ⏱️

Anthropic identified a common pattern: an intent classifier, a fixed multistage reasoning pipeline, user-segment buckets, separate recommendation branches, and a multi-agent orchestrator on top. Feedback often suggested that much of this structure was doing work the model no longer needed. In many cases, a clear system prompt, four or five concise data tools, and firm output guardrails covered most use cases.

Subagents still clearly earn their place in some situations, particularly when:

• A single agent loop suffers measurable degradation from context bloat. 📉
• Multiple tasks need parallel execution in fresh context windows that can be discarded afterward.
• One agent struggles to select the right tools or has conflicting instructions in its system prompt.

But Anthropic has often found companies assigning a subagent to every team or problem type, causing the architecture to mirror the organization chart—Conway's law. This article explains when to fold those subagents into the main loop and the best practices for doing so.

2. How Agent Building Goes Wrong in Large Organizations 🚨

Companies often want an agent that combines multiple products and capabilities in one customer interface. Since separate teams usually own those capabilities, they begin by having each team build an agent, then ask a central platform team to build an orchestrator above them. This can take several forms, including an orchestrator-subagent hierarchy or a single agent with some agents exposed as MCP tools.

Although it looks like the simplest solution, it immediately creates complexity:

• Context management: Teams must decide what context to pass between agents, often losing details.
• Subagent sprawl: Every team ships its own, leading to hundreds of overlapping subagents without standards or clear ownership.
• Frankenprompts: Each team adds another sentence to the system prompt, creating conflicting rules and losing a coherent voice.
• Unvetted, overly local evaluations: Teams add evals overoptimized for their own subtasks. Nobody owns or maintains the complete set, so leadership makes decisions from diluted, overly local scores.
• Latency: Multi-agent complexity adds delays. One customer comparing a multi-agent system with a single loop found the latter ran roughly twice as fast.

3. Using the Agent Loop with Progressive Disclosure 🔍

An orchestrator-subagent design is a reasonable way to coordinate specialists built by different teams. But a frequently more effective approach is progressive disclosure of context through skills and progressive disclosure of tools through tool search. The agent sees brief descriptions and loads full skills and tools only when needed.

There are three reasons this makes sense:

1. Shared context produces better answers: 🤝 Long-running agents need context from multiple tasks in the main window. Seeing results from every previous step lets the agent connect them, producing richer outputs and better insights than subagent summaries. It also means fewer context windows and less lossy handoffs.
2. Progressive disclosure prevents context bloat: Teams can build one agent covering a broad range of work without immediately loading everything into a long system prompt. This removes a major reason teams previously split work across subagents. Anthropic has reduced Claude Code's system prompt by more than 80% for advanced models, partly through progressive disclosure of skills and tools.
3. Models have become more capable: 🚀 Since Opus 4.5, models have been able to manage much more in one loop than most teams expected. Newer models such as Opus 5.5 and Fable 5.1 are better at explaining progress and checking their own work, making some harness components unnecessary. Each new model lets more decision-making move from the harness into the model, and simpler loops ease future model upgrades.

A single-loop design requires discipline: a carefully maintained system prompt, skill and tool descriptions that trigger at the right time, and thoughtful handling of context windows, memory, and notes.

Anthropic advises that one central team own end-to-end quality and the system prompt, reviewing every new tool and eval before release. Keeping that team small supports fast iteration and reduces coordination costs inside a large organization.

If choosing a multi-agent approach, start with the simplest patterns, such as generator-verifier or orchestrator-subagent. Decompose boundaries by context: assign each subagent work whose details the rest of the system rarely needs, and have it return a concise result. Independent research paths, separate components with clean interfaces, and black-box verification are good candidates. Splitting agents by problem type can create a game of telephone, losing fidelity at every handoff. 😥

4. How to Fold Subagents into the Main Agent Loop 🔄

Many teams already operate an orchestrator and specialist agents. Anthropic proposes moving toward a single-loop design as follows:

• One model and one context window 🧠 run an open-ended tool loop, with limits such as turn and cost budgets and write gates enforced by the harness.
• On each turn, the model emits a set of tool calls. The harness runs them in parallel and returns raw results to the same model, which chooses the next step: more tools, a question to the user, or an answer.
• The loop stops when the model answers or reaches its budget. An objective or verifier check may optionally run after the answer.
• The model writes a plan in context on its first turn and revises it as results arrive. Unlike an orchestrator-specialist setup, the model writing the plan also executes it, so it can change the plan midway.
• Context is still loaded and managed by the agent itself.
  • Because the model decides each step, code no longer needs to rewrite plans from a rules catalog.
  • Sequencing and domain procedures move into skills.
  • Hard constraints, including validation and approval gates, and other things that arise during conversation, such as memory lookups, move into tools.
  • Code can still load inexpensive, almost-always-relevant information, such as entity resolution, and handle mechanical work inside loop-called tools: constructing payloads, parsing streams, and resuming after clarification.

This design also supports the longer-term goal of agents understanding higher-level user objectives and acting on their behalf, because everything the agent learns stays in one context.

The following steps explain how to migrate gradually while letting multiple teams continue contributing.

4.1. Task-Completion Evals ✅

First, build an eval set to help determine whether subagents should be folded into the main loop. Anthropic has found a useful structure to be a shared end-to-end set owned by the central team, plus smaller sets each team ships with its skills. Even ten golden examples are enough to start.

Scoring the agent's final message against a rubric is a good starting point for tracking answer quality. While an orchestrator remains, track routing accuracy—whether it chose the correct subagent. After consolidation, check whether the agent loaded the right skill or called the right tool. Over time, move toward task-completion evals, because completion matters most when comparing architectures.

This can be complicated where internal systems are difficult to reproduce and user participation is hard to simulate. One approach that worked inside Anthropic was timestamping important events so they could later be replayed for targeted evaluations.

4.2. Reduce Subagents Gradually 📉

Evolving toward one loop means consolidating subagents into tools and skills. This can involve merging domain subagents, calling them as tools, or replacing them with skills and tools.

4.3. Combining Domain Agents 🤝

Build a small end-to-end eval before the first merge. Then consolidate by shared context, starting with the most-used subagents.

Merge specialists that depend on one another's outputs, access the same data, or are frequently called together. If much of production traffic calls one specialist immediately after another, for example, they form a tightly coupled pair and are candidates for one domain agent.

4.4. Calling Subagents as Tools 🛠️

When one of the three earlier conditions applies and a subagent should remain, letting the main agent call it as a tool can work well. The main agent can then continue the user conversation.

A full conversational handoff is recommended only when the subagent needs to speak directly with the user. Everything else can be handled through skills and tools in the main loop.

This lets teams define a shared response schema, validate conclusions against actual data in the main agent, and refine inputs to final synthesis. It is a good first step because subagents do not need to be rewritten. It also supplies a task-completion baseline before deciding whether to fold them into the main agent.

Some failure modes may remain:

• Every specialist still has its own prompt, context, owning team, and evals.
• Every call still returns a lossy summary.
• Every call is still a nested model loop that adds latency.

4.5. Folding Subagents into the Main Agent Through Skills and Tools 🧠

Fold in one subagent at a time by turning its prompt into a skill and its API calls into MCP tools. Compare eval performance with and without the subagent, then decide which version to keep.

Look beyond aggregate scores to see which tasks changed. In a sample support agent, Anthropic found that folding one subagent into another reduced latency but broke a previously successful process: the main agent used its order-lookup tool to answer independently instead of asking the shipping specialist for the delivery date.

Before each change, ensure the eval set covers every agent chain that runs together in production and every rule the agent must not violate. Run each task at least twice, because such failures sometimes occur in only one of two runs.

5. How Multiple Teams Can Contribute to One Agent 🤝

Domain reasoning can come from knowledge bases, skills, and MCP tools. Individual teams can shift from agent ownership to skill and tool ownership, while a small central team retains ownership of the system prompt and end-to-end quality. This includes reviewing new skills, tools, and evals before release.

5.1. MCP Tools 🛠️

Tools fit situations where an agent must perform an action, read live system data, or return a fixed-format result. During migration, they can also keep invoking subagents. Anthropic recommends grouping tools by user intent rather than creating one per API: tool selection tends to degrade with more than 30–50 tool definitions in the system prompt.

Use tool search with lazy loading, constrain strict prerequisites, and move the necessary enforcement into tools. If Y requires X's output, for example, Y's tool checks for it and returns actionable guidance to the model. User-specific permissions work similarly: each tool checks what the caller may see or do and returns a simple, model-readable denial. One loop can thus serve users with different access rights without separate agents for each permission level.

5.2. Skills ✨

Skills fit situations where the agent needs to know how a team works: the steps, rules, and judgments previously contained in a specialist subagent's prompt.

Anthropic's approach to growing a skill library is to return maintenance responsibility to the people writing the skills. Claude can do the heavy lifting through skills that build, test, and prune other skills.

To prevent sprawl, each team's DRI—directly responsible individual—can own its skills and ensure they are well-constructed, distinct, and shipped with suitable evals.

• /skill-creator helps write well-structured new skills and audit existing ones for refinement, deduplication, and reorganization.
• /skill-doctor shows the cost of each skill and how often it is actually used, helping remove unnecessary material.

5.3. Knowledge Bases 📚

Knowledge bases suit reference material the agent needs only occasionally. Facts and references—policies, metric definitions, and product specifications—can sit behind model-called search or lookup tools, or in reference files within skills. Avoid having code retrieve this context and paste it into the prompt.

6. Tools to Accelerate the Work 🚀

Anthropic recently released Claude API skills that support most of the work above. Its migration kit connects them into a guided workflow for evaluating and moving a multi-agent system to one loop. It also includes a demo to try before applying the approach to a real system.

• /claude-api build-eval: Helps create the central team's first end-to-end eval set or the smaller sets teams ship with their skills.
• /claude-api prompt-audit: Identifies instructions written for older models in prompts, skills, and tool descriptions, proposing edits as diffs. It can uncover legacy system-prompt rules that now slow the agent down or make it rigid. Team DRIs can also run it on their own skills and tool descriptions.
• /claude-api hillclimb: Iteratively improves an app against existing evals. It can support "fold versus keep" comparisons: fold a subagent into skills and tools, iterate on their descriptions, and check whether the consolidated version matches or beats the subagent. It can also improve the system prompt.
• /claude-api cost-optimize: Profiles where calls go and proposes savings one option at a time, including prompt caching, trimming unnecessary input and output tokens, effort settings, and model selection. It can reduce costs and latency within a given design.

As models improve, our understanding of how best to use them evolves too. That makes the underlying principles more important than any one architecture: measure, change one thing at a time, and keep what earns its place.

This is one such case. As models grow more capable and agents run longer, more subagents can become skills and tools. But the transition need not happen all at once. Build a small end-to-end eval, fold in one subagent, keep it if the consolidated version scores worse, and repeat. 😊