When one agent should become many

Every agent we have built is one agent: one system prompt, one set of tools, one loop. Push enough different work through it and the strain shows.

The fix is more than one agent, each good at one thing. This post is about when to split, and the three ways specialists can work together.

The overloaded system prompt

Watch what happens when you ask one agent to do everything. Its system prompt grows into a committee.

You are an assistant that:
  [Research Role] search for information, prefer reliable sources, summarise...
  [Coding Role]   write example code, test it, handle errors...
  [Writing Role]  draft in a clear voice, structure the piece, edit...

Three roles in one prompt pull against each other. The instructions for good research crowd the instructions for good code. The model juggles three jobs on every call, and does each one a little worse than an agent built for that job alone. The prompt is long, the tools are a superset of three tools sets, and the whole thing is harder to test because any change risks the other two roles.

A specialist agent avoids all of that. A research agent has a research prompt and research tools, and nothing else competing for its attention. Split the committee into specialists and each one gets sharp.

The two questions that pick a pattern

Once you have specialists, they have to collaborate, and there are three ways to arrange that. Two questions tell you which.

Who decides the next agent? Either you do, in code, or the model does, at runtime. If the order of work is knowable in advance, "research, then write, then review", you can write it down. If it depends on the request, "this one needs code, that one just needs research", the model has to choose.

Is the context shared? Either every agent sees the same growing conversation, or each agent works in its own context and passes back only a result. Shared context keeps everyone informed and grows large; isolated context stays lean and hides detail between agents.

Those two questions produce the three patterns.

Two questions: who picks the next agent, and is the context shared. They pick the pattern.

The three patterns

Workflow: you decide the order, in code. When the sequence is predictable, write it as code. Research, then write, then review, runs in that order every time because you said so. This is the workflow-versus-agent decision from the very start of this series, one level up: a workflow of agents. Predictable, testable, no surprises.

Agent as tool: the model calls a specialist and gets a result back. The orchestrator treats each specialist as a tool. It decides at runtime which to call, the specialist works in its own context, and only the result returns. The orchestrator stays in charge throughout.

Transfer: the model hands control to a specialist. Instead of calling and waiting, the orchestrator transfers control entirely. The specialist takes over the conversation, inherits its history, and runs with it. Control moves, rather than a result coming back.

Workflow, agent-as-tool, transfer: three ways for specialists to collaborate.

When not to split at all

Reaching for multi-agent too early is a common mistake, because it buys capability at a real cost. More agents mean more model calls, more moving parts, and more places to go wrong, the same trade as reaching for an agent over a workflow, now at a higher level.

Split when the roles genuinely conflict in one prompt, or when a specialist's work would flood the orchestrator's context, or when different requests need genuinely different pipelines. Stay single when one focused agent handles the job, because one agent you can reason about beats three you cannot.

What to take from this

• One agent asked to do three jobs does each worse than a specialist built for it. Splitting the committee into focused agents is the fix.
• Two questions pick the collaboration pattern: who decides the next agent (you in code, or the model at runtime), and whether the context is shared or isolated.
• The three patterns are workflow (you order it), agent-as-tool (the model calls a specialist and gets a result), and transfer (the model hands over control). Split only when the roles genuinely conflict.

The rest of this chapter builds all three. The most predictable one comes first: a workflow of agents, where you define the order in code. The next post starts there.