Anthropic: Don't Rush to Split Out Sub-Agents

Leafw included in AI

2026-10-25 4568 words 22 minutes

Contents

A few days ago I wrote a breakdown of a paper on parallel sub-agents. The takeaway: turning on concurrency generally hurt scores on short tasks, while on long tasks the results were mixed. On October 22, Anthropic published an article on the Claude website, “Building agents: When to fold subagents into your main agent loop”, written by Anthropic’s Diane Sarkis. It’s about when you should fold sub-agents back into the main loop, that is, merge a sub-agent’s prompt and capabilities into the main agent so they become its skills and tools.

The article opens by giving sub-agents their due: they work well for verification, parallel work, and scoping permissions by module, and plenty of Anthropic’s internal agents use them, such as its multi-agent research system. But Anthropic’s Applied AI team has repeatedly seen in enterprise agent deployments that things get better after routers, planners, and domain sub-agents are folded back into the main loop. According to the article, across the several enterprise deployments they compared, a single agent with skills often beat both the “one prompt does everything” design and the “split into sub-agents” design on quality, and usually came in cheaper and faster per task as well.

The whole piece revolves around one question: every sub-agent you split out has to come with evidence for why it needs its own context.

Below I’ll walk through it roughly in this order: background, the core argument, how to migrate, the toolkit, takeaways, and limitations.

Background: Where the Splitting Comes From

Architecture Grows Like the Org Chart

The starting point the article describes is a familiar one. A company wants a single customer-facing entry point that ties together multiple products. Each capability belongs to a team, so each team first builds its own agent, and then a central platform team builds an orchestration layer on top. That can take the form of an orchestrator agent dispatching sub-agents, or a main agent calling each team’s agent as an MCP tool. MCP is the Model Context Protocol, an open protocol for connecting external tools and data to models.

The article argues this looks simple, but complexity shows up right away. It lists five problems:

Context management: every time, you have to decide what gets passed between agents, and details get lost in the back-and-forth;
Sub-agent sprawl: every team ships its own sub-agent, and you can end up with hundreds of sub-agents with overlapping functionality, no shared standards, and no clear owner;
Patchwork system prompts: every team adds a line to the system prompt, rules conflict with each other, and the tone is inconsistent. The article calls this a Frankenprompt;
Fragmented evals: each team only adds evals for its own sub-task, nobody maintains the full eval suite, and leadership sees diluted, overly local scores;
Latency: the multi-agent structure itself slows down responses. One customer compared a multi-agent setup with a single-agent loop, and the latter ran about 2x faster.

The article also gives an example up front: one company’s customer-facing agent had a dozen or so specialist sub-agents, brand voice was hard to keep consistent, and the extra latency hurt the user experience. The article attributes this kind of splitting to Conway’s Law: too many companies give every team and every problem type its own sub-agent, and the agent architecture ends up as a copy of the org chart.

Five Layers vs. One Loop

The article also describes a common way these systems evolve. The figure below is the comparison diagram from the original article.

On the left is the common approach: a request goes into a multi-agent orchestrator, passes through an intent classifier and a fixed reasoning pipeline numbered 1 to 5, gets sorted into three user-segment buckets, each of which goes down its own recommendation branch, and finally everything is merged into an answer. It’s titled “5 layers of structure wrapped around the model.” On the right is what they often recommend instead: one clear system prompt, one model, four or five lightweight tools that only fetch data, plus one strict output guardrail. It’s titled “1 loop.” The article says the feedback on setups like this is usually that most of the structure is doing work for the model that it no longer needs help with, and the setup on the right is enough to cover most scenarios.

The Article’s Argument

One Loop Plus Progressive Disclosure

The approach the article recommends is progressive disclosure: progressively disclose context through skills, and progressively disclose tools through tool search. Normally the agent only sees a short description of each skill and tool, and loads the full content only when it needs it. A skill is Anthropic’s way of packaging a capability: a folder containing instructions and optional scripts. The model first sees the name and a one- or two-sentence description, and reads the full text only when needed. Tool search applies the same idea to tool definitions.

The article gives three reasons.

First, shared context produces better answers. For long-running agents, it’s best to keep the context of multiple tasks in the main context window. An agent that has seen the result of every previous step can connect them, producing richer results than several sub-agents each handing back a summary, with fewer lossy handoffs.

