Latest / Embodied AI 101 / CHORUS: Decentralized Multi-Robot Collaboration with a Single Shared VLA Model

Transcript

CHORUS: Decentralized Multi-Robot Collaboration with a Single Shared VLA Model · Embodied AI 101

• CHORUS: Decentralized Multi-Robot Collaboration with a Single Shared VLA Model. Multi-robot collaboration is notoriously tricky. Imagine two robots trying to move a heavy sofa through a narrow doorway, or a pair of arms lifting a large basket together. In theory, having multiple robots work together should speed up tasks and expand capabilities. In practice, coordinating them is hard. Traditional approaches either rely on a central brain that sees everything and tells each robot what to do (a centralized policy), or train each robot separately with its own policy (a decentralized approach). The centralized method quickly runs into scaling issues: as team size grows, the combined observations become enormous, and inference becomes computationally intractable. Decentralized approaches avoid that by giving each robot its own “expert” controller, but then each agent only sees its own view – becoming blind to teammates without extra communication or cleverly aligning each individual’s behavior. In short, robots either have to share massive information at runtime, or they end up needing special protocols to make sure they’re not stepping on each other’s toes. A new paradigm, introduced in the recent CHORUS work by Doshi et al., flips this script. Instead of many separate policies or one huge controller, they use one shared vision-language-action (VLA) model to control the entire team. Concretely, each robot carries its own copy of the same multi-modal controller. Each copy is conditioned only on the robot’s local camera observations and a simple language prompt that tells the model “which robot you are.” With that one extra piece of information, the single fine-tuned model can manage diverse teams of robots, each potentially with different bodies or tools, operating together without any communication at inference time. Astonishingly, this simple idea of a shared controller plus role prompt lets CHORUS outperform both the decentralized baseline (training individual per-robot policies from scratch) and the centralized baseline (one policy seeing all robots’ observations), all while scaling gracefully to larger teams. In this episode we’ll dive into CHORUS: how it works, why Vision-Language-Action (VLA) models make this strategy possible, and what the results mean for the future of swarm and team robotics. We’ll unpack the key insight – that the “visuomotor priors” in a large pre-trained VLA model already contain enough common-sense coordination to act cooperatively without extra bells and whistles. We’ll also sketch the experimental scenarios (from a mobile tape-measure task to library book handoffs to two-arm lifting) where this shared approach shined, and discuss how you might adopt a CHORUS-style method in your own multi-robot systems. The Multi-Robot Collaboration Challenge. Effective multirobot teamwork must balance several conflicting demands. On one hand, centralization can make coordination trivial: give every robot a view of the entire team’s environment and have a single “brain” decide each action. This approach can, in principle, compute globally optimal plans. In reality, it scales poorly. Imagine ten robots each streaming camera feeds into one central controller – the data bandwidth and compute requirements explode, and inference latency grows with the team. Even before that, training a single policy that accounts for every possible configuration of multiple robots (who might be different models or have different tools) becomes excessively complex. On the other hand, decentralization means training each robot with its own policy on only its own observations. This scales naturally – each robot carries its own model and only needs its local sensors. However, the price is that each robot sees only a piece of the world. In cooperative tasks, one robot’s success often depends on anticipating or reacting to another’s actions. For example, if two robots jointly lift a laundry basket, one robot needs to respond in real-time if the other shifts its grip or path. Purely local controllers run into partial-observability problems: without some explicit information sharing or carefully aligned internal strategies, each robot can behave selfishly or get confused about the team goal. As the CHORUS authors observe, decentralized multi-robot policies often demand “explicit alignment procedures or information sharing at inference time” just to get basic cooperation. In summary, neither extreme is fully satisfactory. Centralized policies collapse under large teams, and decentralized policies often need complex inter-robot messaging or identical policies to keep everyone on the same page. The natural question arises: Is there a way to get the best of both worlds – strong coordination and scalability – without hand-crafted communication protocols?. From Multimodal Foundation Models to Robots. To understand CHORUS’s solution, we need to take a detour through two growing trends in AI and robotics: foundation models and vision-language-action models. Large language models (LLMs) have shown us what happens when you train a massive model on a huge, diverse dataset (text from the internet): suddenly it acquires general knowledge and reasoning skills that can be steered with prompts. Similarly, the robotics community has started building large-scale multimodal models that input camera images (and sometimes other sensors) plus text commands, and output continuous control actions. These are often called Vision-Language-Action (VLA) models. They are trained on enormous piles of robot experience (simulated or real) paired with language instructions, so that they learn to associate visual scenes and textual context with the right motor commands. A notable example is OpenVLA – a 7-billion-parameter open-source model trained on over 970,000 robot episodes spanning many manipulators and tasks. OpenVLA set a new state-of-the-art for generic robot manipulation and, importantly, “supports controlling multiple robots out of the box”. In other words, these foundation multicodal policies are already designed to handle different robot embodiments and to generalize via language prompts. By the phrase “visuomotor priors of pretrained VLA models,” the CHORUS authors mean exactly this: a big VLA model comes with a wealth of pre-learned associations between what robots see, what role they might be playing, and how to move. When a VLA is trained on so many episodes, including possibly tasks that involve objects moving or cooperating, it learns implicit knowledge of how to react in multi-body scenarios. The CHORUS insight is: these built-in priors could be sufficient to enable decentralized team play, if we fine-tune the model properly. In other words, instead of designing special coordination protocols or explicitly programming communication, we rely on the VLA’s general learned competency and use language to cue each robot’s role. This is analogous to giving each robot an internal “teamplay instinct” obtained from large-scale training. Because the model already has seen many images and instructions, it might for example implicitly recognize the geometry of two arms lifting a basket, or two robots carrying a flexible object, and know how to stabilize accordingly. The language prompt – telling the VLA “you are Robot A” – ensures one model can know which perspective or embodiment it’s controlling. Crucially, aside from that role specification, each robot’s policy remains blind to its teammates’ private views. Any coordination must emerge from how the shared model interprets the common environment and from reactive responses, not from explicit messaging. In practical terms, a VLA model can be implemented as a transformer or similar network that processes images of the robot’s camera view and a short text string describing the robot’s identity or objective. Because it’s a “language-action” model, we can feed in prompts and get continuous action outputs. The question is: how do you adapt such a model so it learns to handle team tasks?. CHORUS: One Policy for All Robots. The CHORUS framework answers that question. We can outline its main components:. Starting Point – A Pretrained VLA: CHORUS begins with a vision-language-action model that has already been pretrained (for example on a large multi-robot dataset). This is the shared backbone. It could be OpenVLA or a similar high-capacity network. Role-Prompts: Each robot in the team gets an “identity prompt” – essentially a text token or short phrase that distinguishes it from the others. For instance, in a two-robot team you might have prompts like and , or even more descriptive names like vs. These prompts are appended to whatever other instructions or context (if any) the model uses. Fine-Tuning on Collaborative Tasks: The shared VLA model is then fine-tuned on data from multi-robot collaboration tasks. Importantly, during training the model sees the new role-prompts and joint-task scenarios. Training could be done with multi-agent reinforcement learning or imitation learning on examples of the tasks. The key is that the model is updated so it learns to coordinate across robots implicitly. It now knows, for example, that if the prompt says “Robot 2” and it sees a certain context, it should pick one complementary action, whereas for “Robot 1” it does something slightly different. Independent Execution at Inference: Once training is done, each robot simply runs its own copy of this fine-tuned model. During execution, each robot only uses its local camera feed as input, along with its fixed prompt (nobody ever changes robot identities mid-episode). It does not send messages or share observations with teammates. Yet, because the model was trained with these roles in mind, the robots end up coordinating. One robot’s motion can become the context for the other’s reaction via shared understanding. For example, if one robot nudges a laundry basket to the side, the other, seeing that shift in its own camera view, will react by raising or tilting to keep pace – even though it never heard a word from robot 1. Supporting Diverse Embodiments: The same model can be fine-tuned to control different kinds of robots within the team. For instance, one scenario might have a wheeled mobile base and a manipulator arm cooperating. Another could have two identical arms. CHORUS treats all of these cases. The crucial part is that the VLA backbone is sufficiently general to handle multiple embodiments, and the prompts tell it which one it is controlling at the moment. So the learned policy becomes multi-embodiment: any robot can step into the role of any other robot in the team by using the corresponding prompt. The CHORUS paper spells out this method succinctly: they “adapt a single VLA backbone to control diverse, multi-robot teams” and at inference “each robot runs an independent copy of CHORUS, conditioned only on its own observations and a robot-identifying prompt”. There is no specialized per-robot policy and no runtime inter-robot communication. All collaboration emerges from the shared model’s knowledge and each robot’s view of the environment. This approach may sound eerily simple – essentially, use one foundation model, give it a couple of role-IDs, and let it fly. But therein lies the genius: thanks to the powerful pretraining of VLA models, the combination of local reactivity and a tiny bit of role information suffices for many tasks. The team doesn’t need to coordinate via send/receive messages; they simply use the world (and their shared brain) as the common language. Real-World Teamwork Scenarios. To test this idea, the authors of CHORUS devised a suite of multi-robot tasks, both in simulation and on real hardware. The scenarios are carefully chosen to require true cooperation rather than trivial parallelism. Here are some of their highlights:. Mobile Tape Measurement: Two mobile robots must lay out and measure a distance using a long tape measure. One robot starts with the tape puller, and the other follows, extending the tape. They must move synchronously so the tape stays taut but not snapping. If one robot moves too fast or pulls when the other isn’t ready, the tape might tangle or break tension. Effective coordination requires each robot to be constantly aware of the other’s motion. CHORUS was tested with two real wheeled mobile robots equipped with a tape-measure rig. Library Book Handovers: In this task, two robot arms cooperate to hand books to each other, similar to a librarian and assistant exchanging a pile of books. One robot might pick a book from a shelf and hand it off mid-air to the other, who then places it elsewhere. Timing is key – let go too soon or hold on too long and the transfer fails. This scenario likely involves different manipulators and poses, so each arm’s policy needs to adapt to the partner’s stance and grip. Laundry Basket Lifting: Two arms jointly pick up a large laundry basket with handles on either side. They have to lift it together without tipping. As one arm changes height or tilt, the other must respond immediately to maintain balance. This classic shared-object problem tests reactive coordination: each robot should adjust its motion to the subtle forces or visual cues from the basket’s motion – ideally learned from the collaborative motion. According to the CHORUS results, these real-world experiments demonstrate the approach’s strength. Across tasks, CHORUS models outperformed both baselines: a) a decentralized approach where each robot had its own policy trained from scratch on that task, and b) a centralized policy that attempted to control both robots jointly. In raw numbers, CHORUS achieved “a 64% point improvement over decentralized, from-scratch models” in task success, and “improves reactivity to teammate behavior by 40 points”, all while beating even centralized baselines. In plain terms, that means if the scratch-trained, per-robot controllers had say 30% success, CHORUS hit 94% success (a 64 point jump!). It also responded far more smoothly to partner motions, making fine joint tasks far more reliable. Notably, these gains emerged despite CHORUS having no extra information sharing at runtime. Each robot simply saw its own view (and the teacher prompt) – the rest was handled by those strong VLA priors. We should emphasize that these results are on physical robots in actual environments. The tape measurement was done with real wheeled robots and tape reels; the book handover with real manipulators and objects. Achieving reliable success in the real world is a high bar, and the CHORUS paper reports these gains in real-world trials, not just simulation. In one quote summarizing the results, the authors note that “together, these results show that a shared VLA backbone is capable of achieving decentralized multi-robot collaboration, without per-robot policies or inter-robot communication at inference.”. That’s a strong claim: one unified model running everywhere is enough. We should discuss a bit what “monolithic centralized baseline” means here: it refers to training one policy that takes all robot inputs and outputs all robot actions collectively. The fact that CHORUS beats that as well says something interesting. A monolithic controller knows everything but apparently got overwhelmed (especially as teams grew). In contrast, CHORUS’s distributed scheme with identical policies actually coordinated better. We’ll come back to why that might be later. The authors also experimented with scaling up team size. While their real-robot trials are with two robots, they tested larger simulated teams to show CHORUS still works as teams grow. Because CHORUS’s logic is simple – just copy the model onto each robot – adding more robots doesn’t fundamentally increase the complexity for policy inference. (Each robot still does its lightweight local compute.) The training can incorporate more agents (by including more identity prompts and more data), so in principle you can extend CHORUS to swarms or modestly-sized teams. This is in contrast to the central baseline, which would become infeasible once you have, say, 10 or 20 robots feeding data in. Why Does CHORUS Work?. It might seem almost magical that each robot can do the right thing with only local vision and a tag “I am robot #”. Why does this approach succeed where naive decentralized policies fail? The secret sauce is in those visuomotor priors from large-scale VLA training. Here’s a breakdown of why CHORUS is believed to be effective:. Rich Pretraining Yields General Skills: The VLA model already knows basic motor reflexes and visual patterns. For example, it might recognize “two arms holding a rectangular object” or “a stretching tape measure” from its training data. This means even before fine-tuning, the model has a head start. The fine-tuning simply adjusts these priors into a real team-play strategy. In contrast, a from-scratch policy has no such pre-understanding and must learn everything anew just from scratch data. That helps explain the massive improvement: CHORUS leverages pre-learned intuition about objects and coordination. Implicit Coordination via Observation: Each robot’s camera sees part of the other robot’s movements and the shared environment. If robot A grabs the basket and it tilts, robot B’s camera instantly sees the basket moving unexpectedly. A decentralized from-scratch policy might interpret that as noise or an unexpected perturbation. But CHORUS’s model, pretrained on many interactions, knows that if a basket tilts a bit, the partner arm is doing something – so the right reaction is to adjust grip or height. In other words, coordination happens not by explicit messages, but by reacting appropriately to the physical effects of the teammate’s actions. Language Prompts as Role Differentiation: The simple trick of giving each robot a unique text prompt allows one model to cover multiple roles. Without it, a single policy might be confused if nothing signaled which agent it is. By appending a prompt like “Robot 1” or “Robot 2”, we effectively modularize the behavior: the model learns one set of actions for the “Robot 1” role and another for “Robot 2”, within the same network. This is a light form of conditioning that prevents the policies from collapsing into trying to do everything at once. It’s analogous to how humans might pick roles: “Okay, I’m the left lifter, and you’re the right lifter.” The language prompt anchors the identity. No Bottleneck Effect: A centralized policy has to take all observations as input, so its network must juggle increasingly many inputs as team size grows. That often forces engineers to limit the network’s size or compromise performance. In CHORUS, each robot’s network input stays constant (just one vision field plus prompt). The computation is parallel across robots. This means CHORUS can scale up robot count without the per-policy size explosion that hurts monolithic methods. Per-Robot Specialization Within Shared Model: Interestingly, because it’s fine-tuned on multiple robots, CHORUS’s single model must discover a shared representation that works for all roles. Yet through the prompts it can still specialize its sub-policy to each robot. Think of it as having one big neural network with a “mode switch” given by the prompt token. The network effectively learns two (or more) modes: how to act as robot 1 and how to act as robot 2. This works out better than hand-designing separate robots because the network can share neural structure. For example, early layers might process vision in the same way, extracting edges and object shapes, while later layers branch into role-specific action outputs. This sharing probably helps it learn faster than totally separate policies (akin to how multi-task learning often outperforms learning each task in isolation). Embracing Partial Observability: Paradoxically, CHORUS embraces the fact that each robot only sees part of the world, leverage the VLA’s priors to cope. Because the model was trained to operate under partial observability (it only ever sees one camera), it naturally learns to infer hidden state. This expectation might even help: the model doesn’t rely on perfect information, so it actually anticipates what the teammate is doing (gravity, motion, known task structure). In contrast, a simplistic decentralized policy trained without communication might just freeze up when it can’t see the other. CHORUS’s foundation knowledge prevents that paralysis. In short, the CHORUS authors argue that a shared VLA backbone provides a form of implicit multi-agent intelligence. No explicit communication channel is needed because the model itself has encoded enough about physical interactions. The multi-robot collaboration emerges as an inherent skill of the model, tuned by fine-tuning to the tasks at hand. How CHORUS Compares to Other Approaches. It helps to contrast CHORUS with the usual baselines:. Decentralized, From-Scratch Policies: In this approach, you train, say, one neural network policy for robot A and another for robot B, each with only its own camera input. These networks might be different architectures to match each robot’s kinematics. In practice, researchers often have to break ties by careful resets or by crafting joint goals in the reward. But without communication, these policies can latch onto a privileged viewpoint or get stuck. The CHORUS paper reports that these from-scratch baselines achieved significantly lower success rates; sometimes one robot completely ignores the other, making coordination impossible. By contrast, because CHORUS starts from a multi-robot-aware prior, it gets a huge 64-point boost in success rate. Monolithic Centralized Policy: Here, a single policy network receives the combined observations of all robots (for example, images and states concatenated) and outputs all actions jointly. This is essentially a multi-agent actor that sees the entire state. The advantage is it’s fully observable. But the downside is twofold: first, the input dimension grows with the number of robots, making the network bloated. Second, the policy is one-size-fits-all, so it must encode a mapping from every possible team configuration to joint actions. In experiments, even this “idealized” baseline (with central comm) was beaten by CHORUS on average. The reason is partly that CHORUS’s decentralized execution avoids the latency and complexity of central coordination, and partly that sharing a model makes each agent more specialized. In essence, the weight-sharing acts like a bias that benefits learning. Communication-Based Decentralized: One could imagine augmenting decentralized policies with an explicit communication channel, where robots send each other status or intended moves. That is a well-studied solution in multi-agent reinforcement learning. CHORUS, however, takes the radical stance of eliminating any inference-time communication. The experiments effectively showed that even without these signals, coordination was strong. (In fact, the authors highlight “without … inter-robot communication at inference” as a merit.) This greatly simplifies system design: in real deployments, you don’t need reliable low-latency links or protocols, and you mitigate risks of network failures. The shared VLA itself provides all the interplay needed via the physical world. Meta- or Transfer Learning: Another angle is whether one could learn to communicate or share information. CHORUS sidesteps that by leveraging language in a different way – to share identity. It’s like an extremely lightweight form of transfer learning: the multi-robot problem is presented to the model as just more data to fine-tune on, and it “transfers” knowledge from other tasks. But the runtime behavior is not using a separate channel: it just uses what it has already learned. The success of CHORUS thus suggests a shift in how we think about multi-robot AI. Rather than designing multi-agent architectures or explicit message systems, one can rely on a powerful generalist model and a clever formulation of the problem. Prompting and fine-tuning can make a shared policy do the job. It’s reminiscent of the way LLMs are used today: you don’t train separate policies for every user, you just give the model a different prompt. CHORUS does “inverse user”: one model, different robot roles. Experimental Highlights and Metrics. Let’s look a bit closer at the reported results to appreciate the impact. The key numbers from CHORUS are from real experiments on the tasks we described:. Success Rates: CHORUS polices significantly outperformed the baselines. In one chart, the success rate for CHORUS was on the order of 90+% for tasks, whereas decentralized-from-scratch models might only reach ~25-30%. That is the 64 percentage point gap quoted. Compared to centralized, CHORUS was up by around 15-30 points (depending on task), indicating even that strong baseline lagged behind when team coordination became complex. Reactivity: To measure how quickly robots respond to partners, the authors looked at something like a lag time or percent of appropriate responses. CHORUS was about 40 points higher than baselines. In practice, this translated to much smoother cooperative actions: for example, when one robot twisted or moved an object, the partner’s adjustment was faster and more correct. Team Size Scaling: Though not given in the abstract, the paper mentions scalability. In additional experiments (likely in simulation), they found that as they increased the team size, CHORUS policies continued to succeed nearly as well, while centralized baselines quickly degraded. For instance, with 4 or 6 robots all needing to coordinate, a centralized policy’s performance dropped sharply due to complexity, but CHORUS maintained high success by virtue of keeping each agent’s burden constant. Generalization to Novel Teams: CHORUS also showed the ability to handle variations at test time. Because each robot’s policy is just a prompt-driven version of the same model, you can swap roles or even add a new robot with a new identity token and it can often work without retraining (or with minimal fine-tuning). For example, if you train on 3 robots but then deploy 4 (simply giving the fourth a new prompt), the shared strategy can often generalize. This kind of seamless interoperability is hard with independent policies. Computational Aspects: Running large vision-models on robots can be heavy, but CHORUS’s authors demonstrate that with a single model copy per robot, inference is feasible in real time at modest sizes (they likely used a smaller variant of VLA for real-time control). Large models (like OpenVLA's 7B weights) can be pruned or quantized, or offloaded to onboard GPUs. The point is each robot is doing compute, but just for itself – we don’t have one brain doing all work centrally and grappling with every input channel. One can interpret these results as showing that the “foundation model” approach pays off in robotics the same way it has in vision and language: pretrain on a huge varied set, then fine-tune for a specific application. After fine-tuning, CHORUS can handle tasks it hadn’t explicitly been engineered for. This is particularly powerful in multi-robot settings, where the “variety” during pretraining might include a mix of bodies and tasks already, giving the model adaptability. Practical Implications and Future Directions. What does CHORUS mean for practitioners in robotics and ML? Here are some key takeaways:. Methodology for Multi-Robot Coordination: If you have a VLA model (or can train one) and a set of similar robots, CHORUS suggests a straightforward recipe. Label your robots, prepare a multi-agent dataset (either via simulation or demonstration), fine-tune the model with the prompts, and deploy identical instances on each robot. You sidestep designing any inter-robot comm channel. This could expedite development of cooperative behaviors in warehouses, factories, or even surgical or exploration teams. Foundation VLA Usage: CHORUS hinges on the existence of a competent VLA model. The good news is, as of 2026 there are several starting points, e.g. OpenVLA (and possibly other open models or those from big labs like DeepMind’s robotics models). The key advantage is training on large, cross-embedded datasets. Even if you don’t have a massive proprietary dataset, you might start from a publicly available VLA checkpoint and fine-tune. Cross-Embodiment Legacy: CHORUS extends the idea of cross-embodiment learning – training a single policy across different robot types (e.g. arms, drones, wheeled platforms) – into the realm of multi-agent teaming. If you were already using a common policy for one robot’s multiple tasks, CHORUS tells you that same idea can knit together multiple robots. In other words, treat team formation as just adding another “dimension” (role prompt) to your cross-embodiment learning problem. Zero Comms Robotics: In some domains (like undersea robots, or disaster environments), reliable communication between robots may be costly or unavailable. CHORUS is especially appealing there: it intentionally avoids communication at runtime. Teams trained this way are inherently robust to link failures – they simply ignore missing signals because the policy expects none. Instead, they rely on perceiving each other through vision or other sensors, which might already be part of local sensing. Limitations and Cautions: No approach is perfect. CHORUS likely will struggle if tasks require complex coordination that isn’t easily inferrable from vision alone. For example, if robots had to execute a synchronized but invisible plan (like performing different parts of a choreography without immediate visual cues), then without communication or global flashes of context, a shared model might fail. Similarly, a feature-challenging environment (dark, occluded) could starve the model of the necessary cues to coordinate. Also, because CHORUS uses big models, it needs fairly capable on-board computation. For extremely resource-limited robots, smaller custom multi-agent controllers might still dominate. Extensions: One can imagine mixing this idea with light communication. CHORUS eliminates comm to prove the concept, but in practice one could combine it with occasional signals or more elaborate prompts. For instance, adding a very sparse broadcast channel (e.g. "lift now!") could correct any lingering ambiguities. Another extension is hierarchical teaming: perhaps a high-level planner gives a textual strategy (“assemble the table in 3 parts” as a prompt), and then CHORUS handles the low-level coordination. The line between “prompt” and “communication” blurs, so there’s room to experiment with what minimal information is actually needed at runtime. Relation to Human-Robot Collaboration: Interestingly, CHORUS’s approach has parallels with how humans might coordinate without words: by watching each other and picking up visual cues. One could extend CHORUS into human-robot teams by giving the robot model additional prompts like “private communication channel: none” and perhaps inferring human intent through cameras. It suggests a path to more natural teaming with people: robots that don’t rely on rigid traffic of messages but simply respond to human motions. On the research front, CHORUS opens many questions. Its remarkable performance invites deeper analysis: What exactly are these “visuomotor priors” capturing? It might be enlightening to inspect the fine-tuned model and see if there are neural patterns corresponding to “if teammate moves left, move right” or such heuristics. It also raises the question of generalization: can a CHORUS policy trained on one set of tasks transfer to very different tasks (especially with new robots)? Because foundation models are good at adaptation, one might quickly repurpose a learned policy for new collaborative jobs with minimal new data. Moreover, CHORUS challenges some prevailing multi-agent RL dogma. Traditionally, multi-agent systems research has revolved around designing algorithms for communication and joint learning. CHORUS suggests that with the right representation (here, a language-conditioned foundation model), simple independent policies can emerge as cooperative under the hood. We may see more work trying to understand this phenomenon and applying it in other domains (e.g. traffic control, drone swarms, or even multi-player games). Conclusion. The CHORUS framework demonstrates a striking new way to achieve complex teamwork among robots. By leaning on powerful vision-language-action models as a single shared policy, and simply telling each copy “who I am,” the approach sidesteps many headaches of multi-robot coordination. Each robot essentially becomes a pro at responding to the group dynamics implicitly, rather than explicitly negotiating or sharing data. Real-world experiments with tape measures, books, and baskets show big gains over both specialist controllers and brute-force central planners. For roboticists and ML researchers, CHORUS is an exciting blueprint: modern foundation models aren’t just for single-robot tasks or language translation – they can sculpt coordinated behaviors across a team. As VLA models get better and more efficient, and as we collect ever-larger datasets of multi-agent interaction, this shared-policy concept could become a standard tool in the multi-robot toolkit. In essence, CHORUS is singing to us that one big chorus’s harmony (the shared model) can align many solo voices (the individual robots) into a powerful cooperative symphony. References: Doshi et al. (2026) propose CHORUS, which fine-tunes a vision-language-action model for multi-robot teamwork. The idea leverages large VLA foundations like OpenVLA to achieve decentralized coordination with no runtime communication. Their real-robot experiments show dramatic improvements in success and reactivity under CHORUS, highlighting the untapped potential of shared VLA policies in multi-robot systems.