Anthropic's New Guide: Most AI Agents Don't Need Subagents — a Single Main Loop Is the Right Answer

Anthropic has published a guide titled When to fold subagents into your main agent loop, and its core argument is fairly counterintuitive: most Agents shouldn't be split into a pile of subagents — they should be folded back into a single main loop. The accompanying data is just as direct: Claude Code's own system prompt for new models was cut by more than 80%.

The guide is aimed at enterprise Agent builders, but anyone who has ever strung together a chain of subagents in Claude Code will find it resonates.

The default architecture: one model, one context, one open-ended tool loop

Anthropic's recommended starting point is remarkably plain: one model, one context window, one open-ended tool-calling loop. Domain-specific workflows go into skills, hard constraints and deterministic lookup-style logic go into tools, and the model writes and revises its own execution plan.

The substance of this advice is to push complexity down from the "architecture layer" to the "content layer." Many teams used to carve up responsibilities with subagents, and ended up turning business logic into a multi-process orchestration problem. The single-loop approach says that separation of concerns should be expressed as differences in the content of skills and tools, not as physical isolation of context windows.

Only when measurable degradation appears is it worth splitting out a subagent.

Open-ended tool loop refers to a model that, within a continuous reasoning-acting cycle, decides on its own when to call a tool, which tool to call, and when to stop — rather than following a pre-orchestrated fixed sequence of steps. The counterpart is workflow-style orchestration, where developers explicitly define nodes and edges and the model makes only local decisions inside each node. An open-ended loop hands control of "what to do next" to the model, making it more sensitive to the clarity of tool descriptions and the quality of context, but it also avoids hardcoding a path for every task branch. The "one model, one context, one loop" that Anthropic recommends is the minimal form of this paradigm; its implicit premise is that the model itself has sufficient planning ability, and that architectural complexity should give way to the quality of prompt and tool design.

When subagents are still worth keeping

The guide lists three scenarios that still hold:

• Quality degradation from context bloat has been measured. Note the qualifier "measured" — not a gut feeling, but backed by eval data.
• Parallel processing is needed, and the subtask's context can be discarded. Throwaway context is the cleanest use of subagents.
• There are too many tools or conflicting instructions for a single agent to handle. Here the split is to reduce cognitive load, not for architectural elegance.

Beyond these, many subagents are essentially just "skills with their own context window" and don't need process-level isolation. One Reddit user mentioned maintaining around six subagents at one point, eventually keeping only two and letting the rest degrade back into ordinary skill configurations.

Context window bloat is the most common trigger for splitting agents. When a single task requires reading a large number of files, logs, or search results, irrelevant information crowds the limited window and dilutes the model's attention to key clues, showing up as missed constraints, repeated tool calls, or inconsistency. To judge whether bloat is really happening, look at quantifiable signals — for example, task success rate declining as input length grows, an abnormal increase in tool-call rounds, or a rising share of key instructions being ignored. If these signals are only subjective impressions without eval data to back them up, splitting out a subagent often just turns the problem from "context too long" into "context distorted in transit," introducing new points of information loss.

Performance data: single loop runs about 2x faster

The guide cites real customer results: one customer's single-loop approach was about 2x faster than its multi-agent orchestration framework. Multiple deployment cases also reported better quality, lower cost, and lower latency.

These gains don't come from any single optimization but from multiple factors stacking — one less layer of agent scheduling means one less layer of token overhead, one less context handoff means one less loss of information, and one less cross-agent coordination means one less stretch of latency.

Past 30-50 tool definitions, selection quality starts to drop

An empirical number worth remembering: when the system prompt contains more than 30 to 50 tool definitions, the model's accuracy in selecting tools tends to decline.

Anthropic's remedy is to group tools by user intent, paired with tool search and lazy loading — expose the tool catalog first and let the model retrieve specific definitions on demand, rather than stuffing every schema into context up front. This is the same idea as cutting the system prompt by 80%: context is a scarce resource and shouldn't be used to preload information that may never be needed.