Second, progressive disclosure prevents context bloat. Without cramming everything into a huge system prompt up front, a single agent can handle all kinds of tasks, which removes the main reason teams split out sub-agents in the first place. The number the article gives: Anthropic cut Claude Code’s system prompt for more capable models by more than 80%, including cuts that came from progressively disclosing skills and tools.

Third, models have gotten stronger. The article says that starting with Opus 4.5, what models can handle in a single loop goes far beyond what most teams expect. Recent models are also increasingly good at reporting and checking as they go, which makes some harness components redundant. The simpler the loop, the easier it is to swap in the next-generation model. The article notes that in the migrations they’ve helped customers with, rigid multi-agent structures were often the very reason a new model couldn’t take on more of the work.

A single loop has costs too: the system prompt needs careful maintenance, skill and tool descriptions need to trigger at the right moment, and the context window, memory, and notes all need dedicated handling. The article’s arrangement is a central team that owns end-to-end quality and the system prompt and reviews every new tool and eval before it goes live. That team should be small.

What the Single Loop Looks Like

The target shape the article lays out: one model, one context window, running an open-ended tool loop, with limits such as turn count, cost budget, and approval for write operations living in the harness. On each turn the model issues a batch of tool calls, the harness executes them in parallel, and the raw results go back to the same model, which decides whether to issue another batch, ask the user a question, or give an answer. The loop stops when the model is done answering or the budget runs out, after which a verification pass can optionally run. The model writes its plan into the context on the first turn and keeps revising it as results come in. The article says this is the most important change relative to the orchestration pattern: the model writing the plan is the same model executing it, so it can change the plan midway.

Each of the old components has somewhere to go. The code that rewrites the plan according to a fixed set of rules can be deleted; the model decides each step itself. Sequencing and domain workflows go into skills. Hard constraints like validation and approval gates, along with things only needed mid-conversation (such as looking up memory), go into tools. Code can still preload content that’s cheap and almost always needed, such as entity resolution, and it still handles mechanical work inside tools, like assembling requests.

Who Still Gets Sub-Agents

The article is explicit that sub-agents are still useful, and they’re still used in frontier research. It lists three situations where you should use them:

The single-agent loop shows measurable performance degradation due to context bloat;
Multiple tasks need to be processed in parallel, each in a fresh context window that’s thrown away when done;
A single agent has trouble picking the right tool, or the instructions in the system prompt conflict with each other.

If you really do need to go multi-agent, the article recommends starting from the simplest viable pattern, such as a generator plus a verifier, and drawing boundaries by context: the work handed to each sub-agent should need very little information from the rest of the system, and should return a compact result. The good fits it names are independent research paths, independent components with clean interfaces, and black-box verification that only looks at outputs. Splitting by problem type, on the other hand, turns into a game of telephone, with a bit more distortion at every handoff. The figure below is the example from the original article.

The top half splits by problem type: agent 1 writes the feature, hands it to agent 2 to write tests, which hands it to agent 3 to review the code. The caption says every handoff loses context, and the agent writing tests doesn’t know why the implementation made the decisions it did. The bottom half splits by context: one agent writes both the feature and the tests, because it already has the context; a separate verifier only runs the tests and reports the results, and doesn’t need the implementation context at all.

This lines up with the paper from before. The three situations in the paper where concurrency paid off were complementary division of labor, parallel attempts followed by selection, and independent verification, which are very close to the scenarios the article lists. Its failure taxonomy also includes a “global context” category, accounting for 9.3% of all failure instances, which is exactly about agents working separately lacking the information needed to stitch the work together.

As for a full handoff, where a sub-agent takes over the whole conversation, the article only recommends it when that sub-agent must talk to the user directly. Everything else can be replaced with skills plus tools in the main loop.

How to Migrate

The migration path can be drawn as the flowchart below, which I put together from the original article and its companion toolkit. Start by building evals and running a baseline, then merge or wrap as tools, then fold sub-agents into the main loop one at a time, comparing evals after each one. If things get worse, fix it first; only if it’s still worse after the fix do you roll back and keep that sub-agent as a tool call.

Build Evals First

