When one agent becomes five

An agent that keeps losing the thread on a long task looks like a staffing problem, and staffing problems have an obvious fix: hire more. That instinct is why so many teams end up with five agents and one very surprising invoice. This lesson is about what the extra agents actually do for you, what they always cost, and the small number of shapes worth wiring up.

1What splitting an agent actually does

You are not adding four more brains. You are cutting one context into five and adding a message-passing layer between the pieces. Both halves of that are real, and the second one is the half people forget.

What you gain. Each worker gets a smaller, cleaner context — its own instruction, its own tools, its own transcript. A worker that only searches never sees the formatting rules, so the formatting rules never crowd out the search. That is the same effect What the loop remembers within one run described inside one run, applied across processes. And when subtasks do not depend on each other, they run at the same time, so a job that took six sequential minutes finishes in ninety seconds.

What you pay. Every worker re-reads a brief. Every worker's output is read again by whatever merges it. The orchestrator spends tokens deciding what to dispatch, and spends them again when a worker comes back with something unusable. A multi-agent run costs several times what the same task costs a single agent. The multiplier depends entirely on how chatty your workers are and how much of the brief you resend, so measure yours rather than trusting any published figure, including a vendor's.

There is a second cost that never shows on an invoice. Workers cannot see each other's transcripts, so they make silently incompatible decisions. One picks a date format, another picks a different one. One decides the answer should be a summary, another writes bullet points. Nothing errors. The merge step receives two coherent halves of two different answers and has no way to know which assumption was right, because it never saw either agent decide.

Splitting an agent splits its context. Anything two workers both needed to know is now either something you pass explicitly, or something they will each quietly guess at.

2The two patterns that hold up

Almost everything worth building is one of these two, or a shallow nesting of them.

Both names appeared in A loop, not a brain, in the list of workflow patterns, and that is not a contradiction — it is the same test doing its job. That lesson asks who picks the next step, and the answer here is whether the model chooses the decomposition. When you enumerate the subtasks in your own code, this is a workflow that happens to run several contexts at once, and everything A loop, not a brain says about a drawable path and a known bill still holds. When an orchestrator reads the task and decides at run time how many workers there are and what each one is for, the same picture is an agent, and you have bought its unpredictability along with its flexibility.

Orchestrator-worker. One agent owns the plan. It reads the task, decides what the separable pieces are, writes a brief for each, dispatches them, reads what comes back, and decides whether it has enough. Workers are ordinary agents with a narrow tool set and no knowledge of each other.

The whole quality of this pattern lives in the brief. A brief that says "research the pricing" produces two workers doing the same search and neither of them answering the question. A brief that works states four things: the objective in one sentence, the exact output shape you want back, which tools to use, and the boundary — what this worker must not go and do. Anthropic's own write-up on their research system lands in the same place: their most common coordination failures were spawning workers for a task that did not need them, duplicated effort, and task descriptions too vague to act on.

Parallel fan-out. The same worker prompt over many inputs, with no orchestrator reasoning in between. This is map with a model inside it. Forty companies, the same three questions about each. Two hundred support tickets, the same classification. It is the cheapest kind of multi-agent work because there is no coordination at all — you wrote the decomposition yourself, in code, and no model spends a token deciding it.

What does not hold up is worth naming, because it is what people build first. A free-for-all where every agent can message every other agent: the message volume grows with the square of the agent count, nothing owns the plan, and there is no single place to cap or debug. Debate loops, where two agents argue to a consensus: expensive, and the wins are hard to reproduce outside the write-up that reported them. Deep hierarchies: every level adds a full round-trip of latency before any real work starts, so three levels of orchestration is three model calls of pure overhead on every task.

import concurrent.futures as futures

from anthropic import Anthropic

client = Anthropic()
MAX_WORKERS = 5          # a ceiling, not a target

def run_worker(brief: str) -> str:
    """One subtask, its own context. This worker never sees the others."""
    resp = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1000,
        system=(
            "You answer one narrow question and report only what you found. "
            "If you cannot find it, say so. Do not guess and do not broaden the question."
        ),
        messages=[{"role": "user", "content": brief}],
    )
    return resp.content[0].text

def fan_out(briefs: list[str]) -> list[str]:
    if len(briefs) == 1:
        return [run_worker(briefs[0])]            # one subtask is not a fan-out
    if len(briefs) > MAX_WORKERS:
        raise ValueError(f"{len(briefs)} subtasks is a batching problem, not a fan-out")
    with futures.ThreadPoolExecutor(max_workers=MAX_WORKERS) as pool:
        return list(pool.map(run_worker, briefs))

# Each brief is complete on its own: objective, output shape, boundary.
briefs = [
    "Who currently chairs the board of company A? Return the name and one source URL. "
    "Do not research anything else about company A.",
    "Who currently chairs the board of company B? Return the name and one source URL. "
    "Do not research anything else about company B.",
]
for brief, finding in zip(briefs, fan_out(briefs)):
    print(brief[:40], "->", finding[:80])

Two things in there are load-bearing. MAX_WORKERS raises rather than silently dropping subtasks — a fan-out that quietly discards work is the worst kind of bug, because the output still looks complete. And each brief repeats its own boundary, because a worker that has no idea another worker exists will happily expand its scope into that worker's job.

3The rule, and how to know you were right

Coordinate only when the subtasks are genuinely independent, or the task is too big for one context and the value is worth the multiple. That is the whole rule. Nearly every multi-agent setup that disappointed its team failed one of those two tests before a line of it was written.

Writing code is the standard example of a task that fails this test. Every edit depends on every earlier edit; two workers writing two files are making constant implicit decisions about names, shapes and conventions that the other one cannot see. Broad research is the standard example of a task that passes it: forty independent lookups, merged at the end, where being wrong about one does not corrupt the other thirty-nine.

Being blunt about it: most multi-agent setups are not worth it. They usually get built because a single agent was struggling, and a single agent struggling is far more often a tool-design problem, a context problem, or a missing step limit than a headcount problem. Fix those first — they are Designing a tool a model can actually use, What the loop remembers within one run, and Planning a run, and knowing when to stop, they cost nothing extra to run, and they frequently make the split unnecessary.

If you do split, prove it. Keep the single-agent version working and run both over the same twenty tasks. Record, for each: whether the answer was right, the total tokens across every agent in the run, and wall-clock time. You will get one of three results. The multi-agent version is clearly better and the multiple is worth it, so ship it. It is clearly better on time but not on quality, which is still a real win for anything a user waits on. Or it costs several times as much for a difference you cannot see, which is the common outcome — and the useful one, because now you know, and you can go back to the one agent with a clear conscience and a much smaller bill.