Anthropic tells enterprises to fold subagents into a single agent loop

Anthropic changes its advice on subagents

Anthropic is telling companies that build agents on its platform to use fewer subagents. In a guide published on 22 October 2026 by Diane Sarkis, the company says its Applied AI team has seen enterprise agents improve after their routers, planners and domain subagents were folded into the main agent loop, with the extra knowledge supplied through skills and tools that load only when needed.

Alongside the guide, Anthropic published single-agent-loop-kit on GitHub, an Apache 2.0 reference implementation that walks a team through measuring an existing multi-agent system and folding it down one step at a time. The advice matters because multi-agent orchestration has been one of the most common ways to structure large agents, and Anthropic itself has promoted the pattern, including in its own multi-agent research system.

What Anthropic saw in enterprise deployments

According to the guide, in comparisons across several enterprise deployments, a single agent with skills frequently beat both a single giant prompt and a subagent design on quality, and often did so at lower cost and latency per task. Anthropic gives two concrete examples. One company found that the dozen specialist subagents inside its customer-facing agent made it hard to keep a consistent, on-brand voice and added latency users noticed. Another customer that compared its multi-agent harness against a single loop saw roughly twice as fast a runtime with the single loop.

The company also describes a familiar shape in proposed designs: an intent classifier, a fixed multi-step reasoning pipeline, user-segment buckets, separate recommendation branches and an orchestrator on top. Its feedback, it says, is often that most of that structure does work the model no longer needs done for it, and that one clear system prompt, four or five thin data tools and firm output guardrails would cover most of the use case. These are Anthropic's own observations from customer work; the guide does not publish the underlying numbers or name the companies.

When subagents still make sense

The guide is not a blanket rejection of subagents. Anthropic lists three situations where it still recommends them: when a single loop shows measurable performance loss from context bloat, when several tasks need to run in parallel in fresh context windows that can be thrown away afterwards, and when a single agent struggles to pick the right tools or its system prompt contains conflicting instructions.

If a team does go multi-agent, the advice is to start with the simplest pattern that could work, such as a generator and a verifier, and to split work by context rather than by problem type. Good candidates are independent research paths, components with clean interfaces and black-box verification. Splitting by problem type, the guide warns, turns into a game of telephone where each handoff loses detail.

The org chart problem

The sharpest part of the guide is about how large companies end up with sprawling agent systems. Each product team builds its own agent, then a platform team puts an orchestrator on top, sometimes exposing the specialists as MCP tools. Anthropic calls the result a copy of the org chart and names Conway's law directly.

It lists the failure modes that follow. Context management becomes a negotiation over what each agent passes on, and details get lost. Subagent sprawl leaves companies with hundreds of overlapping agents with no standards and no owner. Every team adds a sentence to the system prompt, producing what the guide calls the Frankenprompt, with conflicting rules and no consistent voice. Each team writes evals tuned to its own subtask, so leadership ends up deciding on scores that do not reflect the whole product. And every extra layer adds latency.

Anthropic's answer is organisational as much as technical: one small central team should own the system prompt and end-to-end quality and vet every new tool and eval before it ships. That echoes the cost concerns in our explainer on what multi-agent systems really cost.

Why one loop can work now

Anthropic gives three reasons the single loop now holds up. First, shared context produces better answers: an agent that has seen every earlier step can connect them, instead of working from summaries handed back by subagents. Second, progressive disclosure, where the agent sees short descriptions of skills and tools and loads the full versions only when needed, removes the main reason teams split work up in the first place. The company says it cut the Claude Code system prompt for its more advanced models by more than 80 percent, partly by disclosing skills and tools progressively.

Third, the models have changed. The guide says that starting with Claude Opus 4.5, models could manage far more in one loop than most teams expected, and that thinking cannot be turned off on Opus 5.5 and Fable 5.1. Recent models narrate their progress and check their own work, which makes some harness scaffolding redundant. Anthropic adds that in model migrations it has helped with, rigid multi-agent structures were often what stopped a new model from doing more of the work.

The loop Anthropic recommends

The target design is plain. One model and one context window run an open-ended tool loop, with limits such as turn budgets, cost budgets and write gates enforced by the harness. Each turn the model emits a batch of tool calls, the harness runs them in parallel and returns raw results, and the model decides whether to call more tools, ask the user a question or answer. An optional goal or verifier check can run afterwards.

The key change from an orchestrator setup is that the model writes its own plan in context on the first turn and revises it as results come in, so the planner and the executor are the same model. Ordering and domain procedures move into skills. Hard rules, such as validation and approval gates, move into the tools themselves. Code still handles cheap, almost always relevant steps like entity resolution and mechanical work like payload construction.

How to migrate without breaking things

Anthropic's migration advice starts with evals. It suggests one shared end-to-end set owned by the central team, plus smaller sets shipped with each skill by the team that owns it, and says even 10 golden examples are enough to begin. While an orchestrator remains, teams should track whether it routes to the right subagent; after folding, whether the agent loads the right skill or calls the right tool.

From there the steps are gradual. Merge specialists that chain on each other's output or touch the same data. Keep any subagent that still earns its place but call it as a tool, so the main agent keeps the conversation; a full handoff makes sense only when the subagent must talk to the user directly. Then fold the rest one at a time, turning prompts into skills and API calls into MCP tools.

The guide includes a useful warning from Anthropic's own test on a sample support agent. Folding one subagent into another cut latency but broke a process that had been passing: 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 appeared in only one of two runs. The lesson Anthropic draws is to look at which tasks flipped, not just the overall score, and to run each task more than once.

Where team knowledge goes instead

In the single-loop world, teams own skills and tools rather than agents. Anthropic recommends tools grouped by user intent rather than one per API, because tool choice tends to degrade once a system prompt holds more than 30 to 50 tool definitions, and suggests tool search with deferred loading. Permission checks live inside each tool, which returns a plain refusal the model can read, so one loop can serve users with different access. Our guide to designing tools for agents covers the same grouping problem.

Skills hold how a team does its work: the steps, rules and judgment calls that used to live in a specialist's prompt, each owned by a named person on that team. Reference material such as policies and product specs belongs in knowledge bases behind a search tool or as files inside a skill, not pasted into prompts by code. Anthropic's Agent Skills format joined the Agentic AI Foundation on the same day, as we reported.

The migration kit

The kit chains Anthropic's Claude API skills into a guided workflow with three stages: measure, combine and fold. The guide names the skills involved: build-eval to create eval sets, prompt-audit to flag instructions written for older models and propose fixes as a diff, hillclimb to iterate on skills and tool descriptions against an eval, and cost-optimize to suggest savings such as prompt caching and model choice, one change at a time.

It ships with a demo support desk built from a router and six subagents, and an offline smoke test of 19 tasks that runs with a fake model at no cost. The workflow is designed to stop for a human at the audit, before any paid runs, after the baseline and after each change. The README is frank about its limits: the workflow has been run against a real model only twice, by one person on one model, and the merge and upkeep steps have not been run on a real model at all. The repository is labelled a reference implementation that is not maintained and not accepting contributions.

What to take from it

For teams with large multi-agent systems on Claude, the practical message is to build a small end-to-end eval, fold in one subagent, and keep it separate only if the folded version scores worse. Anthropic's Managed Agents work already leans on the model to plan its own steps, and this guide pushes the same idea into customer architectures.

The caveats are real. The evidence is Anthropic's own and mostly anecdotal, the kit is lightly tested, and the advice is tied to its own newest models and platform features. Anthropic itself frames it as a principle rather than a fixed architecture: measure, change one thing at a time, and keep what holds up.