On October 22, Anthropic published an article by Diane Sarkis from the Applied AI team, the people who help companies build agents on the Claude Platform. The article is long and covers several separate topics. Here we’ll look at just one of them: what to do with the subagents you already have in production. It’s an important topic because I run into it constantly in practice. People, influenced by all sorts of AI slop articles, demand that dozens of agents be spun up because that’s the fashion. Yet it often doesn’t help, and in fact it’s counterproductive.
Why subagents have spread so widely (and not only in development)
A subagent is an agent with its own context window, its own tools, and its own instructions, directed by a coordinator. Anthropic uses them itself, for example in its research system. They work well for verification, for parallel work, for separating permissions, and also for saving context.
In companies, though, they’ve become an organizational tool. Every team or type of problem gets its own subagent, and a central platform team builds an orchestrator on top of them. Anthropic simply calls this Conway’s law in the article: a system copies the communication structure of the organization that builds it (Melvin Conway formulated this back in 1967, so nothing new under the sun).
Frankly, it doesn’t surprise me. Splitting an agent along team lines is the politically easiest solution. Nobody has to hand anything over, and everyone has their own sandbox.
Where multi-agent architecture loses
Every handoff loses something. A subagent returns a summary to the orchestrator, not the raw data. The main agent therefore works with an extract of an extract. Anthropic compares it to a game of telephone: information thins out with every handoff.
Every call costs time. Calling a subagent means another nested model loop, with everything that entails. In a comparison, one customer measured a run roughly twice as short with a single agent as with their multi-agent variant.
Subagents proliferate. When every team deploys its own, the company ends up with hundreds of overlapping agents with no shared rules and no concrete owner. Meanwhile, every team adds its own sentence to the shared system prompt. Anthropic calls this a Frankenprompt: contradictory rules and no unified voice.
According to the article, one company found that with a dozen specialists inside its customer agent, it couldn’t maintain a consistent brand tone. And the added latency spoiled the customer experience.
What Anthropic proposes instead
One model, one context window, and an open loop with tools. The harness enforces the limits (number of turns, budget per call, approval of writes).
In each turn, the model issues a batch of tool calls. The harness runs them in parallel and returns the results in raw form to the same model. It decides what’s next: another batch, a question to the user, or an answer.
Whoever plans also executes. In the first turn, the model writes a plan into its context and keeps adjusting it as results come in. According to Anthropic, this is the main difference compared to an orchestrator with specialists. The plan is no longer written by one agent and executed by another, so it can be changed in the middle of the work.
Context is revealed gradually. At first, the model sees only short descriptions of Skills and tools. It loads the full text only when it needs it. That removes the main reason teams used to split the work: the fear that everything wouldn’t fit into one prompt.
Shared context gives better answers. An agent that has seen the results of all previous steps can connect them. A set of summaries from subagents can’t do that.
Procedures and domain knowledge move into Skills; actions and hard constraints move into tools. Exactly where to draw that line is a separate topic for the next installment.
When to keep subagents
Anthropic gives three clear conditions for when to keep subagents or introduce them:
- a single agent measurably loses performance because of an overloaded context,
- you need to handle multiple tasks concurrently, each getting a clean context window that you throw away when it finishes,
- the agent can’t pick the right tool, or the system prompt contains contradictory instructions.
On top of that, independent verification still applies, where the checker should not see how the result came about.
Draw the boundary along context. A good subagent gets a piece of work that needs little from the rest of the system and returns a compact result. Typically independent research branches, components with a clean interface, or blind verification.
If you split agents by type of problem, the game of telephone begins. Take a Czech e-shop with an agent that has a specialist for complaints, one for shipping, and one for payments. A customer asks: “When will the replacement for my defective blender arrive, and will you refund me the price difference?” You need all three to answer, and the orchestrator shuttles summaries back and forth between them.
Just starting? Build it right from the beginning
If you’re only now designing your agent, you have an advantage: there’s nothing to merge. All you need to do is avoid building a multi-agent structure out of caution.
The default choice is one agent. You add a subagent once measurement shows one of the conditions from the previous section. There’s no need to add one up front just to be safe. Splitting a finished agent is much easier than gluing it back together later.
Limits belong in the harness. Maximum number of turns, budget per task, and approval before every write operation (refund, order change). Within those bounds, the model does whatever it sees fit.
Everything has its place:
| What | Where | E-shop example |
|---|---|---|
| Procedure, rules, judgment | Skill | how to assess a complaint, when to escalate to a human |
| Actions and live data | Tool | order status, issuing a credit note |
| Conditions and permissions | Inside the tool | “first verify the customer’s identity” |
| Reference material needed occasionally | Knowledge base with search | terms and conditions, product specifications |
| Cheap and almost always needed | Code before the agent runs | looking up the customer by email |
Group tools by what the user wants to do. One tool per API endpoint quickly inflates their number. According to Anthropic, above 30–50 definitions, tool selection gets worse. Then tool search helps, showing the model only short descriptions and loading the full definition only when it needs it.
Enforce hard rules in the tool. A prompt is a recommendation, and the model occasionally bypasses it. If it must not answer about a delivery date without asking the carrier, have the order-status tool fetch that data itself. Why this matters so much is shown by the carrier story below.
Permissions are handled by tools too. Each tool checks what the calling user may see and do, and returns a refusal the model understands. One agent can thus serve a customer, a support operator, and a shift supervisor without a dedicated agent for each role.
Evals from day one. Ten real tasks, run each several times, and grade against a rubric. In addition, log which Skill the agent loaded and which tools it called. When you eventually consider a subagent, you’ll have something to compare against. (Frankly, this is the most boring and at the same time the most important piece of advice in the whole article.)
How to merge step by step
If you already have subagents in production, Anthropic recommends proceeding slowly and measuring each time.
Eval first, changes after. You build the eval (a set of test tasks with grading of the result) before you touch the first subagent. Ten sample cases are enough to start. What has worked well is one shared end-to-end set maintained by the central team, plus small sets that come with each Skill, supplied by the team that owns it.
At the start, it’s enough to grade the final answer against a rubric. As long as you still have an orchestrator, also track routing accuracy: did it pick the right subagent? After merging, you ask differently: did the agent load the right Skill, did it call the right tool? Over time it’s good to arrive at an eval that measures completion of the whole task, because that’s what decides when comparing architectures.
Where internal systems are hard to replay, Anthropic says it helps to record timestamps of important events. Targeted tests can later be assembled from them.
First call subagents as tools. The main agent holds the conversation with the user and calls subagents as a tool with a shared response schema. You don’t have to rewrite anything, and you get a baseline measurement to compare against. Fully handing the conversation over to a subagent makes sense only when it has to talk to the user directly.
Handoff losses and the latency of nested loops don’t disappear this way, of course. It’s an intermediate step.
Merge tightly coupled pairs first. Look at production. If a large share of requests goes through specialist A and immediately afterward through specialist B, that’s a merge candidate. The same goes for specialists who touch the same data.
Then one by one into Skills and tools. A subagent’s prompt becomes a Skill, and its API calls become tools via MCP. You compare the eval with and without the subagent. You keep the subagent only if the merged version does worse.
The carrier story
In my view, this is the most valuable part of the whole article. Practical experience.
Anthropic tried merging on a sample customer support agent. Merging one subagent into another reduced latency. At the same time, a task that had worked before stopped passing. The agent had an order-lookup tool at hand, so it answered on its own. It never asked the shipping specialist about the delivery date.
And now the key part: the error showed up in only one of two runs.
From this, Anthropic draws three rules:
- look at which specific tasks flipped from success to failure, because the overall score easily hides such a loss,
- the eval must include a task for every chain of agents that runs together in production, and for every rule the agent must not break,
- run every task multiple times.
I would draw one more conclusion. The subagent structure carried an unwritten rule: “ask shipping about the delivery date.” Nobody wrote it down anywhere, because the division of labor itself guaranteed it. In the merge it quietly vanished. Every layer of architecture you remove may carry rules you don’t know about until they break. That’s why you need to explicitly carry them over into a Skill or a tool when merging.
The migration kit
Anthropic has released single-agent-loop-kit on GitHub for this. It’s a guided process that helps you map the current architecture, evaluate the options, and verify which one holds up. It includes a demo on a simulated system, so you can try it out before you unleash it on a real agent.
The kit chains several Skills for the Claude API:
- build-eval helps build the first end-to-end set as well as the small sets for individual Skills,
- hillclimb iteratively tunes the application against an existing eval, so after merging a subagent you can have it refine the descriptions of Skills and tools and find out whether the merged version catches up with the original,
- prompt-audit looks in prompts for instructions written for older models,
- cost-optimize shows where the calls go and suggests savings.
It won’t do the merging for you. It helps with measuring, and that’s the essential part of the whole thing.
What to take away
I agree with the diagnosis. A lot of multi-agent architectures are a copy of the org chart, and you look in vain for a technical necessity in them. And I have to say, if subagents multiply in your system, you’ll have trouble getting rid of them, just like unnecessary staff in a company. You’ll have to put in quite a bit of work just identifying them.
But it’s also fair to remember who is writing this. A model vendor claims that its models can handle more in a single loop than you expect and that you can throw away the structure around them. That obviously suits them, if only so you don’t entertain the sinful thought of moving to cheaper models. There are few hard numbers in the article: a twofold speedup at one customer with no described methodology (and that’s pretty flimsy evidence). And their own carrier example shows that simplification has a price you won’t see without a good eval.
The only thing I’d adopt without reservations is the method itself: change one thing at a time, measure, and keep only what holds up. If you have an agent with five subagents and no eval, start with the eval. The merging can wait.
Sources: Building agents: When to fold subagents into your main agent loop (Anthropic, 10/22/2026), single-agent-loop-kit. As of 10/24/2026.
