When to fold subagents: Anthropic's criteria and migration

The more you build out an agent, the more tempting it is to add a subagent for each role: a router that sorts incoming requests, a planner, specialists for orders or shipping. On October 22, Anthropic’s Applied AI team published a piece on Claude’s site about when some of that structure belongs back in the main loop, and how to decide. It covers agents built on the Claude Platform.

One caveat up front: the article does not say subagents are obsolete. It calls them useful for verification, parallel work, and separating permissions, and says Anthropic’s own research system uses them. The target is splitting where no split is needed.

What went wrong#

According to the article, the team compared, across several enterprise agents, a single agent with skills against two alternatives: everything packed into one prompt, and the work split across subagents. The single agent with skills often won on quality, and often cut cost and latency per request too. The article does not include the numbers from those comparisons. Kim Olsen, who wrote an outside test of the idea, points this out as well.

The example given is a company whose customer-facing agent had more than ten specialist subagents. It struggled to keep a consistent brand voice, and the added latency hurt the user experience.

Large organizations tend to build in this order: each feature team builds its own agent, then a central team puts a router on top. The article calls this a case of Conway’s law, where the org chart becomes the architecture, and lists five problems that follow.

Problem	What happens
Context handoff	Someone has to decide what passes between agents, and details drop out along the way
Subagent sprawl	Every team ships its own, so overlapping agents grow into the hundreds with no standard and no owner
Patchwork prompts	Each team adds a line to the system prompt, rules conflict, and the tone drifts
Local evals	Each team adds evals tuned to its own piece, and nobody looks at the whole
Latency	In one customer’s comparison, the single loop was about twice as fast

One loop with skills#

What Anthropic recommends is a loop with one model and one context window. Each turn, the model emits a batch of tool calls, the harness (the code that runs the loop) executes them in parallel, and the results go straight back to the same model. The model writes a plan on the first turn and revises it as results come in. Because the same model plans and executes, it can change the plan midway. The article names this as the biggest difference from a design split into a router and specialists. Limits on turns and cost, and approval gates for writes, live in the harness.

A single loop sounds like it would bloat the context. Progressive loading is what keeps it in check. At startup, only the name and description of each skill go into the system prompt, and the body loads when a request matches the description. The official docs put a description alone at about 100 tokens per skill. Tools work the same way: with tool search, a tool marked defer_loading: true stays out of the context until a search finds it.

The article gives three reasons to choose this design. First, the model sees the results of earlier steps in the same context, so its answer ties the steps together instead of stitching up summaries returned by subagents. Second, progressive loading avoids context growth, which was the main reason to split work into subagents in the first place. Claude Code itself, the article says, cut its system prompt for newer models by more than 80%. Third is model capability: from Opus 4.5 on, it says, one loop can handle more than many teams expect.

The work that subagents or fixed pipelines used to own goes to different places.

Content	Where it goes
Step order and domain-specific procedures	Skills
Verification, approval gates, and processing needed mid-conversation (such as memory lookups)	Tools
Cheap things needed on nearly every request (such as identifying what the input refers to)	Load up front in code
Reference material such as policies, metric definitions, and product specs	A search tool, or reference files inside a skill

Three reasons to keep a subagent#

Anthropic lists three conditions under which a subagent can stay: you can measure performance loss from context growth in a single loop, you want to run several tasks in parallel in fresh contexts that are thrown away when done, or a single agent picks the wrong tool or runs into conflicting instructions in its system prompt.

It also warns about how to split when you do. Splitting by type of problem degrades information at every handoff, like a game of telephone. The article recommends splitting by context instead: hand off work that needs almost nothing from the rest of the system, and have it return a short result. Good fits are independent research, components with clear boundaries, and verification done without knowledge of the content.

When one of the three conditions applies and a subagent stays, the article recommends that the main agent call it as a tool and keep the conversation with the user. Handing off the conversation itself is only for a subagent that has to talk to the user directly. Everything else, it says, can go into the main loop as skills and tools.

Migration starts with evals#

The article’s procedure begins by building evals. Ten examples with known correct answers are enough to start. The starting point is grading the final message against a rubric, and while the router is still in place, it recommends also checking whether the right subagent was chosen. After folding, the checks shift to whether the right skill loaded and the right tool was called.

