It sits alongside. The robot keeps its ROS 2 middleware (Cyclone DDS or rmw_zenoh) for on-board comms: low-latency LAN-local fabric, exactly what those layers are tuned for. We add a sidecar that bridges DDS / Zenoh topics → CDR-on-MoQT → the cloud relay. Cloud subscribers (fleet ops dashboard, simulators, operators) speak our SDK, not DDS.

Two ways. (1) rmw_zenoh is a first-class ROS 2 middleware now. It replaces DDS for many fleets that want a unicast, peer-aware fabric without DDS's multicast assumptions. We bridge into our cloud relay the same way we bridge DDS topics, so the swap is transparent to your cloud subscribers. (2) Native [Eclipse Zenoh](https://zenoh.io/) workloads (non-ROS robots, edge sensors, MQTT-replacement deployments) plug directly into our MoQT fabric: Zenoh sessions on the south side, MoQT tracks on the north, without going through ROS at all.

DDS does discovery via multicast: WAN routers drop multicast. Zenoh does WAN better than DDS does, but neither gives you per-track auth, multi-tenant namespacing, or a 1000-fleet-deep relay tree. Our relay does. The on-robot fabric stays as-is (whichever you picked); only the cloud-bound edge of it talks our wire.

Every MoQT track is captured to object storage with frame-accurate timestamps. The Cruise viewer (over WebTransport) lets ops scrub time the way Foxglove does on bag files, but live. Bag files as a format are imported on the way in if you have an archive.

On one 8-vCPU / 8 GB GCE box the relay held 36,732 concurrent MoQT-over-WebTransport connections at about 0.4 % CPU (0.03-0.04 of 8 cores), with no media flowing. The bottleneck wasn't the relay. It was the load fleet. For real workloads (more tracks/robot, real publish rates), 1k–5k robots / box is the practical envelope. Mesh fanout scales horizontally; the relay is shard-per-core (shared-nothing SMP) so adding cores adds capacity ~linearly.

Yes. The π0.5 (DROID) vision-language-action model runs inside our serving stack, on our C++ runtime. One action chunk takes about 27 ms of model time on an RTX PRO 6000 with 8-bit weights, and the output passes our agreement gate against the reference model. Each policy request can carry a deadline and a supersede key, so a newer camera frame replaces a stale request instead of queueing behind it.

Most MQTT topology survives. The substrate ships a broker-mode façade that speaks MQTT 3.1.1 / 5 on the south side and MoQT on the north. Existing MQTT clients keep working unchanged; new code talks to the cleaner MoQT API directly. Same pattern for Zenoh-fronted deployments: the fabric is whichever protocol your robots already speak; the cloud sees MoQT.