What are Multi-Agent Systems? When One Agent Is Not Enough

One agent with a handful of tools can already do a lot. But some problems are too broad for a single model to hold in its head: too many sources, too many tools, too many specialities. That is where multi-agent systems come in, with several agents, each with its own role, instructions and tools, cooperating on one goal. They are powerful, and often overused.

What is a multi-agent system?

In a multi-agent system, a task is split across two or more LLM-driven agents that communicate with each other. The agents may share the same underlying model or use different ones. What differs is what each agent is told to do, which tools it can call and what it gets to see. If you are new to agents, read What is Agentic AI? first.

Why split the work?

• Context management. A model’s context window is finite, and attention degrades when it is crowded. A specialist agent sees only what it needs, not the whole project history.
• Specialisation. A focused prompt and a small toolset are easier to get right than one prompt that covers everything.
• Parallelism. Independent sub-tasks can run at the same time, which cuts wall-clock time.
• Independent checking. A reviewer agent with fresh context can catch mistakes the author agent is blind to.
• Modularity. You can improve, test or replace one agent without touching the rest.

Four common architectures

Orchestrator–worker (hierarchical)

A lead agent decomposes the task, delegates sub-tasks to workers and assembles the results. This is the most widely used pattern, and also the easiest to reason about, because control flows in one direction.

Pipeline (hand-off)

Agents work in sequence, each passing its output to the next, like stations on an assembly line: analyse, then design, then implement, then test. It is close to a workflow (see agents vs. workflows), with an LLM at each station.

Critic and generator

One agent proposes, another critiques, and they iterate. It is a good fit when quality criteria are clear, such as code that must pass tests or text that must meet a rubric.

Peer collaboration (group chat)

Several agents with different roles talk in a shared conversation and decide who speaks next. It is flexible and fun to watch, and it is also the hardest to control, test and keep within budget. Research frameworks such as AutoGen popularised this style of programming.

The hidden costs

• Tokens multiply. Every agent has its own context, and messages between them are re-read repeatedly. Multi-agent runs can cost several times more than a single agent.
• Coordination overhead. Agents duplicate work, contradict each other, or wait for each other. Someone has to define who owns what.
• Errors propagate. If one agent hands another a wrong fact, the second agent has no way to know, and may build on it with confidence.
• State is hard. Free-text messages are a poor way to pass large or structured data. Information is lost or garbled at every hand-off.
• Debugging is harder. You need traces that show which agent said what, to whom, and why.

When one agent is the better answer

Multi-agent designs shine on broad, parallelisable problems, such as researching many sources at once. They are a poor fit for tightly coupled tasks where every step depends on shared, detailed state. Scientific computing is a good example. A recent paper from the Aspuru-Guzik group, El Agente Gráfico, argues that splitting work across many LLM agents is “fundamentally misaligned” with scientific workflows, where the main challenge is reliably passing large, structured numerical state between computations. Its answer is a single agent whose planning sits inside a type-safe execution graph, so that data travels as typed objects instead of as text in a context window. The same group’s El Agente Quntur uses a hierarchical multi-agent design for quantum chemistry. Both are reasonable; the right choice depends on the problem. More in agentic AI for science.

A practical rule of thumb

1. Build the single-agent version first and measure where it fails.
2. Split off a sub-agent only when you can name the specific problem it solves, such as context overflow or a need for independent review.
3. Keep hand-offs small, structured and validated, and avoid passing raw prose where a typed object will do.
4. Give every agent a clear owner role, a budget and a stopping rule.
5. Log the full conversation. When a multi-agent system fails, the trace is the only way to find out why.

Before you put such a system in front of real users, read how to evaluate and secure AI agents.