Claude's New Guidance: Ditch Subagents for a Single Agent Loop

Title: Don't learn subagent anymore; it's likely to die out.

Author: cxuanAI

Tags: 后端, AI编程, Agent

A couple of days ago, Claude published an article titled Building agents: When to fold subagents into your main agent loop, meaning "Building agents: when to fold subagents into your main loop." This is an article well worth careful reading, because it puts forward many novel ideas.

After reading it, I felt enlightened. I hadn't expected that the multi-agent approach we're playing with now is, in Anthropic's view, already a product of a bygone era. A big wave of people working on multi-agent ideas will likely be slowly phased out...

What they're playing with now is a single Agent + Main Loop loop.

When building agents on Claude, reducing the number of subagents and adopting a progressive presentation strategy for context and tools both improves quality and lowers cost and latency.

At the start, Claude ran an ad:

Oh, when you're using multi-agent systems, you can take advantage of our migration toolkit. Our migration toolkit can automatically fold subagents into the main agent loop.

emmmm, then it gets serious.

Subagents, like the main agent, have their own context windows, tools, and instructions. Subagents are uniformly scheduled and planned by a Coordinator, which is a core component of agent design.

You'll find that as AI architectures evolve, they increasingly resemble CPU thread and child-thread design.

Claude is the one who likes this architecture best; this article also mentions that this has been the mechanism and way the Claude platform builds agents all along.

Recently, however, the Applied AI team has found a pattern in enterprise-level agent deployments.

This pattern is: integrating a Router, a Planner, and domain-specific subagents into the Main Agent Loop brings significant results.

Then Anthropic stressed that they horizontally compared multiple enterprise deployments: on quality, a single agent with multiple skills often outperforms both universal-prompt schemes and subagent schemes. In addition, its cost and latency per single task are usually lower.

Anthropic also said they've seen some agent schemes that typically follow a fairly common architectural evolution path: intent classifiers, fixed multi-step reasoning flows, user-segment-based logic, independent recommendation branches, and a multi-agent coordinator at the top.

However, in actual operation, the feedback is often the opposite; most components in this architecture are actually redundant. In fact, just a clear prompt + 4 or 5 lightweight tools, plus a robust guardrails mechanism, are enough to cover the vast majority of application scenarios.

Figure: redrawn in Chinese from the official animation.

But Anthropic didn't completely say subagents are useless; they still acknowledged some use cases for subagents, such as:

• When a single agent shows obvious performance degradation during loop execution due to context bloat;
• When multiple tasks need to be processed in parallel and can be discarded after completion;
• When a single agent has difficulty choosing the right tool, or when there are conflicting instructions in the system prompt.

However, we often see enterprises configure one subagent per team or per problem type, causing the agent architecture to end up as a replica of the organizational chart. This is exactly Conway's Law at work.

What is Conway's Law?

In plain terms: a company has a customer service department, a logistics department, and an after-sales refund department. The moment people start building AI agents, the first reaction in their heads is often to match the departments: build a customer service agent, a logistics agent, a refund agent, and then put a platform "leader" Orchestrator on top to coordinate.

On the surface, the division of labor is tight and each does its own job, but in fact this is a typical case of directly transplanting a human team's organizational structure onto an AI system architecture. LLMs passing messages to each other isn't as flexible as humans; instead, they fall into a serious "telephone game" effect. Every time information passes through a subagent's relay and summarization, a lot of detail is lost, while latency and token costs double.

So the following content focuses on how to fold subagents into the Main Loop, and then Anthropic shares some best practices.

Enterprise Agent building failure modes

Many enterprises often want to build an Agent that integrates multiple products and functions into a unified customer interaction interface.

This is usually how it's done: each capability is owned by its own team; each team develops its own Agent; then a central platform architecture group integrates these Agents. The integration process uses an Orchestrator.

There are many integration approaches, such as Orchestrator ----> Agent mode, or simpler: attach Agents directly to MCP, then integrate the MCP.

These architecture patterns look simple, but often introduce complexity:

