When One Agent Isn't Enough (and When It Is)

The most common mistake in this field is reaching for several agents before you have used one properly. Teams of agents look like an org chart. They demo well, and every framework makes them easy to set up. But each extra agent adds cost, delay, extra coordination and one more place for things to go wrong. This path is about building teams of agents well. The first skill is knowing when not to.

Two well-known write-ups frame the debate. Anthropic's Building effective agents says to find the simplest solution and add complexity only when it clearly improves results. Cognition's Don't Build Multi-Agents argues that agents who do not share full context make clashing, poorly informed decisions. Then Anthropic built a multi-agent research system and found the other side. For broad research that can be split up, a lead agent with helpers beat a single agent by a large margin on its own tests. It also used many more tokens. Both views are right, for different kinds of tasks. Your job is to recognize the kind.

What several agents really give you

• Clean focus. Each agent works in a fresh, focused context, instead of one stuffed with everything every other step produced. This is the strongest reason.
• Speed through parallel work. Wide jobs, such as researching many sources or reviewing many files, finish in the time of the slowest branch and not the sum of all of them.
• Specialists. Each role can have its own instructions, tools and even model: a cheap fast model to route, a strong one to reason, a small one to extract.
• Separate permissions. The agent that reads untrusted web pages can change nothing. The agent that can change things never sees raw untrusted content. Splitting by permission is a security design.
• Independent checking. A reviewer who did not do the work, and was told to look for faults, catches mistakes the author cannot see.

What it costs

Be honest about the bill. Anthropic reported that, in its own system, an agent used roughly 4 times the tokens of a plain chat, and a team of agents roughly 15 times. So the task must be valuable enough to pay for that. Delay grows with every step that has to wait for another. And mistakes add up. If each step in a chain is 95 percent reliable, five steps in a row are only about 77 percent reliable together.

def chain_reliability(per_step: float, steps: int) -> float:
    return per_step ** steps

for steps in (1, 3, 5, 8, 12):
    print(f"{steps:>2} steps @ 95% each -> {chain_reliability(0.95, steps):.0%}")

#  1 steps @ 95% each -> 95%
#  3 steps @ 95% each -> 86%
#  5 steps @ 95% each -> 77%
#  8 steps @ 95% each -> 66%
# 12 steps @ 95% each -> 54%
#
# Every hand-off you add must either raise a step's reliability (verification)
# or remove steps from the critical path (parallelism). Otherwise it's a tax.

A five-question test

• Have I built the single-agent version and measured it? If not, stop here. You cannot judge a team without the baseline it has to beat.
• Is the work wide (many independent branches) or deep (each step needs the last)? Wide favors several agents. Deep favors one agent with good context.
• Would one context window overflow or get noisy before the job is done? That is a vote for separate agents.
• Do different parts need different permissions or trust? That is a vote for splitting by permission.
• Is each task worth enough to pay about 15 times the tokens? If a task is worth a few cents, it is probably not a multi-agent task.

From the shape of the task to a design

• A straight-line task with shared context, such as building a feature or fixing a bug: one agent with good tools and context care.
• Broad research across many separate sources: a lead agent with parallel workers.
• Mixed trust, where it reads untrusted content AND takes actions: split by permission.
• Quality matters and mistakes are costly: one agent that makes and one independent reviewer.
• Lots of requests, mostly easy: a router that sends easy ones to a small model and hard ones up.

A worked example: support triage

A support inbox gets billing questions, bug reports and feature requests. The first instinct is three specialist agents plus a manager. A better first step is one agent with three tools (look up the account, search the docs, make a ticket) and a clear prompt. Measure it on 50 real tickets. Say it fails mostly on one kind, because its context fills with unrelated documents. Then add a cheap router that sends that kind to a specialist with a narrower prompt and fewer tools. You added one agent because the data asked for it, not because the diagram looked complete.