When to split into several agents

Why it matters

Every agent framework ships a demo of five agents: a planner, a researcher, a critic, a writer, a reviewer. Most of those systems would be cheaper, faster and easier to debug as one agent with a good tool set, and the engineers who built them cannot say what the split bought. Interviewers ask "why several agents?" because the honest answers are few and specific.

The idea

The default is one agent

An agent is a model in a loop with tools. Current frontier models hold a million tokens of context and choose correctly among dozens of tools, so one agent with search, a database, a calculator and an email tool handles most tasks end to end. It has one context, one prompt, one trace, and nothing to coordinate. Add a second agent only when you can name the reason, and the reasons come down to five.

Five reasons to split

Context isolation. A long task fills the window with intermediate noise: forty search results, three drafts, a stack trace. A sub-agent that reads the forty results and returns a two-paragraph summary keeps the parent's context small and its attention sharp. The parent pays for the summary, not the pile. This is the most common legitimate reason.

Specialisation. Different parts of the job want different prompts, different models or different tools. A cheap, fast model triages; a strong model reasons; a code-tuned model edits. Cramming those into one prompt gives you a prompt that is mediocre at all of them.

Parallelism. Independent subtasks can run at once. Researching four competitors is four agents for one minute, not one agent for four, provided the parent can merge what comes back.

Separation of trust. An agent that reads untrusted web pages should not hold the tool that sends email, because a prompt injection in a page becomes an outbound message. Splitting the reader from the sender turns a prompt problem into a permission boundary the runtime enforces.

Organisational ownership. Teams own agents the way they own services. The billing team's agent exposes a contract; the support team's agent calls it. The boundary is an API, which is what agent-to-agent protocols standardise.

What the split costs

Each boundary is a place to lose information. The parent must explain the task to the child, the child must report back, and both explanations are lossy and cost tokens. A handoff that takes 2,000 tokens of context to set up, done ten times, is 20,000 tokens you did not pay with one agent. Coordination logic is code you now own. Failure modes multiply: loops between agents, cascades of bad output, two agents answering one question differently. And "the model did the wrong thing" becomes "which of the four did", which the Observability across agent boundaries lesson exists to answer.

The workflow test

Before you add an agent, ask whether a workflow pattern would do: orchestrator-workers, where one model plans and spawns workers with fixed prompts; parallelization, where the same prompt runs on several inputs at once; routing, where a classifier picks a path. These are multi-call, not multi-agent. The control flow is in your code, the workers do not decide what to do next, and nothing hands off a conversation. If a workflow gives the same parallelism and isolation without agent-to-agent negotiation, it is the better design.

A decision list

Split when at least one holds: the parent's context would otherwise fill with material it only needs summarised; subtasks are independent and total latency matters; a tool must be withheld from an agent that reads untrusted input; a different model or prompt is clearly better for one part; another team owns the capability. Do not split because the task is long, because the prompt is big, or because the framework makes it easy. If the only reason is parallelism or isolation, try a workflow first.

	Single agent	Workflow pattern	Multi-agent
Context size	One window holds everything; grows with the task	Each worker sees its input; the parent sees results	Each agent has its own window; handoffs carry the rest
Parallelism	Only parallel tool calls within a turn	Natural: fan out workers in code	Natural, but merging results is on you
Trust boundaries	None; every tool is reachable	Per worker, fixed in code	Per agent, enforced by the runtime
Complexity	Lowest; one loop, one trace	Moderate; control flow in code	Highest; coordination, handoffs, loops to guard
Fits	Most tasks	Decomposable tasks with known steps	Open-ended tasks with trust or ownership splits

Trade-offs

The split that saves context costs tokens at every handoff, so it pays only when the isolated material is large relative to the handoff. Specialised agents drift apart: two prompts are two artefacts to keep in step. Parallel agents finish at different times and the slowest sets the latency. Trust boundaries are real only if the runtime enforces them; an agent that can ask another agent to send email has not been isolated, merely indirected.

In an interview

Say: "I start with one agent and a good tool set, and I split only for a named reason: context isolation, specialisation, parallelism, a trust boundary or team ownership. If the reason is parallelism or isolation alone, a workflow pattern usually does it with less machinery." At junior depth, know that one agent is the default and that more agents means more tokens and coordination. At mid depth, name the five reasons and the workflow patterns that cover the first three. At senior depth, argue the trust case and price the handoff overhead. Expect: "Your research agent is slow; would more agents help?" Only if the slow part is independent work, and then a parallel workflow comes first.