Scalable Multi-Robot Collaboration with LLMs: Centralized or Decentralized Systems?

All four frameworks plan one step at a time. In each step, the LLM agents must agree on the next action for each robot [1, §II]. An LLM agent is one LLM call stream with its own prompt and role. The frameworks differ only in who proposes the actions and who can object.

• DMASDecentralized. Each robot has an LLM agent. The agents talk in turns. The dialogue stops when one agent writes "EXECUTE" with an action for each robot. Earlier work (RoCo, CoELA) uses this design [1, §III-B; 2; 3].
• HMAS-1Hybrid, based on DMAS. A central LLM first writes an initial plan. Then the local agents talk in turns as in DMAS.
• CMASCentralized. One LLM writes the actions for all robots. No local agents exist.
• HMAS-2Hybrid, based on CMAS. The central LLM writes the plan. Each local agent checks only its own action. If one local agent disagrees, the central LLM plans again. This repeats until all local agents agree.

In both hybrids, only the robots that have an action in the current step join the dialogue. This decreases the number of tokens [1, §III-B].

Each step follows the same loop in all frameworks [1, §II, §III]:

1. Pre-defined functions change the goal and the environment state into text.
2. The LLM agents talk, as their framework sets, until they agree on one action for each robot.
3. A rule-based verifier checks the syntax of the plan. If it finds an error, the error text goes back to the LLM, which tries again.
4. The robots execute the actions. The new state goes into the prompt of the next step.

Each prompt has seven parts: task description, step history, current state, robot state and capability, an agent-specific part (with a persona), communication instructions, and optional syntax feedback [1, §III-A]. The robot capability part also lists actions that cause a collision. Thus, the planner, not the environment code, must find a safe plan.

The models are gpt-4-0613 (8,192-token limit) and gpt-3.5-turbo-0613 (4,097-token limit). A sliding window keeps the newest steps of history, so that the prompt stays below 3,500 tokens [1, §III-D].

All four tasks are 2D grid worlds with text input and text output. Each task needs coordination between robots [1, §IV-A].

A run fails in five cases: the context goes above the token limit, the agents do not agree within a round limit, the syntax check repeats past its limit, the step count passes its limit, or the plan causes a collision [1, §IV-A].

Each robot can lift a different weight. In one step, several robots can lift the same box together. The box goes up only if the total capability of its robots is greater than the box weight [1, §IV-A]. The LLM agents see only box size. Size and weight are roughly proportional, with some random variation. After each step, the agents learn only whether each lift worked.

Thus, BoxLift tests two things: team allocation (which robots go to which box) and learning from feedback (a failed lift says that a box is heavier than the team tried). Try it below.

Table I gives four numbers per framework and task [1, Table I]. Success rate is the mean over all 40 runs. Steps, API calls and tokens are means over successful runs only. Those three metrics are normalized: each value is divided by the smallest value in its row, so the best framework has 1.00.

HMAS-2 makes the best plans. It has the highest success rate on all four tasks and the fewest steps on all four [1, §IV-C]. On BoxLift, it succeeds in all 40 runs.

CMAS is the cheapest. It uses one LLM and usually one API call per step. On BoxNet2, Warehouse and BoxLift, HMAS-2 uses 5.22, 9.21 and 21.52 times the tokens of CMAS.

DMAS is the worst on all counts. It has the lowest success rate (0% on BoxNet2 and Warehouse) and the highest cost (50.34 times CMAS tokens on BoxLift). The authors saw agents repeat what earlier agents said, or propose the same action again and again. This makes the dialogue long and dilutes the useful information in the context [1, §IV-C; 4].

An initial plan helps the dialogue. HMAS-1 is better than DMAS everywhere. But HMAS-2 is better than HMAS-1 on all metrics. In HMAS-1, local agents can stay fixed on their own proposal, and the dialogue does not end (paper Figure 5).

Figure 6 of the paper plots success rate against robot count for CMAS and HMAS-2. The authors report this trend: with few robots, CMAS is about as good as HMAS-2, but CMAS gets much worse as robots are added [1, §IV-C, Fig. 6]. On Warehouse, CMAS is worse than HMAS-2 at every robot count.