Tool search and lazy loading is a pattern that separates tool discovery from tool use: the system prompt keeps only a condensed tool catalog or retrieval entry point, and the model actively queries and loads the full parameter schema when it judges that a certain capability is needed. This contrasts with the traditional "inject all schemas at once" approach, which makes the prompt's fixed overhead grow linearly with the number of tools and dilutes the model's attention to each tool description. The cost of lazy loading is an extra retrieval round-trip, so it suits scenarios with a large tool set where any single task involves only a few of them; for high-frequency core tools, they should still be exposed directly in context to avoid unnecessary call overhead.

Build evals before refactoring — 10 samples is enough to start

The guide places special emphasis on order: evals first, then architecture. To start, 10 golden cases are enough.

One easily overlooked detail is that each task should be run more than once. The guide mentions a regression that appeared in only one of two runs — an eval based on a single run would miss it entirely. The non-determinism of Agents means evaluation must account for variance.

Eval (evaluation set) here refers to a set of repeatable test cases designed for an Agent's end-to-end behavior, typically including input tasks and expected results or judgment criteria. Unlike unit tests, Agent outputs are non-deterministic — the same input may produce different paths and results — so evaluation should focus on pass rates rather than single-run success or failure. Golden cases should cover the most representative real tasks and include known failure modes, so regressions can be caught quickly after architectural changes. Starting with 10 cases emphasizes "establishing an observable baseline first" rather than statistical completeness; as the system evolves, coverage and difficulty can be expanded gradually.

Common failure modes in large organizations

The guide calls out several problems typical of teams at scale:

• Context is lost between agents, with information degrading layer by layer along the handoff chain
• Subagent sprawl — the count only ever goes up
• "Frankenprompt" — every team appends its own rules to the prompt until no one understands the whole
• Evals are too local, covering only a single subagent and missing end-to-end behavior
• Latency grows linearly or even superlinearly with the number of agent layers

These problems share a common root: complexity gets split along organizational boundaries instead of converging into a single observable place.

Supporting migration tools

Anthropic provides several new /claude-api skills to assist migration: build-eval, prompt-audit, hillclimb, cost-optimize, plus /skill-creator and /skill-doctor. There's also a anthropics/single-agent-loop-kit toolkit on GitHub.

Practical takeaways

The value of this guide isn't in declaring subagents obsolete but in giving an actionable criterion: default to a single loop, and split only when specific degradation is measured. This is the exact opposite of the common engineering habit of "build the architecture first, fill in the content later."

For teams already invested in multi-agent architectures, the most realistic path is to first shore up eval infrastructure and use data to find out which subagents genuinely contribute value and which are just byproducts of context isolation. The fact that the system prompt was cut by 80% also shows that much of what gets stuffed in as "necessary context" really isn't necessary.

Worth noting: the guide's data comes mainly from enterprise customer deployments, and the specific scenarios and task types aren't fully disclosed. When migrating, rely on your own eval results rather than directly applying someone else's performance multiplier.

One-line Summary

Anthropic's guide argues Agents should default to a single loop, splitting into subagents only when degradation is measured.

Paragraph Summary

Anthropic published the guide When to fold subagents into your main agent loop, arguing that most Agents shouldn't be split into multiple subagents but should converge into a single model, a single context window, and a single open-ended tool loop, with domain workflows in skills and hard constraints in tools. Subagents are worth keeping only in three cases: measured quality degradation from context bloat, a need for parallelism where context can be discarded, or conflicting tools and instructions. The guide cites customer data showing a single-loop approach is about 2x faster than multi-agent orchestration, and notes that model selection quality declines past 30-50 tool definitions, recommending intent-based grouping with lazy-loaded tool search. Build evals before refactoring — start with 10 golden cases and run each task multiple times to catch non-deterministic regressions.