Single agent vs multi-agent systems
Most failures in a multi-agent system come from the handoffs between agents, not from any single one.
The short answer
A single agent with clear tools is easier to test, to explain and to run. A multi-agent system splits the work between agents that pass results to one another. It is worth the extra complexity when the roles need different permissions or the task is too large for one context, and not before.
Decision table
| Question | Single agent | Multi-agent system |
|---|---|---|
| What it is | One model with a set of tools and instructions | Several agents, each with a role, that hand work to each other |
| Who owns the outcome | The team that owns the single agent | The same team, plus whoever owns each handoff |
| Typical duration | Days to a first working version | Longer, because each handoff needs its own tests |
| What you get at the end | One agent with a clear trace | A chain of agents with more traces to read |
| Main risk | Overloading one agent with too many tools | Errors that pass between agents and grow |
| Best for | Most workflows, and the first version of any agent | Work with separate roles, permissions or very large scope |
Use cases for single agent
- A support assistant with a few tools. One agent reads a ticket, looks up the account, and drafts a reply for a person to approve.
- A document checker. One agent checks a document against a checklist and flags gaps.
- A workflow with one approval step. The agent prepares the action and a person approves it. No coordination is needed.
- Any first version. Build one agent first. Its traces show where a second agent would help, if one is needed.
Use cases for multi-agent system
- Roles that need separate permissions. A research agent reads widely, and a payments agent can act only after a human approves. The permissions are separate by design.
- A task too large for one context. A long analysis is split across agents that each hold one section, then combined by a reviewer agent.
- Separate evaluation for each role. Each agent is tested on its own task, so a failure is traced to one role.
- Parallel work that can be checked. Several agents draft independently and a checker compares the drafts against the same rules.
Trade-offs
Single agent
Advantages. Simpler to test, trace and explain. Fewer handoffs, so fewer places for errors to hide. Cheaper to run and quicker to change.
Disadvantages. One context must hold every tool and instruction. Can become crowded as the tool list grows. Separate permissions are harder to enforce inside one agent.
Multi-agent system
Advantages. Roles can be permissioned and evaluated separately. Large tasks can be split across contexts. Parallel work can finish sooner.
Disadvantages. Each handoff can lose or distort information. More traces, more tests, more to maintain. Costs rise with the number of agents and calls.
How each option runs
Single agent, step by step:
- Step 1. Write the agent's instructions and its tool contracts.
- Step 2. Test it on a fixed set of cases, with traces kept for each run.
- Step 3. Add tools or steps only when a failing trace shows the need.
Multi-agent system, step by step:
- Step 1. Define each role, its permissions, and the exact format of each handoff.
- Step 2. Test each agent alone, then the handoffs between them.
- Step 3. Trace the whole chain on a fixed set of cases, and check where errors enter.
What drives the effort
- How many tools one agent needs before it starts to confuse itself.
- How many roles need different permissions.
- How much work the task holds, and whether it can be split cleanly.
- How much tracing and testing the team can keep up.
This site does not publish prices. The engagements page describes what each shape includes.
A checklist before you choose
- Does one agent with its tools fail for a reason you can name?
- Do roles need separate permissions that one agent cannot hold?
- Can the task be split along lines that do not need constant back-and-forth?
- Can the team trace and test each handoff?
If the first is no and the others are mostly no, start with one agent. Add roles only when a named failure needs them.
What people get wrong
- They split the work into agents before one agent has been tested.
- They add agents to fix a prompt problem, and the errors move to the handoffs.
- They skip traces, so a multi-agent failure cannot be explained.
A hybrid that often works
Start with one agent. Add a second only for a clear permission boundary, such as a step that must not act without approval. Keep the handoff format fixed and tested, and keep the number of agents as low as the task allows.
Common questions
Is a multi-agent system more capable?
Not by default. It can handle larger tasks or separate roles, but each handoff adds a place where information can be lost.
How do I tell which agent caused a failure?
Keep a trace of each run, with the input and output of every agent. Without traces, the failure is hard to locate.
Should each agent have its own evaluation?
Yes, for roles that act or decide. Also evaluate the chain as a whole, since errors can pass between agents.
What is the simplest first step?
A single agent with a clear tool list, a fixed evaluation set, and traces. Split only when a trace shows the need.