Anthropic: Fold Subagents Into One Agent Loop, With a Kit

Introduction

On October 22, 2026, Diane Sarkis published "Building agents: When to fold subagents into your main agent loop" on claude.com. The post comes from Anthropic's Applied AI team and addresses a pattern it has seen in enterprise agent deployments: routers, planners and domain subagents that could be folded into one main agent loop. According to the post, in comparisons across several enterprise deployments, "a single agent with skills" frequently outperformed both a one-prompt-for-everything design and a subagent design on quality, and often at lower cost and latency per task. A companion repository, anthropics/single-agent-loop-kit, packages the migration workflow as a runnable kit.

The post is guidance, not a model release, and it does not argue that subagents are obsolete. It lists three situations where they still belong and describes a measured, one-change-at-a-time path for everyone else.

Feature Overview

1. The case against org-chart architectures. The post says enterprises often give each team or problem type its own subagent, so the agent architecture becomes a copy of the org chart (Conway's law). It names five failure modes: context management, subagent sprawl ("hundreds of overlapping subagents with no enforced standards and no specific owner"), the "Frankenprompt" of conflicting system-prompt rules, unvetted and overly localized evals, and latency. On latency, the post cites one customer that evaluated a multi-agent harness against a single agent loop and saw a roughly 2x faster runtime with the latter. That is one customer's comparison, not a general benchmark.

2. Progressive disclosure instead of handoffs. The proposed alternative is a loop where the agent sees short descriptions of skills and tools that are fully loaded only when needed, through skills and tool search. The post gives three reasons: shared context produces better answers than summaries handed back by subagents, progressive disclosure prevents context bloat, and models are more capable. It says Anthropic reduced Claude Code's system prompt for more advanced models by over 80%, including cuts related to progressively disclosing skills and tools, and that starting with Opus 4.5 models became capable of managing far more in a single loop than most teams expected.

3. The target loop design. One model and one context window run an open-ended tool loop, with turn and cost budgets and write gates set in the harness. Each turn the model emits a batch of tool calls that the harness runs in parallel. The model writes its plan in context on the first turn and revises it as results arrive. Ordering and domain procedure move into skills; hard limits such as validation and approval gates move into tools.

4. A staged migration. The post recommends one shared end-to-end eval owned by a central team, plus smaller evals shipped with each skill. It says a set of 10 golden examples is enough to start. From there the options are to merge specialists that chain on each other's output, to keep a subagent but call it as a tool, or to fold it into skills and MCP tools one at a time and compare eval results with and without it.

5. Tool and skill guidance. Tools should be grouped by user intent rather than one per API, because past 30-50 tool definitions in the system prompt, tool choice tends to degrade. Per-user permissions can live in the tools, which return a plain refusal the model can read. Skills hold how a team does work, and knowledge bases hold reference material behind a lookup tool.

Usability Analysis

The companion kit is documented as a "Reference implementation. Not maintained and not accepting contributions," under the Apache-2.0 license. It frames the work as Measure, Combine, Fold: score the current system, merge subagents that always run together, then turn each remaining subagent into a skill plus tools and compare. The audit step gives each subagent one of four verdicts: fold, merge, call as a tool, or keep.

To use it, a team copies the kit's skill into its agent repo's .claude/skills/ directory and tells Claude Code to run the single-agent-loop skill. According to the README, it stops after the audit, before any paid run, after the baseline, and after each change, and includes a token estimate before paid runs. The example in examples/support-desk is a support agent with a router and six subagents. A free offline check with KIT_MODEL=fake runs 19 tasks on a stand-in model; the README says that run is not scored.

The post also warns about regressions that final scores can hide. When Anthropic folded one subagent into another in a sample support agent, latency dropped but a previously passing process broke: the main agent held the order lookup tool and answered on its own instead of asking the shipping specialist for the delivery date. The break showed up in one run out of two, which is why the post advises running each eval task more than once and covering every production chain of agents.

Pros and Cons

The strengths are a concrete, staged method and a decision rule that accepts evidence over ideology: keep a subagent as a subagent only if the folded version scores worse. The three conditions for keeping subagents are stated plainly. The kit lowers the barrier by including a runnable example and a no-cost smoke check.

The limits are also clear. The headline comparisons come from Anthropic's own enterprise work and are described without published numbers beyond one customer's roughly 2x runtime. The kit is unmaintained, and the approach assumes the discipline the post itself calls out: a carefully managed system prompt, well-triggering skill and tool descriptions, and deliberate handling of context, memory and note-taking. Teams without any eval need to build one before they can judge a fold.

Outlook

The post frames architecture as secondary to a principle: "measure, change one thing at a time, and keep what holds up." It expects that as models get more capable and agents run longer, more subagents can become skills and tools. According to The Decoder, which covered the post on October 25, 2026, the Vals study it cites found that agent teams can be faster than single agents but do not deliver higher quality, and that scaling to 30 or 100 agents added costs without quality gains. That is The Decoder's account of outside research, not a claim from Anthropic's post.

For teams building on Claude Platform, the practical shift is organizational as much as technical: domain teams move ownership from agents to skills and tools, while one small central team keeps the system prompt and end-to-end quality.

Conclusion

This is useful reading for engineering leads who already run an orchestrator with several specialist subagents and suspect some of them mirror team boundaries rather than real needs. The advice is conditional, backed mainly by Anthropic's own experience, and best treated as a hypothesis to test on your own eval. Teams with parallel research paths, black-box verification or tool-selection problems have a stated reason to keep their subagents.

Editor's Verdict

Anthropic: Fold Subagents Into One Agent Loop, With a Kit earns a solid recommendation within the Claude space.

The strongest case for paying attention: a staged method with explicit verdicts (fold, merge, call as a tool, keep) gives teams a concrete audit to follow. That alone raises the bar for what readers should expect in this space. Reinforcing that, stated conditions for keeping subagents keep the guidance from reading as a blanket rejection of multi-agent design — practical value rather than just headline appeal. The broader signal worth registering is straightforward: folding a subagent is framed as an experiment scored on an eval, and a subagent stays only when the folded version scores worse. On the other side of the ledger, one constraint is real rather than a marketing footnote: the headline quality, cost and latency claims rest on Anthropic's own enterprise comparisons with no published dataset and one customer figure. It should factor into any serious decision. Layered on top of that, the kit is a reference implementation that is not maintained, so fixes and updates should not be expected — which narrows the set of teams for whom this is an obvious yes.

For engineering leads running an orchestrator with specialist subagents on Claude Platform, especially teams that already keep an end-to-end eval, this is a serious evaluation candidate, not just a curiosity to bookmark. For everyone else, the safer posture is to monitor coverage and revisit once the use cases that matter to your team are demonstrated in the wild.