[r-johnv]

Thank you!

The underlying stack definitely can connect to multiple robots simultaneously. Our current implementation is sequential, where the language model can connect from one robot to the next (and then back).

But it is definitely possible for us to write it to be simultaneous as well.

[awanacode]

Really cool, the multi-robot angle got me thinking. For simultaneous setups, would that mean spinning separate MCP clients (one per robot), or could a single client handle multiple connections in parallel, almost like an operator shell aware of multiple robot contexts?

On the flip side, how would you handle conflicting commands from multiple clients? Is it last-writer-wins, or do you envision some arbitration layer? It feels like orchestration + conflict resolution will be key if MCP is to scale beyond single-robot demos into fleet-level use.

[r-johnv]

Conflicting commands from multiple clients is one of the open questions at the moment.

We're also building out a technical steering committee to help guide our direction on topics like this. Safety is a big category where having direction from across the community will be important.

[r-johnv]

It should be possible to do it from one client. The MCP server would handle the parallel connections.

We're using websockets as the interface between the server and the robot itself, which to the best of my exploration does have the ability for simultaneous connections.