Single Agent vs Multi-Agent: When One Agent Is Enough

Use a single agent unless you can point to a specific problem it cannot solve. A well-prompted agent with good tools handles most tasks, costs less, responds faster and is much easier to debug. Reach for multiple agents when the task is too wide for one context window, has independent parts that can run in parallel, or needs a reviewer who is independent of the author.

Start with the single-agent baseline

Before designing a team, build the simplest version: one system prompt, the tools the task needs, and a loop that runs until the model stops calling tools. Measure it on a handful of real examples. This gives you a baseline for quality, cost and latency. Any multi-agent design must beat that baseline on something you care about, otherwise it is complexity for its own sake.

Signs one agent is not enough

The context fills up

If a task requires reading far more material than fits comfortably in one context, or if tool results crowd out the instructions, subagents help. Each subagent processes a slice and returns a compact result.

The work is parallel

Checking ten sources, reviewing twenty files, or testing five hypotheses are independent jobs. A single agent does them one after another. Parallel subagents finish in roughly the time of the slowest one.

Tool sets conflict

An agent with forty tools picks the wrong one more often. Splitting into specialists, each with four or five tools, makes choices clearer and lets you grant permissions narrowly.

You need independent review

A model reviewing its own output in the same conversation tends to agree with itself. A separate reviewer with a different prompt and no memory of the author's reasoning catches more.

The roles need different behaviour

Creative brainstorming and strict validation pull the prompt in opposite directions. Separate agents let each prompt be clean.

Signs you should stay with one agent

• The task is a short sequence of steps that fits easily in one context.
• Steps depend tightly on each other, so each agent would need the full history anyway.
• Latency matters and there is nothing to parallelise; extra agents only add round trips.
• You cannot yet describe how you would measure whether the team beats one agent.

A decision table

Question	If yes	If no
Does the task exceed one comfortable context?	Consider subagents	One agent
Are there independent subtasks?	Parallel workers	One agent or a chain
Does quality need an independent check?	Add a reviewer	Skip it
Are there many unrelated tools?	Split by specialty	One agent

Measure, do not guess

The honest way to decide is to run both designs on the same test set. This small script times and counts tokens for any agent function you pass in, so you can compare designs side by side.

import time

def benchmark(name, agent_fn, tasks):
    start = time.perf_counter()
    results = [agent_fn(t) for t in tasks]
    elapsed = time.perf_counter() - start
    print(f"{name}: {len(tasks)} tasks in {elapsed:.1f}s "
          f"({elapsed / len(tasks):.1f}s each)")
    return results

# Plug in your two designs:
# single = benchmark("single", single_agent, tasks)
# multi  = benchmark("multi", multi_agent, tasks)
# Then score both result lists against your expected answers.

Add token counts from response.usage and a quality score, and you have the three numbers that matter: quality, cost, speed. A later post builds a full A/B harness.

Common mistake

The most common error is copying a team structure from a demo because it looks impressive. A planner, researcher, writer and editor sounds powerful, but for a three-paragraph summary it is four times the cost for little gain. Match the structure to the task, not to the demo.

A worked example of the decision

Imagine two tasks. The first: "Summarise this 2-page changelog for customers." The input is small, there is one output, and nothing can run in parallel. One agent is the right answer. The second: "Audit these 40 repositories for outdated dependencies and write a report." Each repository is independent, the total material is far beyond one context, and a final report must merge everything. Here, one subagent per repository (or per batch) with an orchestrator that merges the findings is a clear fit.

Notice that the deciding factors were not "how smart is the task" but the shape of the work: size, independence and the need for a merged result. Look at the shape first.

A middle path: workflows before agents

Between one agent and a free-roaming team sits the workflow: your code calls the model in a fixed sequence, perhaps with a branch or a loop. A workflow gives you most of the benefit of specialisation, with predictable cost and easy debugging, because the control flow is ordinary code. If you can write the steps down in advance, prefer a workflow. Use model-directed delegation only when the steps genuinely depend on what the model discovers along the way.