Next, merge the parts that work together. Candidates are specialists that act on each other’s output, touch the same data, or are often called together. If, in real usage, one specialist is frequently called right after another, the two are candidates to merge into a single domain agent.

As a step before a rewrite, you can also call subagents as tools. This lets you standardize what the subagents return, and lets the main agent check conclusions against real data. But prompts and evals stay split by specialist, each call returns a lossy summary, and the nested loops add latency.

Finally, replace the rest with skills and tools one at a time, comparing evals before and after each swap. The article recommends looking at which tasks changed outcome, not just the total score. When the team tried this on the sample support agent, latency dropped but one previously passing flow broke. Once the main agent had the order lookup tool, it answered a delivery date question itself instead of asking the shipping specialist. That failure appeared in only one of two runs, so each task needs several runs.

Several teams growing one agent#

Teams keep their areas of ownership in a single loop. In the article’s proposal, each team owns skills and tools instead of an agent, and a small central team owns the system prompt and overall quality. New skills, tools, and evals ship after the central team reviews them.

Tools are for taking actions, reading current data from a system, and returning results in a fixed shape. The article recommends grouping them by user intent rather than one per API, because tool selection accuracy tends to drop once you pass 30 to 50 tool definitions. Per-user permissions are also checked inside the tool, and a disallowed action returns a refusal message the model can read. That way you do not need a separate agent for each permission tier.

Skills are where a team’s way of working goes: the procedures, rules, and judgment calls that used to live in specialist prompts. To keep skills from multiplying, the article recommends giving each team an owner, shaping skills with /skill-creator, and using /skill-doctor to see each skill’s cost and usage count and delete the ones nobody uses.

What the migration kit does#

The article comes with a migration kit. The sample is a fictional support desk with a router and six subagents, and it includes 19 eval tasks and 200 synthetic run logs. A check run with KIT_MODEL=fake needs no API key and costs nothing. It only confirms that the pieces are wired together, though. It does no grading.

To use it on your own repository, copy the kit’s skills into .claude/skills/ and run them in Claude Code. It first builds an inventory of your subagents, sorts each into “fold”, “merge”, “call as a tool”, or “keep”, and stops once to show you. It also stops before any costly run, after the baseline measurement, and after each change, and it shows a token estimate before each run. Eval runs call the model once per task per repetition, so the README recommends starting with 10 tasks and 2 to 3 repetitions.

The kit is explicitly a reference implementation, with no maintenance and no contributions accepted. According to the README, it has run against a real model only twice, on the sample, and the merge procedure and the flow for starting from a repository with no evals have not yet been tried with a real model.

The README also lists cases where you do not need the kit. If you have no subagents yet, start with one loop. If a subagent does serve to separate context, keep it. If you lack either a way to run the system on test requests or a person who can judge correct results, set that up first. Without a score, whether to migrate becomes a matter of opinion.

An outside test#

The day after the article, Kim Olsen published a comparison of two builds of a quoting desk. Twelve emails sent to a fictional furniture company were each processed three times by two designs: a router that queries three specialists, and a single loop that loads skills. The single loop met all eight checks in 36 of 36 runs, the four-agent build in 29 of 36. Median time per quote was 13.9 seconds for the four agents and 7.3 seconds for the single loop. Average cost was 4.1 cents versus 2.0 cents, so the single loop again came in at about half.

All seven runs the four agents failed were missing product codes. The router did not have the product catalog, and in those seven runs it did not ask the pricing specialist for product codes, so the quote listed only product names. Olsen also points to a multiplication error in a handoff. On an order for 120 chairs, the pricing specialist got the multiplication wrong in two of three runs. The router recalculated once, and the other time copied the wrong total straight into the quote. On the other side, the single loop loaded all three skills every time, so progressive loading saved nothing in this case. The difference came from running lookups together in one context. The test covers one desk, one model, and made-up data, and Olsen writes that it should not be treated as proof that a single loop always wins.

Anthropic’s article closes on principles rather than on which design to pick: measure, change one thing at a time, and keep what holds up. Its reason is that when models change, so does our understanding of how to use them and the design worth recommending, so principles matter more than any particular design. If you have several subagents in hand, a good first step is to write down which of the three conditions, if any, each one meets.