The cause, in the authors' view, is that one central LLM writes more wrong plans when the task is complex. In HMAS-2, local agents find these errors before execution. Figure 7 shows a case: a local agent sees that its assigned move causes a collision, reports it, and the central LLM changes the plan.

The paper gives two reasons why per-robot dialogue does not scale [1, §I]:

1. The number of possible joint actions and dependencies grows exponentially with the number of agents.
2. Each agent's prompt holds the replies of all other agents. Thus, the prompt length, the run time and the API cost all grow with the team size.

Figure 6 is a line chart without printed values, and the paper gives no per-count numbers in the text. This page does not redraw it.

The step history is the record of earlier steps in the prompt. The paper tests three kinds with HMAS-2 [1, §III-C, Table I]:

• None: no earlier steps.
• State-action: earlier states and actions, without dialogue. All main runs use this kind.
• Full: states, actions and all dialogue.

State-action history is the best on all four tasks. Full history is a bit worse. The authors explain this with context dilution: long dialogue pushes the useful facts into the middle of the prompt, where LLMs use them less well [1, §IV-C; 4].

No history fails on BoxLift in all runs (0%). The paper does not explain this specific result. A probable cause (our reading, not a claim of the paper): in BoxLift, the only weight information comes from lift results in earlier steps. Without history, the planner cannot learn which boxes need more robots, so it can repeat the same failed lift until it reaches the step limit.

A weaker model breaks all frameworks. With GPT-3.5 (the table calls it "GPT-3"), CMAS and HMAS-2 reach only 12.5% and 27.5% on BoxNet1, 0% and 5% on BoxNet2, 0% and 10% on Warehouse, and 12.5% and 20% on BoxLift [1, Table I]. HMAS-2 is still better than CMAS, but the model quality decides most of the result.

3D simulation. The authors also run a PyBullet task similar to BoxNet: robot arms with fixed workspaces put colored boxes into bowls of the same color. A vision model (ViLD) changes the camera image into object text. Grip errors can occur, and the step-by-step loop plans again after them [1, §IV-D].

The same lab reused the four 2D tasks in later papers. These results are from this project's earlier benchmark research [5; 6; 7]:

• PROMST (prompt optimization) uses BoxNet1, BoxNet2, Warehouse and BoxLift with a central planner. GPT-4 reaches 1.0 on BoxLift with an optimized prompt.
• CodeSteer / SymBench uses BoxLift and BoxNet as single-agent text tasks. On BoxLift, o1 scores 95. On BoxNet, o1 scores only 45.
• Wan et al. put CMAS, DMAS and HMAS on the four tasks into a suite of 14 embodied multi-agent systems to measure cost.

Thus, BoxLift is close to saturated for strong models. BoxNet2 and Warehouse at high robot counts are better tests for architecture differences. The project notes found no paper that repeats the four-framework comparison with 2025-2026 models [7].

• Small samples. 10 trials per robot count. The paper gives no variance or confidence intervals.
• Success is averaged over robot counts. Table I mixes 4 and 32 robots in one number. Only Figure 6 shows the trend, without values.
• Cost is counted only on successful runs. A framework that fails often can look cheap, because its expensive failed runs do not count. DMAS on BoxNet2 and Warehouse has no cost value at all.
• The normalization does not match the table in all rows. Eq. 1 says that the best value in each row is 1.00. But no BoxNet1 row has 1.00 (for example, CMAS tokens = 4.09), and no Steps row has 1.00 in any task. The paper does not say which reference value it used there.
• Full observability. Each LLM agent knows the whole environment and all robot capabilities [1, §II]. Only BoxLift hides one fact (weight). Thus, the local agents in the hybrids do not add private information. They add a second check.
• One model family, 2023 models. Only GPT-4-0613 and GPT-3.5-turbo-0613, with an 8k context limit. Several failure types (token overflow, long dialogue) can change with newer long-context models.
• Hand-made text interfaces. State-to-text and text-to-action functions are written by hand for each task.
• Authors' future work: deeper hierarchies (one agent per robot sub-group) and multimodal models [1, §VI].