When to split an agent into subagents, and when one loop is better

Sooner or later every agent builder hits the same moment. The single loop is getting slow, the context window keeps filling up, and somebody says "what if we had a planner agent that hands work to a few specialist agents?" It sounds like good engineering. Split the problem, run the pieces in parallel, merge the results. Sometimes it is exactly right. Other times it turns one agent you could debug into four agents that quietly disagree with each other.

The good news is that the people who have shipped both designs have written down what happened, and the advice lines up better than the headlines suggest. This post walks through the main patterns, what they cost, where they break, and a simple test you can run on your own task before you commit to an architecture.

Start with the plain loop

Anthropic's Building effective agents post is still the clearest baseline. It separates workflows, where your code decides the path, from agents, where the model directs its own process and tool use. Its core advice is to find the simplest thing that works and add complexity only when it measurably improves results, noting that agentic systems "often trade latency and cost for better task performance." It also points out that an agent is usually just a model using tools in a loop based on feedback from its environment.

That framing matters because a lot of "multi-agent" designs are really workflows wearing a costume. If you already know the steps (research, outline, draft, critique), you don't need agents negotiating with each other. You need a chain of calls with checks between them, which your code controls. The same post describes that pattern as prompt chaining, and lists routing, parallelization, orchestrator-workers and evaluator-optimizer as separate patterns, each with its own fit. Picking the right one is half the battle.

The case for splitting: research and breadth

The strongest public argument for multiple agents comes from Anthropic's write-up of how it built its multi-agent research system. A lead agent plans the research, spins up subagents that search in parallel, and then pulls their findings together. On Anthropic's internal research eval, a setup with Claude Opus 4 as the lead and Claude Sonnet 4 subagents beat a single Claude Opus 4 agent by 90.2%. Their example is a question like listing the board members of every company in the S&P 500 information technology sector, which the multi-agent system split into chunks while the single agent ground through slow, sequential searches and failed.

The explanation they give is refreshingly unglamorous. In their analysis of the BrowseComp evaluation, token usage alone explained 80% of the performance variance, with the number of tool calls and the model choice as the other factors. Subagents work largely because each one gets its own context window, so the system as a whole can spend more tokens on the problem than one window allows. The post calls subagents a form of compression: each one explores a slice of the problem and hands back only the most important findings.

Then comes the bill. Anthropic reports that agents typically use about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more. They say plainly that this only makes sense when the task is valuable enough to pay for it, and that domains where agents need to share a lot of context, or where tasks depend heavily on each other, are not a good fit today. They name coding specifically as having fewer truly parallel pieces than research.

The case against: conflicting decisions

Cognition's Don't Build Multi-Agents post, published the day before Anthropic's, is the other half of the conversation. Its example is a Flappy Bird clone split into two subtasks, one for the background and pipes and one for the bird. One subagent misreads its task and builds something that looks like Super Mario Bros. The other builds a bird that doesn't match the game. The final agent is left trying to stitch together two misunderstandings.

The post boils this down to two principles. First, share context, meaning full agent traces and not just the one message describing a subtask. Second, actions carry implicit decisions, so two agents working in parallel make choices the other can't see, and conflicting choices produce bad results. Even after you give every subagent the full original task, the two halves can still come back in different visual styles, because neither saw what the other decided.

Cognition's recommendation is a single-threaded agent by default, and for very long tasks, a dedicated step that compresses the history into key details, events and decisions. They also point to Claude Code as of mid-2025 as a sensible middle ground: its subagents were mostly used to answer well-defined questions rather than write code, and they never worked in parallel with the main agent. The benefit was keeping all that investigative noise out of the main agent's history.

These two posts mostly agree

Read side by side, the two posts are less opposed than their titles. Both say coordination is the hard part. Both say subagents earn their keep when the work can be cleanly separated and the results can be compressed. Anthropic's own early failures, which included spawning 50 subagents for simple queries and subagents duplicating each other's searches, are basically Cognition's warning playing out in a research setting. Anthropic fixed them with much more detailed delegation: each subagent got an objective, an output format, guidance on which tools and sources to use, and clear task boundaries.

So the real question is not "single agent or multi-agent." It is whether your subtasks are independent enough that a worker can do its job well with a short brief and without seeing the other workers' choices.

Handoffs versus agents as tools

When you do split, there are two common ways to wire it, and the OpenAI Agents SDK orchestration guide describes both clearly. With agents as tools, a manager agent keeps control of the conversation and calls specialists like any other tool, so one agent owns the final answer and can enforce shared guardrails in one place. With handoffs, a triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn and answers the user directly.

The difference matters more than it looks. Agents as tools is the safer default for anything where results need merging, since the manager sees every worker's output and is the only one talking to the user. Handoffs fit routing problems, like a support bot that sends refund questions to a refunds specialist with its own prompt and tools. The same guide also lays out code-driven orchestration: using structured outputs to classify a task and pick the next agent, chaining agents, running an evaluator agent in a loop, or running independent agents in parallel with something like asyncio.gather. When the steps are predictable, it says, code orchestration is more deterministic in speed, cost and performance.

A practical test before you split

Here is the check we'd run on a real task. Write down the subtasks you'd hand to workers. For each one, ask whether a capable contractor could do it from a one-paragraph brief without phoning the other contractors. "Find every public filing that mentions this supplier between 2023 and 2025" passes. "Build the bird for our game" fails, because the bird depends on art style, physics and screen size decisions made elsewhere.

Next, ask what each worker returns. If the answer is a compact result, such as a list of companies, a set of citations or a yes or no, splitting compresses well. If the answer is a large artifact the lead agent must read in full, you're paying the 15-times token premium and then piping everything back through one window anyway. Anthropic's post suggests a middle path for that case: have subagents write their output to external storage and pass back a lightweight reference, so the coordinator isn't copying big outputs through its own history.

Then put rough numbers on it. If a single-agent run of your task costs a few cents and the answer is usually fine, a setup that uses several times the tokens has to buy you a visibly better answer, not just a faster one. If the task is a high-value research question where missing a source is expensive, the math can flip quickly. Our model comparison lists current per-token prices, which makes it easy to estimate a lead model plus cheaper worker models before you build anything.

Finally, decide who talks to the user. If more than one agent could end up writing user-facing text, you have a consistency problem waiting to happen. Keep one owner of the final answer unless you have a clear routing reason not to.

Guardrails that make splitting safer

If you go ahead, a few habits from the sources above are worth copying. Put effort scaling into the lead agent's prompt; Anthropic's version says simple fact-finding needs one agent with 3 to 10 tool calls, direct comparisons might need 2 to 4 subagents, and complex research might use more than 10 with clearly divided responsibilities. Give every worker the full brief format described earlier rather than a one-line instruction. Run independent workers in parallel, since Anthropic says parallel subagents and parallel tool calls cut research time by up to 90% for complex queries. And trace everything, because when a multi-agent run goes wrong, the bug is usually in what one agent told another, not in any single call. We covered the tracing side in tracing agent runs with OpenTelemetry, and budget limits in budget caps for agent runs.

If you want a longer treatment of how to evaluate and structure systems like this, Chip Huyen's AI Engineering covers agent patterns, evaluation and cost tradeoffs in one place.

The short version

Start with one loop. Move to a code-driven workflow when the steps are predictable. Add subagents when the work splits into genuinely independent pieces that each return something small, and when the task is valuable enough to cover several times the token cost. Keep one agent in charge of the final answer, give workers detailed briefs, and watch the traces. Most agents never need more than that, and the ones that do will tell you through slow, sequential runs and overflowing context long before you have to guess.