• Context management: you need to determine what context information is exchanged between Agents, and during frequent context exchanges, some details are often lost.
• Subagent proliferation: each team deploys its own subagents, so the enterprise ends up accumulating hundreds of overlapping subagents, with no unified standard, and when something goes wrong, no one can be held accountable.
• Patchwork prompts: each team adds one sentence to the system prompt, causing conflicting rules and an inability to maintain a unified tone.
• Unreviewed and overly local evaluations: everyone adds their own evaluation metrics, each over-optimized for their own subagent. The whole evaluation system lacks a single owner or maintainer, causing management decision-makers to rely on diluted and overly local score results.
• Latency: the complexity of multi-agent architectures increases latency. Anthropic's customers found that when comparing multi-agent frameworks with single Agent + Loop architecture, the single Agent + Loop architecture is about twice as fast.

Figure: based on the five failure modes from the official article, animation added by this post.

Agent Loop using progressive presentation

We mentioned the Orchestrator ----> Agent pattern architecture above. It's actually a reasonable way to build an Agent, though not the best. But often the more effective approach is to present context through Skills and progressively provide available tools via Tool Search.

That is, the Agent initially sees descriptions of Skills and tools, but only loads their full contents when actually needed.

Side note: What's the difference between Tool Search here and what we usually call Tool Use?