The first step is building an eval suite: a set of tasks to score the system, so you can judge whether a given sub-agent should be folded. The structure the article has seen work well is a shared end-to-end eval suite owned by the central team, with each team attaching small eval sets to its own skills. Ten examples with reference answers are enough to get started.

For scoring, you can start by grading the final response against a rubric. While there’s still an orchestrator, also track routing accuracy, i.e. whether the right sub-agent was chosen; after folding, switch to checking whether the agent loaded the right skill and called the right tools. The long-term goal is task-completion evals, which matter most when comparing architectures. When internal systems’ environments are hard to replay, the article mentions a technique Anthropic uses internally: timestamp important events, replay them later, and run them as targeted evals.

Merge, Wrap as a Tool, Fold In

Evolving toward a single loop means gradually turning sub-agents into tools and skills. The article gives three approaches; the figure below is the original illustration.

The left column is merging: the main agent originally had four sub-agents, A, B, C, and D, under it, and the ones sharing context get merged pairwise into A+B and C+D. The article recommends starting with the most heavily used ones, and targeting three kinds: one that depends on another’s output, ones that read and write the same data, and ones that are frequently called together.

The middle column is calling sub-agents as tools: the main agent gets each sub-agent’s result back through a tool call and stays in control of the conversation itself. This lets you define a unified return format for sub-agents, and the main agent can check their conclusions against real data. This step doesn’t require rewriting the sub-agents, so the article considers it a good first step, and it also gives you a baseline before folding. But the problems remain: each specialist still has its own prompt, context, owning team, and evals; every call still returns a lossy summary; and every call is a nested model loop that adds latency.

The right column is folding into skills and tools: the sub-agent’s prompt becomes a skill of the main agent, and its API calls become MCP tools. The article’s approach is to fold one at a time, compare eval results with and without that sub-agent, and then decide which to keep.

Watch Which Tasks Flip

When comparing, the article warns against looking only at the overall score. Look at which tasks flipped, i.e. went from passing to failing, or the other way around. Anthropic tried this on an example customer-service agent: after folding one sub-agent into another, latency went down, but a previously passing flow broke. With an order-lookup tool now in hand, the main agent answered on its own instead of asking the shipping specialist for the delivery date.

So before every change, your evals need tasks covering every chain of agents that runs in sequence in production, as well as every rule the agent must never break. And each task needs to run more than once, because the problem above showed up in only one of two runs.

How Multiple Teams Divide the Work

After folding, each team’s responsibility shifts from maintaining an agent to maintaining skills and tools, while the small central team keeps owning the system prompt and end-to-end quality. The article divides the work across three vehicles.

MCP tools are for taking actions, reading live data, and returning fixed-format results. The article recommends grouping tools by user intent rather than one tool per API, because once the system prompt holds more than 30 to 50 tool definitions, tool selection tends to get worse. Pair this with tool search and deferred loading, and put necessary preconditions inside the tools: for example, if Y needs X’s output, have Y’s tool check for it itself and, if it’s missing, return a hint the model can act on. Same for permissions: each tool checks what the calling user can see and do, and if it’s not allowed, returns a refusal the model can understand. That way one loop can serve users with different permissions.

Skills carry a team’s way of doing things, i.e. the steps, rules, and judgment criteria that used to live in the specialist sub-agent’s prompt. To prevent skill sprawl, the article recommends each team designate a directly responsible owner who ensures skills are well written, don’t overlap, and come with evals. The article also mentions two Claude Code commands: /skill-creator, provided by an official plugin, for writing well-structured new skills and also auditing existing ones to trim, dedupe, and reorganize them; and /skill-doctor, for seeing each skill’s cost and actual usage frequency in the library so you can delete the unused ones.

The knowledge base holds reference material the agent only occasionally needs, such as policies, metric definitions, and product specs. It can sit behind a lookup tool the model calls itself, or live as reference files inside a skill. The article specifically says to avoid having code retrieve this content and paste it into the prompt.

There’s an outside case study that maps onto this. Skyvern is an open-source browser automation framework. In an October 1 blog post, co-founder and CEO Suchintan Singh wrote that they removed the preprocessing step where code took a screenshot and compressed the web page into an element list before handing it to the model, and instead had the agent start from minimal context and scan the HTML and screenshots on demand. In their A/B test on about 100,000 production runs, average run time dropped from 593 seconds to 262 seconds, model calls rose from an average of 6.4 to 23, and tokens per call fell from 29K to 12K.

