← Deep dives

Deep dives · 2026-10-23 · Advanced

Multi-agent systems: the trade-offs of role division and collaboration

A multi-agent system is a design that tries to solve complex tasks by assigning roles to multiple LLM agents and having them communicate with each other. Recent research is moving toward learning who takes which role and who talks to whom, but results are also emerging showing that in real user-facing tasks, multi-agent systems often perform worse than a single agent or just use more tokens.

Contents
Key points
  • Multi-agent design comes down to four decisions: how to split the task, which model gets which role, who communicates with whom, and who gets credit for the result.
  • Recent research is moving toward learning or adapting these decisions to the situation instead of fixing them, as in role assignment (Meta-Debate), communication structure (MANTA, ACTS) and separating planning from worker selection (DeOrch).
  • Collaboration is not always a gain. In τ²-bench experiments involving conversations with users, multi-agent systems did worse than a single agent in 12 of 13 cells. In a financial document review experiment, they caught more defects but also produced more false positives and used 2.2–2.4 times as many tokens.
  • A model with strong reasoning ability is not necessarily good at collaboration (CRAFT), and the value of the 'different answers' produced by multiple agents often comes from diversity of perspective rather than accuracy.
  • Before adopting one, a fair benchmark is to compare it with spending the same token budget on multiple runs of a single agent.

Why it was needed: the limits of leaving everything to one model

A single agent, built from one LLM with one system prompt and a few tools, is easy to build and its behavior is easy to trace. But as work becomes long and complex, one agent has to plan, find information, fix code and verify results. The context window (the amount of text a model can see at once) fills up quickly, and there are limits to how well a model can review its own answers.

A multi-agent system is a design that splits this work among multiple agents. MANTA paper gives four reasons why LLM-based multi-agent systems solve complex problems well: task decomposition, agent specialization, information exchange and intermediate verification. It is the same logic as a human organization separating planning, execution and review.

Another motivation is 'different perspectives'. A study applying multi-agent deliberation to legal reasoning paper proposed two frameworks inspired by court procedures. Overall performance was similar to a single LLM, but the answers produced were quite different. The multi-agent setup sometimes solved cases the single model could not, and vice versa. The authors report that the multi-agent approach did better particularly on questions that require critical examination from multiple perspectives.

However, it was not clear when the expectation that 'splitting work leads to better results' holds. This article covers how role division is designed, along with recent experiments that examined whether collaboration actually pays off.

Core idea: building a project team

A multi-agent system can be compared to building a project team. The team lead breaks down the work (task decomposition), decides who gets each piece (role assignment), sets up the meeting structure (who reports to whom and who consults with whom), and, when the project ends, evaluates who did well and who held things back (credit assignment).

The key point of this analogy is that adding more team members does not automatically improve results. More meetings mean higher communication costs, people focused only on their own part can miss the big picture, and when things fail it is hard to tell who is responsible. Multi-agent systems face exactly the same problems. ACTS paper frames the decision of 'who talks to whom and when' as a balance between collaboration performance and token costs that grow exponentially with the number of agents.

So research in this field falls into four broad questions: how to split the work, which model suits which role, how to design the communication structure, and how to divide the single reward received by the whole team among the individual agents (credit assignment). Each of the following sections answers one or more of these four questions.

How it works: decomposition, assignment, communication, verification

The most common form is hierarchical. A main agent (the planner or orchestrator) receives the task, splits it into subtasks and hands them to subagents (helper agents that handle specific subtasks). This is the structure M-GRPO paper addresses: one main agent responsible for planning and several subagents that do the actual work by calling tools over multiple turns.

The first step is task decomposition. DeOrch paper has the planner split the task first, without knowing which workers are available. If worker information is tied to the plan, the planner has to be retrained every time the worker pool changes. The second step is assignment. DeOrch uses a lightweight matcher that estimates fit by observing how workers behave on a fixed set of probe problems, and during execution it keeps adjusting with a contextual bandit (a simple reinforcement learning technique that chooses among options depending on the situation and learns from the outcome). A study on dynamic role assignment paper holds a Meta-Debate to decide 'who takes which role' before the main debate. Candidate models put forward arguments tailored to each role (proposal), then score each other using data and role-specific criteria (peer evaluation), and the best-fitting model is selected for each seat.

The third step is communication. The connection structure through which agents exchange messages is called the topology. Letting everyone talk to everyone gives rich information but makes token usage explode; connecting agents in a single chain is cheap but blocks information. MANTA paper starts from an initial topology tailored to the task, monitors the collaboration log during execution, and when it judges the current organization to be inadequate, modifies roles, connections, execution order, information visibility and verification paths within set limits. The task's input/output format and the agent budget are not changed.

The last step is verification, synthesis and learning. When a result comes out, the whole team receives a single success or failure signal, and it has to be split into planning errors versus worker errors to see what to fix next time. DeOrch assigns credit conditionally to decomposition decisions and collaboration decisions, while M-GRPO computes group-relative advantages separately for the main agent and the subagents to divide credit by level.

