Recently multi-agent has been getting more popular.
But I keep having a question: are we actually solving a problem that requires multiple agents, or are we splitting something one agent could already do into several agents talking to each other, just because multi-agent is in fashion?
If all you do is split planner, critic, and reviewer into three roles, but underneath they still share the same model, the same information, and the same tools, then pass answers back and forth — is that just a more expensive, longer single-agent workflow?
Back to a practical question: in what cases should we actually split a system into multi-agent?
I’ve roughly worked out four criteria.
1. You need genuinely independent cognitive paths
AI is easy to steer.
That steering is not necessarily malicious prompt injection. It can be something very ordinary: once earlier context has already offered a hypothesis, later reasoning tends to keep going in that direction.
For example, an agent first proposes:
“The problem might be in the database.”
Then you ask the same agent to check. It will likely keep looking for evidence from the database direction. Even if you tell it “please critique the previous answer,” it has already seen that answer.
At that point the so-called critic has already been anchored.
So one legitimate use of multi-agent is to let different agents keep genuinely independent context and framing.
One agent starts from supporting the hypothesis. Another does not know the earlier reasoning at all, and investigates from the opposite direction. There can even be an agent whose job is to induce the others, to see whether they change their judgment too easily — so that not every agent starts from the same cognitive origin.
If several agents share the full context from the start and end up agreeing with each other, that kind of multi-agent probably did not produce real new information.
I think there is an important distinction here: collaboration is not necessarily valuable. We might as well try controlled disagreement.
2. The problem itself needs adversarial pressure, not discussion
The second case is when the task needs mutual challenge.
A lot of multi-agent systems look like this:
A proposes a plan. B says the plan is fine, with a few additions.
C summarizes both.
Everyone ends up with a longer answer.
That interaction is a lot like a meeting. It does not necessarily add reasoning depth. Adversarial work that is actually valuable should be more explicit.
For example:
Agent A must put forward a conclusion that can be verified. Agent B’s job is not to comment, but to find counterexamples. Agent C checks whether either side used unproven assumptions.
Agent D then rules on the evidence.
Using multi-agent to form a verification mechanism is different from the first case. The first aims at independence of thought. The second uses adversarial pressure for verification — and preferably with more than one kind of LLM.
If the work itself needs red teaming, audit, finding holes, proof and disproof, competing hypotheses — then splitting into multiple agents is easier to justify.
But the adversarial setup has to be institutionalized. It is not enough to write one line in the prompt: “Please boldly challenge the other agents.”
You should specify what can be attacked, what evidence is required, what counts as refutation, and how the final judgment is made.
Otherwise it easily turns into AIs being polite and commercially complimentary to each other.
3. A single agent’s attention starts to overload
More capability is not always better. When one agent takes on too many roles at once, it has to keep deciding:
- What should it attend to now?
- Which instruction has priority?
- Which tool to use?
- Which context is relevant to the current problem?
- Whether previous state still needs to be kept?
- Whether different skills conflict with each other?
The problem then shifts from “not capable enough” to “attention allocation.” For long-running agents, this gets more obvious over time.
To keep the working range narrow enough: a security agent only watches attack surface over the long term; a finance agent only maintains financial state; and so on.
An execution agent does not need the whole strategic discussion. It should stay on execution accuracy, difficulty, return, and so on. A research agent does not need write access to production. It should stay on checking, verifying, searching for cases.
That reduces interference between different context, skill, and responsibility.
If different tasks need to maintain their own independent context, memory, tool state, and focus over time, multi-agent can make each side’s work more accurate.
4. The workflow is already not a single line
The last one, and the one I think is often ignored: not all work is A → B → C → D.
A lot of agent systems still advance in a heartbeat style: wake up on an interval, check current state, decide the next step, execute, then enter the next state.
For simple flows, that is fine.
Real work is often not linear.
Different branches often run at the same time. A cutting department may take scheduled material from several departments at once. After a cut, operations reviews it. If it fails, it goes back for a recut. Or extra shots are needed, so production has to shoot again — and that shoot then queues against work already in hand, while subtasks may have their own urgency.
Films that pass operations still go to transcode and distribution. Distribution still has to stagger peak hours so the output is not judged as a bot.
A single agent is not completely unable to do this. You can maintain a large state machine inside one engine, keep checking every branch, and simulate different roles. As task complexity grows, that engine itself starts to become a scheduling system.
And it is hard to maintain.
This is where the value of multi-agent shows up. Each agent can have its own lifecycle and state. Different branches can actually run in parallel. Each can speak its own dispatch rules when problems appear. Some agents wait on the outside world; some keep working; they converge again through an explicit sync mechanism.
At that stage, what we are facing is no longer just AI reasoning. It starts to look more and more like a distributed system.
You have to consider:
- Who owns state.
- Who can modify state.
- Whether repeated execution causes problems.
- What happens when two agents operate on the same resource.
- Who takes over if an agent dies.
- How to tell the whole task is finished.
- When you need a lock.
- When you should use a lease.
- How to handle version conflicts.
These are genuinely hard inside a single agent.
If I were designing an agent system, I would first ask whether it cannot reasonably be compressed back into one agent.
So far I see about four kinds:
First: cognition cannot be compressed. We actually need independent angles of observation, so that one shared context does not drag all reasoning in the same direction.
Second: adversarial pressure cannot be compressed. The task itself needs different positions attacking, proving, and verifying each other.
Third: attention cannot be compressed. Different roles need to maintain their own context, memory, skill, or scope of responsibility over time.
Fourth: work topology cannot be compressed. The task already has real parallelism, branching, joining, resource contention, and different lifecycles.
If none of these conditions exist, a single agent will solve the problem better. Multi-agent is not free. More agents means higher cost: more communication, more state sync, more failure points, and it is harder to know who actually went wrong.
So don’t design agents first. Look first whether the problem contains differences that cannot be compressed, then decide how many independent execution units those differences should be split into.
That at least avoids a situation that is getting more common: creating a group of agents so they can collaborate, then starting to wonder what they are supposed to collaborate on — even though it looks cool.