What’s in the Toolkit

The article’s companion repo, anthropics/single-agent-loop-kit, states in its README that it’s a reference implementation: not maintained, not accepting contributions. The main piece is a Claude Code skill, plus four scripts, a reference loop, and a runnable example.

Six Steps and Four Checkpoints

Copy the skill/ directory into .claude/skills/ in your own agent repo, ask Claude Code to run it, and it goes through six steps: audit, baseline, merge, fold, keep as tool, and ongoing maintenance.

The audit assigns each agent a verdict: main (the router or orchestrator, which will become the single loop), fold (the default, folded into skills and tools), merge (merged with another one), as-tool (keeps its own context and is called as a tool), or keep (must hold multi-turn conversations with the user itself, or is owned by an outside company). For judging whether a sub-agent deserves its own context, the step file gives three criteria; meeting any one is enough. The first is more specific than the article: each call has to read content on the order of tens of thousands of tokens, a few thousand doesn’t count, and you should first ask whether the tools could return less. The other two are parallel or independent work, and too many tools or conflicting instructions that skills can’t fix. It also lists several things that don’t count as reasons: being owned by another team, having its own persona, a long prompt, lots of tools, or fixed steps. Fixed steps are a workflow; write them as code and put them in a tool.

When folding, the sub-agent’s prompt is split line by line into five places: workflows and domain knowledge go into skills; hard constraints go into tools, enforced by code; reference material goes into reference files or lookup tools; personas and greetings get deleted, with tone owned by the main system prompt; and instructions written for older models, like all-caps emphasis or “think step by step”, also get deleted.

The whole process has four fixed checkpoints: after the audit, before the first paid eval run, after the baseline, and after each change. Each time it reports findings, recommendations, and one question for a human to answer. The tokens for evals are paid by the user, so an estimate has to be given before spending; the README recommends starting with 10 tasks and two or three runs per task. The baseline step also requires a breakage checklist: lost rules, the main agent taking shortcuts, picking the wrong tool, extra write operations that shouldn’t happen, broken multi-turn conversations, and so on. Every applicable one must have a task that can catch it. Two categories, silent cost creep and routing drift, don’t get tasks; you watch for them through token and path changes in the comparison results.

Example: A Fictional Support Desk

examples/support-desk is the customer-service agent for Tamberwick Home, a fictional home-appliance retailer: one router plus six sub-agents handling orders, shipping, returns, accounts, device diagnostics, and claims. Each sub-agent is designed with a known correct verdict, and the answers are in ANSWER-KEY.md.

The router’s system prompt is a textbook Frankenprompt: it opens in all caps saying it must never answer on its own and must always transfer to a specialist; the teams’ rules contradict each other, with the orders team saying to call orders first and then shipping, and the shipping team saying to go to shipping first for delivery-time questions. The returns sub-agent has an enthusiastic persona named Remy that doesn’t match the brand voice, and hard constraints like the 30-day return window are written only in the prompt, with no backend check.

The answer key’s intended verdicts: orders and shipping are merged and then folded, since 96 of 200 synthetic traces called shipping, every time right after orders; returns and accounts are folded; device diagnostics is kept as a tool, because every call reads a 900-line device log, about 30K input tokens, while the other sub-agents use only 1,000 to 3,000; claims keeps its full handoff, because it’s run by an insurance company and has to hold multi-turn conversations with the customer.

single_loop/ is the end state after the migration: one loop, one returns skill, eight tools, one diagnostics sub-agent called as a tool, and one handoff to claims. The tools are reorganized by user intent: what used to be two steps, orders then shipping, is now a single track_order that returns status, carrier, and estimated delivery. Every write operation has to pass an approval gate.

Two Real Runs

example-run/ stores records of two real runs, both by the same user with one model (claude-opus-5), running each task twice. The README says the measured conclusions were removed from the descriptive text after the runs, but the raw results and traces are all there and can be read directly with compare.py.