One cycle of a hierarchical multi-agent systemTask → Planner; Planner → Worker assignment(Subtasks); Worker assignment → Worker A; Worker assignment → Worker B; Worker assignment → Worker C; Worker A → Worker B(Communication); Worker B → Worker C(Communication); Worker A → Verification·synthesis; Worker B → Verification·synthesis; Worker C → Verification·synthesis; Verification·synthesis → Final answer; Verification·synthesis → Credit assignment; Credit assignment → Planner(Learning)TaskPlannerTaskdecompositionWorkerassignmentRole·fitWorker ASearchWorker BTool executionWorker CReviewVerification·synthesisFinal answerCreditassignmentWhocontributed?SubtasksCommunicationCommunicationLearning
One cycle of a hierarchical multi-agent system The planner breaks the task into parts and assigns workers; the workers communicate with each other as they work, and then the results are verified and synthesized. The dashed line is the learning loop that assigns credit based on the results and feeds it into the next plan.

How it developed: what the foundational studies did differently

The foundational studies of 2025 addressed 'how to divide work among multiple actors' from both the operations side and the training side. CrowdAgent paper, inspired by real crowdsourcing companies, manages the entire data labeling process with multiple agents. Its core is assigning tasks to different labeling actors — LLMs, small language models (SLMs) and human experts — while also managing the balance between quality and cost. It shows that role division is a resource allocation problem that includes not only models but also people.

M-GRPO paper tackled the training problem directly. Previously, all agents were trained as a single LLM, which the authors saw as limiting performance because each role deals with a different data distribution. Training a different LLM for each agent creates new problems: agents are called at different frequencies, the number of subagent calls varies across Rollouts (single runs in which the model actually executes the task), and agents are hosted on different servers, which breaks backpropagation. M-GRPO solved this with Trajectory Alignment, which builds fixed-size batches even when call counts differ, and a decoupled training pipeline in which servers exchange only minimal statistics through shared storage. The authors report that it consistently outperformed single-agent GRPO on GAIA, XBench-DeepSearch and WebWalkerQA.

In 2026, research followed that made roles and structure themselves flexible. Dynamic role assignment paper, when added on top of existing debate systems, was up to 74.8% better than filling all roles with the same model and up to 29.7% better than random assignment (depending on the task and assignment combination). MANTA paper averaged 74.0 points across five benchmarks covering information seeking, tool use, planning, workflow execution and mathematical reasoning, 5.8 percentage points higher than the strongest baseline. DeOrch paper achieved higher performance than competing learned orchestrators while using fewer worker calls, and its gains held without retraining when moved to a worker pool it had never seen.

In the same period, studies also appeared that examined 'whether collaboration actually works'. CRAFT paper is a benchmark in which each agent can see only part of a 3D structure and must coordinate using natural language alone. Testing 8 open-weight models and 7 frontier models, including reasoning models, showed that strong reasoning ability did not mean good coordination, and small open-weight models sometimes matched or beat frontier models. Better individual communication did not translate into team success. The study also offered a framework for diagnosing failures as errors in spatial understanding, estimating others' thinking (belief modeling) and context-appropriate communication.

How role-division research has evolved

  1. 2025
    CrowdAgentAllocating labeling across humans, LLMs and SLMs
  2. 2025
    M-GRPOTraining a different LLM for each agent
  3. 2026
    Dynamic role assignmentSelecting roles via Meta-Debate
  4. 2026
    CRAFTCoordination tests with partial information
  5. 2026
    MANTAChanging communication structure during execution
  6. 2026
    DeOrchSeparating planning from worker selection
Publication order runs from left to right. Starting from operational and training problems, the research broadened toward flexibly changing roles and structure, and then toward testing collaboration itself.

When does collaboration pay off: experiments on the gains and losses

Two studies released in October 2026 examined the benefits of multi-agent systems through controlled experiments. A study of user conversation settings paper tested a previously proposed 'capability saturation rule'. This rule states that collaboration helps when a single agent is weak but hurts once it becomes strong, with the boundary near 45% single-agent accuracy; it came from autonomous benchmarks without users. The researchers compared a single agent and a centralized multi-agent system built from the same model in the airline, retail and telecom domains of τ²-bench, where the user and agent change the state together. They ran about 7,950 simulated conversations with six models from three families and preregistered the experimental plan.

The results were unfavorable to multi-agent systems. Under a fixed simulated user, the multi-agent system did worse in 12 of 13 valid cells and tied in the remaining one, for a weighted average of -28 points. Even in the two cells where the rule predicted a gain, it lost by 13 and 22 points, and even with the budget cap removed, it only barely caught up after using 5.5 times the tokens of a single agent. The researchers themselves noted a limitation: the multi-agent planner could not see the tool schemas. So the result applies to 'multi-agent systems in this configuration', but it is also an example of how large a loss an information gap between planner and executor can cause.

