Gemini Robotics ER 2: what multi-robot orchestration really means for a mixed fleet
Google demonstrated a humanoid and a wheeled robot dividing a task between them. For an operator already running two vendors in one building, the interesting part is not the demo but the architecture behind it.
On 30 July 2026 Google published three robotics models, and the coverage compressed all three into one headline about robots working together. For an operator who already runs cleaning robots from one manufacturer and transport robots from another in the same building, the useful reading is different. What became publicly available is a planner. What stayed behind closed doors is everything that actually moves a machine. That distinction decides what you can pilot this quarter and what you cannot.
Key Takeaways
- 1Three models shipped, not one. Only Gemini Robotics ER 2, the high level planner, is publicly available. The two models that convert perception into motor control remain limited to early access partners.
- 2ER 2 does not drive motors. It plans, tracks progress and hands execution to a separate vision-language-action model declared to it as a tool.
- 3Semantic handoff between two robots is not a fleet interface. VDA 5050 remains the only credible fleet standard, and it does not normalise localisation quality, load handling or error codes.
- 4Lifts, fire doors and access control stay per building integration work. No foundation model removes that line item.
Three models, three very different access tiers
The release covers three separate models, and conflating them is the most common error in the current coverage. Reading them apart is what makes the announcement actionable.
| Model | Role | Drives motors | Availability |
|---|---|---|---|
| Gemini Robotics ER 2 | Embodied reasoning, planning, progress tracking | No | Public: Gemini API and Google AI Studio, plus private preview on the Gemini Enterprise Agent Platform |
| Gemini Robotics 2 | Vision-language-action, converts perception into motor control | Yes | Early access partners only |
| Gemini Robotics On-Device 2 | Lean on-robot vision-language-action model | Yes | Early access partners only |
Gemini Robotics ER 2 is built on Gemini 3.5 Flash, takes interleaved text, image, video and audio, works with a context window of up to 128k and emits up to 64k tokens of text. It is reachable through two endpoints, gemini-robotics-er-2-preview and gemini-robotics-er-2-streaming-preview, the second optimised for the Live API and bidirectional streaming. The older gemini-robotics-er-1.6-preview is being retired at the end of August.
The architectural point is stated plainly by Google: ER 2 plans multi-step tasks and then hands motor execution to a lower level vision-language-action model, with control interfaces declared to it as callable tools. It is a planner that talks to executors. It is not a robot controller.
What the multi-robot demonstration actually showed
Google demonstrated machines of different types communicating through a shared semantic understanding, handing parts of a task to one another and completing workflows a single machine could not finish alone. The demonstration used an Apptronik Apollo 2 and a Franka F3 Duo. A separate example drove a Boston Dynamics Spot through the Spot APIs, with configuration examples and demo code published on GitHub.
That is a real result and worth taking seriously. It is also narrower than the headline suggests. Two robots agreeing on what a task means is a semantic achievement. It is not the same problem as two robots sharing a corridor at 07:40 on a Tuesday while a cleaning machine occupies the lift and a delivery is blocking the goods entrance. The first problem is about understanding. The second is about traffic, priority and interlocks, and it is solved in the fleet layer, not in the model.
Why the planner sits above the safety layer, not inside it
For a building operator the separation between reasoning and motor control is a requirement rather than a limitation. A cloud model that emits variable text cannot hold authority over machine motion. Safety-rated controllers, certified protective fields and emergency stop circuits keep that authority, whatever the planner proposes.
| Layer | Function | Governed by |
|---|---|---|
| Planner (ER 2) | Interpreting goals, decomposing tasks, verifying progress | Cloud API, bounded by declared tools |
| Fleet middleware | Dispatching, traffic control, right of way, interlocks | VDA 5050, OPC UA, building interfaces |
| Execution and safety | Trajectory, speed, protective fields, emergency stop | EN ISO 3691-4, person detection at PL d per ISO 13849 |
Read the table as a chain of custody. When the planner concludes that a machine should enter a corridor, that conclusion is a request. The fleet layer checks whether the corridor is clear and whether the machine is permitted there, and only then does the vehicle move. Nothing in the July release changes which layer is allowed to say no.
The part no model solves: your building
The gap between an impressive orchestration demo and a working deployment is almost never the intelligence. It is the building. A plan to move laundry from the basement to the third floor is worthless if the machine cannot call the lift, and lift integration is negotiated per property, per manufacturer and per controller generation.
- Lifts. No robot manufacturer publishes a lift protocol or a named lift manufacturer partnership. This is an integration item on every project, priced per building.
- Fire doors and smoke barriers. Actuation is documented by nobody and touches fire safety approval. It needs the operator, the integrator and usually the authority having jurisdiction in the same room.
- Access control and speed gates. Usually a separate system with its own vendor and its own permission model.
- Cross-vendor traffic. VDA 5050 gives you a common vocabulary for orders and states. It does not normalise localisation quality, load handling or error codes, so two compliant fleets can still disagree about what a corridor blockage is.
This is the honest reason mixed fleets are hard, and it is unchanged by a better planner. It is also precisely the work an integrator exists to do.
What to ask a vendor now
The release does shift the questions worth asking during procurement. A machine that cannot accept an external task instruction will not participate in orchestration at all, whichever planner you eventually choose.
- Does the robot expose an interface for accepting externally dispatched jobs, or only its own scheduler?
- Is VDA 5050 supported, at which version, and which optional parts are actually implemented?
- What telemetry is available in real time, on the local network rather than through the vendor cloud?
- Which failure states does the machine report as structured error codes, and which only as a generic fault?
- Who holds the CE conformity for the machine once a third party dispatches its work?
The last question is the one most often skipped and the one that matters most. If you connect an external planner to a machine and thereby change its behaviour or its operating boundaries, you may have made a substantial modification, and whoever makes a substantial modification takes on the obligations of the manufacturer. We treat that question in detail in our piece on what the ER 2 model card says about safety-critical use.
werob specifies, procures and integrates multi-vendor robot fleets for building operators. If you are weighing which machines can take part in an orchestrated fleet at all, the robot catalogue and the console demo are the practical starting points.
FAQ
- What is the difference between Gemini Robotics ER 2 and Gemini Robotics 2?
- ER 2 is the high level planner. It reasons about a scene, breaks a goal into steps and tracks whether those steps succeeded, but it does not drive motors. Gemini Robotics 2 is the vision-language-action model that converts perception into motor control. ER 2 is publicly available through the Gemini API and Google AI Studio; Gemini Robotics 2 is limited to early access partners.
- Can I connect Gemini Robotics ER 2 to the robots I already own?
- Technically you can call the API and have it produce a plan. Whether your machines can act on that plan depends on whether they accept externally dispatched jobs, which many closed fleet systems do not. Before any of that, note that the ER 2 model card prohibits safety-critical deployment, so an operational pilot around people needs a deterministic safety layer that the model has no authority over.
- Does VDA 5050 solve mixed fleet coordination?
- Partially. VDA 5050 is the only credible fleet interface standard and it gives different manufacturers a shared vocabulary for orders and machine states. It does not normalise localisation quality, load handling or error codes, so integration work remains even between two compliant systems.
- What does multi-robot collaboration change for lift and door integration?
- Nothing. Lift calls, fire door actuation and access control remain per building integration work negotiated with the respective system vendors. No robot manufacturer publishes a lift protocol or a named lift partnership, which is why this stays a project line item rather than a product feature.