The first was on October 8, folding the returns sub-agent into the main loop across 12 tasks. Completed tasks went from 11.0/12 to 11.5/12, average latency dropped from 27.3 seconds to 19.4 seconds, model calls went from 6.3 to 4.8, and output tokens fell by 32%. The cross-domain t11 went from failing both times to passing both times; but t01, which asks about order status, failed once. In that failing trace, the main agent used its newly acquired order-lookup tool, found the order had shipped, and replied that there was no delivery date yet, without calling the shipping sub-agent, so the October 3 date the eval required never appeared. My reading is that the customer-service example in the article is exactly this run: latency went down, t01 broke, and it showed up in only one of two runs. The toolkit’s fold step file also notes that this issue was exposed in its own example run.

The second was on October 9, across 17 tasks, only changing the device diagnostics sub-agent into a tool call. Completed tasks went from 16.0/17 to 15.5/17, again with one t01 failure, and the script judged it “worse than baseline.” Claude Code didn’t directly recommend keeping or reverting; it proposed 4 extra runs each of t01 and t10 on both sides, 16 conversations in total. After the extra runs, both sides passed everything, and the user kept the change.

The Reference Loop

reference_loop/loop.py is under 300 lines and implements the single loop as the article describes it. The default budget is at most 25 turns, 400K tokens (including what sub-agents spend), and at most 16 tool calls per turn. Reads run in parallel; writes execute one at a time in order after the reads finish. If any tool writes data, an approval function must be passed in, otherwise it errors out. Skills only list their name and description in the system prompt, and the model loads the body with load_skill; deferred tools go through tool search. The verifier gives only one chance to revise, and an answer rejected twice is not returned to the user.

Takeaways

Putting the article and the toolkit together, here’s what it boils down to for day-to-day agent building:

Start new systems with one loop. The toolkit README recommends that if you don’t have sub-agents yet, start with one loop and add tools and skills when testing shows you need them.
Before splitting out a sub-agent, check it against those three situations. A long prompt or lots of tools isn’t a reason; hand those to on-demand skill loading and tool search respectively. Being owned by another team isn’t a reason either; ownership can move to the skill and its evals.
Put hard constraints in tools. Rules like return deadlines or “never read out the address” are the easiest to lose during folding if they stay in the prompt; put them in tools checked by code, then write unit tests proving they refuse.
Score evals on outcomes. The toolkit requires looking at what changed in the system and what the user was told; path checks break as soon as the architecture changes.
Run each task at least twice, and keep an eye on tasks that flip. In the example, if you only looked at the overall score (11.0 to 11.5), you’d think the change was all upside.

The costs land on different people: with many sub-agents, latency and information lost in handoffs land on the user; fold back into a single loop, and the central team has to keep the discipline, the migrating team pays the eval tokens, and if the evals miss a broken chain, it’s still the user who pays.

Limitations

Evidence for the key numbers is thin. The roughly 2x run time comes from one customer, and “quality is often better” comes from a handful of enterprise deployments; the article gives no eval scores, task types, or sample sizes.
The 80% refers to Claude Code’s system prompt for more capable models, and the article only says it “includes” cuts from progressive disclosure, without breaking out how much.
Both real runs in the toolkit are from the same user, one model, two runs per task, and the second run’s conclusion was settled only by extra runs. The parts the README lists as not yet run on a real model: the merge and maintenance steps, the single_loop/ end state, tasks t18 and t19, the from-scratch eval-building flow, and any system beyond the example. The skill’s wording was also changed after the second run, and nobody has run it with the new wording yet.
The article and the toolkit disagree in places. The article says wrapping as a tool is a good first step; the toolkit’s checklist is merge first, then fold, then convert to tools last, with failed folds also turned into tools. The article recommends checking after folding whether the right skill was loaded and the right tools called; the toolkit scores only on outcomes and lists path changes separately for human review.
The article’s examples are mainly customer-facing enterprise agents. For frontier research it only says sub-agents are still in use, without going further. Whether to split on long tasks is something the article doesn’t answer; the paper from before measured mixed results.

Final Thoughts

Read alongside the earlier paper, they’re saying the same thing. The three most common failures in the paper were spawning too many sub-agents and burning through the budget, being terminated too early, and deliverables getting overwritten, all of which come down to how the main agent hands out work and wraps it up. The remedy in Anthropic’s article is to first use evals to confirm a given sub-agent really needs its own context, and fold any that can’t produce that evidence back into the main loop, with skills and tools taking over the work they used to do. When building an agent, start with one loop, and only consider splitting things out once your evals detect degradation.