The financial review study paper narrowly tested the common practitioner belief that 'splitting the work improves document review'. It reviewed 300 credit memos (synthetic data) against six requirements, comparing one agent checking all six requirements at once with three copies of the same model each checking two requirements. The team caught 0.08–0.10 more defects, but false positives (flagging a problem where there was none) also rose for all four models. The change in balanced accuracy, which combines both, was 0.02 or less, and token usage was 2.2–2.4 times higher. In fact, running a single agent three times and flagging an issue if any run caught it gave higher balanced accuracy than the team for some models. Showing each agent the requirements it was not responsible for reduced the extra false positives, which suggests a side effect of division of labor in which each agent 'only looks at its own share'.

Taken together, the two studies yield one practical criterion. To fairly judge the benefit of a multi-agent system, compare it not with a single run of a single agent but with spending the same token budget on a single agent (multiple samples, longer reasoning and so on).

Costs and outcomes of collaboration

12 of 13 cellsMulti-agent did worse
-28 pointsWeighted average performance gap
5.5×Tokens needed just to break even
2.2–2.4×Tokens used by the financial review team
Key figures from the τ²-bench experiments (first three cards) and the financial review experiment (last card).

Where things are heading: systems that learn communication structure

The recent trend is to have roles and communication structures learned or adjusted according to the situation, rather than fixed in advance by people. If MANTA paper, covered earlier, fixes the structure during execution, DeOrch paper separates planning from worker selection so the system does not need retraining when workers change. Both treat team composition 'not as a fixed design choice but as something to adjust during operation'.

ACTS paper narrows this trend to the problem of communication scheduling. Its starting point is that existing methods either fix the communication graph so it cannot change with the state of problem solving, or ignore complementary relationships between roles. ACTS uses two kinds of attention within a centralized training with decentralized execution (CTDE) framework, in which the whole team's information is used during training and each agent decides on its own during execution. One module looks at roles and the current execution state to choose whom to talk to this time (the number of partners can also vary each time). The other feeds the resulting directed communication graph directly into team value decomposition to divide credit more accurately. It was evaluated on 9 benchmarks covering code generation, multi-step reasoning, general knowledge and competition math problems.

What these studies share is that they aim not for 'more conversation' but for 'only the conversation that is needed'. Given the token costs and information gaps shown by the experiments in the previous section, this is a natural direction. However, whether such learned orchestration also beats a single agent in user-facing conversational tasks has not yet been confirmed within the source material.

Limitations and open issues

First, cost. Messages between agents are all tokens, and the more roles there are, the more times the same context is read. Figures such as 2.2–2.4 times in the financial review experiment paper and 5.5 times in the τ²-bench experiment paper show that when performance differences are small, cost becomes the deciding factor.

Second, information gaps and accountability. Division of labor prevents each agent from seeing the whole picture. The planner not seeing the tool schemas in the τ²-bench experiment, and false positives dropping when other requirements were shown in the financial experiment, are two faces of the same problem. Credit assignment, which determines which agent is at fault when something fails, remains a core challenge for training, which is also why DeOrch paper, M-GRPO paper and ACTS paper all address it.

Third, coordination ability itself is still weak. CRAFT paper concludes that even strong reasoning models do poorly at coordination under partial information, and that this problem has not been fundamentally solved. Multi-agent systems producing 'different answers', as in the legal deliberation study paper, is useful for widening the set of candidates for human review, but it does not in itself mean higher accuracy.

Fourth, from a general design perspective, as agents and connections increase, so do the paths messages travel through and the permissions involved. Safeguards such as the principle of least privilege, which gives each agent only the tools and information it needs, and format checks on messages between agents become more important than with a single agent.

Checks before going multi-agent

Comparison baseline

  • Did you compare against a single agent with the same token budget?
  • Did you include multiple samples from a single agent as a baseline?
  • Do you measure missed errors and false positives separately?

Information and roles

  • Does the planner see the workers' tool information?
  • Does each agent know the overall goal?
  • Did you choose the model for each role on solid grounds?

Operations

  • Can you trace which agent is responsible when something fails?
  • Did you give each agent only the permissions it needs?
Design checklist items drawn from the limitations and experimental results in the text.

Further reading

If you want a feel for what collaboration gains and costs first, start with the financial review comparison study paper. The setup is simple, and because it measures missed defects and false positives separately, it shows clearly 'what division of labor changes.' Then read the user-dialogue environment study paper to see what the capability saturation rule and fair comparison design (preregistration, token ledger) are.

To study design methods, read dynamic role assignment paper for role assignment, MANTA paper and ACTS paper for communication structure, and DeOrch paper for separating the planner from workers, in that order; this walks through the four decisions (decomposition, assignment, communication, credit assignment) one at a time. If you are also interested in training, M-GRPO paper, which trains a hierarchical system with reinforcement learning, is helpful because it also deals with real infrastructure problems (server separation, variable-length Rollouts).

To look more deeply at why collaboration is hard, see the failure taxonomy in CRAFT paper; for the operational view of deploying people and models together, see CrowdAgent paper; and for a domain application, see the legal deliberation study paper.

Related terms

Multi-agent Subagent AI agent Agentic workflow Reinforcement learning Harness A2A Principle of least privilege

References

Foundational papers

Recent research

Written by AI from the listed references and reviewed. Please check the original sources for details.