(I didn't quite understand this at first, so I researched it.)

Tool Use refers to how the model calls tools. In the default approach of exposing all tools at once, you put the complete definitions, parameter types, JSON Schema, and usage instructions of these tools into the model context. When there are many tools, the instruction manual may consume a lot of tokens first. Anthropic also mentioned in the original article that after exposing more than 30 to 50 tool definitions in the system prompt, model tool selection tends to degrade.

Tool Search solves the problem of discover first, then load. It can be combined with Tool Use: 1. Start with only a small amount of content: Skills can provide short descriptions; for tools, let the model get Tool Search and a few commonly used tools, while the full definitions of other tools stay out of the model context. 2. Search and load when needed: when the model finds it needs to check an order, it first searches the tool catalog through Tool Search, and after a hit, loads the full parameter spec and description of that tool. 3. Call as usual after loading: the model then calls the order tool via Tool Use, and the result continues in the same context.

In plain terms, it changes the tool manual to on-demand retrieval. The lazy loading here controls when content enters the model context; when using the official API, the client still submits the full tool definitions for the server to search and expand.

Claude Code has reduced its system prompt for stronger models by more than 80%, including the slimming brought by progressive presentation of Skills and tools. This number is the overall reduction of the system prompt.

Figure: added as an illustration by this post; mechanism based on the official Tool Search documentation.

There are three reasons for this approach:

• Shared context helps generate better answers: for long-running Agents, we want context from multiple different tasks to remain in the main context window. If the Agent can know the results of each previous step, it can link these steps together;
• Progressive disclosure: this is a mechanism that effectively avoids overly bloated context. With this technique, teams can build a single Agent capable of handling multiple tasks without stuffing all context into the system prompt at once. Progressive disclosure removes the main reason teams previously had to split tasks across multiple subagents to cope with context limits.
• Models become more capable: Anthropic emphasizes that starting with Opus 4.5, the amount of work a model can handle in a single loop far exceeds what most teams expect. In models like Opus 5.5 and Fable 5.1, you cannot turn off their thinking (chain-of-thought) process; these models, as they execute tasks, increasingly narrate progress and self-check results, which makes some components of the existing Harness redundant. In addition, each generation of model capability shifts more decisions from the external framework to the model itself.

More model decisions may be pulled away from the Harness, and eventually only differences in model capability will remain.

Single-Agent design requires rigorous control, mainly including these details:

1. A carefully managed system prompt;
2. Skills and tool descriptions that can be triggered at the right moment.
3. Careful handling of context window, memory, and note-taking.

Therefore, Anthropic suggests having a core team responsible for end-to-end system prompt quality control, and reviewing every new tool or evaluation plan before official release.

If you choose a multi-agent architecture, you can start from a simple generator ---> verifier or Orchestrator ----> subagent pattern.

Boundaries should be divided by context: give each subagent an independent task, and return concise results after the work is done. If you split Agents by problem type, you easily fall into the situation where "three people make a tiger," and the problem gets distorted.

Figure: redrawn in Chinese based on the official static image, and handoff animation added.

How to merge subagents into the Main Loop

Currently, most enterprises and teams doing Agent work run the classic Orchestrator ──> Agents architecture (a master orchestrator with a bunch of business-specialized subagents underneath).

This architecture did hold up for a while when model reasoning was weaker and context was smaller, but now the drawbacks are increasingly obvious: detail loss is severe, and latency often doubles.

So what does the single loop Anthropic recommends actually look like? How does it manage to beat a group of subagents?

Anthropic provides a very clear blueprint for the single-loop core design:

1. Core operating mechanism: single context + open tool loop

Previous multi-agent architectures like to slice the business into tiny pieces, each subagent having its own context. The single loop's core is: use one model throughout, and maintain only one global context window.

The entire Loop runs like this: * In the first turn, after the model receives the task, it writes the execution plan directly in its own context. * Batch parallel tool calls: in each turn, the model makes a batch of tool calls based on the current execution plan. The outer Harness is responsible for concurrently calling downstream APIs and returning the rawest data directly to the model. * Plan while executing (dynamic planning): this is the biggest qualitative change from the traditional Orchestrator approach. In the past, the plan was written by an external orchestrator or hardcoded rules; now, the brain that makes the plan and the brain that does the work are the same. When the model sees the latest results returned by tools and notices changes, it can immediately revise the follow-up plan dynamically in its context. * Autonomously decide the next step: the model itself decides, based on current global information, whether to continue making the next batch of tool calls, ask the user for more details, or output a final conclusion. * Termination and fallback: when the model gives the final answer, or an external budget threshold is triggered (such as max turns or token budget consumption), the loop terminates. If the business has strict quality-check needs, you can also attach a lightweight Goal / Verifier goal-checking program after the answer.

Figure: based on the single-loop design from the official article. Order and shipping policy can be queried independently in parallel; once the logistics tracking number is obtained, then the logistics query proceeds; all results return to the same main context.

Have you noticed? This is entirely a super-brain with extremely strong self-drive and a global view solving problems independently, without any external coordinator pointing fingers.

2. Four-way division of responsibilities: model, Skills, Tools, and code

Anthropic divides the responsibility boundaries of the entire system extremely clearly here. Four components each do their own job, fully decoupled:

1. Model (Brain - global brain): Responsible for global strategic decisions and dynamic planning.
2. The model looks at feedback and revises its own plan; all the cumbersome logic that used to be hardcoded by outer code to forcibly rewrite plans based on rule catalogs can be deleted.
3. Skills (domain business SOP): The business norms, execution order, and industry guidelines that used to be sedimented in each dedicated subagent's system prompt are all distilled into Skills.
4. Adopt the progressive disclosure mentioned earlier: normally only a short description is shown; when the model determines it's needed, it dynamically loads the complete SOP of the corresponding domain.
5. Tools (capability interfaces): All real system read/write operations, data retrieval, and actions temporarily needed during conversation (such as memory retrieval) are encapsulated into Tools.
6. More critically, hard rules and security lines (such as validation logic, human-in-the-loop Approval Gates, user permission checks) all sink into Tools. If the model lacks parameters or oversteps permissions during execution, the Tool directly returns a clear interception notice; the model understands and adjusts its actions accordingly, with no need for an external permission-auditing Agent.
7. Traditional code (dirty work): Don't be superstitious that LLMs can do everything. Traditional hardcoded code still has a big role, specifically for low-cost, deterministic mechanical labor.
8. For example, use regex or lightweight logic in advance to extract entities from user input (order numbers, user IDs) and inject them directly into the context; or inside Tools, handle constructing API payloads, parsing streaming responses, and resumption. Ordinary code does these things quickly and cheaply, with no need to waste the model's thinking compute.

Anthropic makes a very profound point in the article:

The ultimate goal many teams dream of is to build a general-purpose Agent that can truly understand high-level user intent and act autonomously on their behalf.

But under a multi-agent architecture, subagents are like employees in different siloed departments. They can only pass heavily lossy summary information back and forth, and no one holds the full picture.

The single-loop design keeps everything the Agent learned during execution, all detours it took, and all raw data it saw in the same context. Only with coherent global memory can the model connect the threads of each previous step and produce truly deep insight and decisions.

Moving smoothly from the familiar Multi-Agent architecture to a single Agent Main Loop: Anthropic says it has summarized a set of strategies after helping many enterprises migrate:

Evaluate task completion

First, you need to build an evaluation set to assess whether a subagent is suitable for integrating into the Main Loop. Anthropic found this structure: a core team maintains shared, end-to-end evaluation sets, while the teams responsible for Skills each provide smaller evaluation sets that are released along with the corresponding Skills.

During actual execution, the Agent's responses need quality evaluation; if an orchestrator exists in the system, routing accuracy also needs to be evaluated.

But because each answer cannot be reproduced 100% and is hard to simulate, evaluation becomes complex. However, you can do it this way: record timestamps of key events, then replay the day later for evaluation.

Gradually reduce subagents

Evolving to a single Agent Loop means integrating subagents into tools and Skills.

Implementation methods include: merging subagents within certain domains, calling them as tools, or replacing them with Skills and tools.

Figure: redrawn in Chinese based on the official migration animation. The three methods can be adopted in phases; whether to keep a subagent must be judged through end-to-end evaluation one by one.

Integrate domain Agents

Before merging subagents within a domain for the first time, first build a small end-to-end evaluation plan. Then, based on shared context, gradually integrate the most frequently used subagents.

Some Agents are interactive, using each other's outputs as inputs, or specialized Agents called simultaneously; these should be merged first. Tightly coupled Agents are suitable for merging into a unified Domain Agent.

Subagents as tools

If your subagent fits one of the three situations above, you can consider turning the subagent into a tool that the Main Loop calls, letting the Main Agent control the conversation between the subagent and the user.

The subagent should take over only when it truly needs to interact with the user. Apart from that, subagents are only suitable for integration into the Main Loop as Skills and tools.

You can define a unified response pattern for subagents, use the Main Agent to verify subagents' conclusions, condense the content, and then summarize.

However, some potential failure cases remain, such as:

• Each dedicated Agent has its own prompt, context, responsible team, and evaluation metrics.
• After each call, only a lossy summary is returned.
• Each call is equivalent to a nested model run loop, which increases system latency.

Integrate subagents through Skills and tools

To fold subagents into the Main Loop: convert their prompts into Skills and API calls into MCP tools, then compare performance with and without the subagent to decide whether to keep it.

When comparing, don't just look at the final score; also look at which specific tasks had results flipped.

Anthropic stressed that when testing a customer service Agent, they found that integrating a certain subagent reduced latency but caused a previously smooth flow to break. The Main Agent, when handling an order query, answered directly without asking the logistics subagent for the delivery date.

How multiple teams build a single Agent

Anthropic says Domain reasoning ability can be obtained from knowledge bases, Skills, and MCP tools. Agent teams can move ownership from the Agent layer down to the Skills and tools layer.

MCP tools

When an Agent needs to perform actions, read real-time data from systems, or return results in a fixed format, tools are the most appropriate solution. During system migration, you can also use tools to continuously call subagents.

Skills

When an Agent needs to understand a team's specific work, such as the steps, rules, and judgment standards that a special subagent like an expert follows when executing tasks, Skills are the most appropriate solution.

Our strategy for expanding the Skill library is to hand maintenance back to the Skill creators. Claude can handle maintenance tasks, automating library management by expanding, testing, and slimming Skills.

Using /skill-creator, you can create well-structured Skills and audit existing ones, thereby slimming, deduplicating, and refactoring. Using /skill-doctor, you can view the cost and actual usage frequency of each Skill in the library, and clean out redundant or ineffective Skills.

Knowledge base

A knowledge base is very suitable for storing specific reference materials. Facts and reference materials can be obtained either through model-called search or query tools, or included as reference files in a Skill. What should be avoided is retrieving this context through code and pasting it into the prompt.

In plain terms, Tools handle execution, Skills handle the method, the knowledge base handles reference materials, and the core team handles whether the Agent ultimately gets the job done.

Emmm, in the end Anthropic even advertised its own tools; it said the Claude API tools also assist in completing most of the work discussed above.

After reading the whole article, I have to say AI changes too fast. Remember early this year, everyone was talking about multi-agent architecture, and even Anthropic itself advocated multi-agent architecture. A few months later, this architecture is gradually becoming outdated. Now it's single Agent + Main Loop. It's like a super-brain continuously iterating in its mind over whether each piece of work has been done well enough. Future models might think this way.

Is this the AGI that DeepSeek advocates?

Anthropic also says future decisions should be placed as much as possible in the model, which means the Harness may also become outdated...

It truly matches the saying: Only if you learn late, can you avoid needing to learn.