NEW DELHI, August 5, 2026, 2:20 PM IST — Google DeepMind has made Gemini Robotics ER 2 publicly available through the Gemini API and Google AI Studio, giving developers a new cloud-based reasoning layer for robots that can interpret continuous video, plan multi-step work and coordinate more than one machine.
The release matters because it moves several physical-AI capabilities from a laboratory demonstration into developer-accessible preview endpoints. For platform and robotics teams, that changes the immediate engineering question from whether a general-purpose model can reason about a physical workspace to how safely and reliably it can be integrated with low-level control software, observability systems and human approvals.
What Google has confirmed
Google describes Gemini Robotics ER 2 as an embodied-reasoning model that serves as a high-level “brain” rather than directly replacing a robot’s motor controller. It processes text, images, video and audio, then invokes tools such as navigation interfaces, robot APIs or separate vision-language-action models that execute movement.
The standard Gemini Robotics ER 2 Preview endpoint is designed for spatial reasoning, video analysis, multi-step tool use and multi-robot orchestration. A separate streaming preview connects through the Gemini Live API for bidirectional audio and video workloads where latency matters. Both are preview services, not general-availability products.
Google said the model is available in the Gemini API and Google AI Studio, with private-preview access through the Gemini Enterprise Agent Platform. Its developer documentation also says the earlier Gemini Robotics ER 1.6 preview will shut down at the end of August, giving existing users a short migration window.
Video progress tracking is the operational shift
A central addition is continuous progress classification. Instead of reasoning only from a still image, the model can watch a video stream, estimate how far a task has progressed, detect whether a step succeeded and decide whether to continue, retry or change course.
Google reported 57.4% accuracy on its progress-classification evaluation. It also reported 91.3% accuracy and a mean absolute distance of 0.96 seconds on a “moment-finding” test intended to locate a critical event in video, such as the point at which pouring should stop. Those results come from Google’s own evaluations; independent replication and performance in unfamiliar production environments remain open questions.
The distinction is important. A model can score well at identifying task states without meeting the reliability threshold for unsupervised operation around people or valuable equipment. Camera placement, lighting, occlusion, unusual objects and network delays can all alter real-world behavior.
Why DevOps and platform teams should pay attention
Physical AI creates a larger failure domain than a conventional software agent. A bad tool call in a business application may corrupt a record. A bad tool call routed to a robot can damage inventory, interrupt a production line or put a person at risk.
That makes familiar platform practices newly important. Teams evaluating the preview should treat every robot function as a privileged API: use narrow permissions, validate arguments, add deterministic safety interlocks and retain a human-controlled stop path outside the model. Prompts and model responses also need versioned audit logs linked to video, sensor readings, tool calls and the exact model endpoint used.
Observability should measure more than model latency and token consumption. Useful service-level indicators include task completion rate, false-success detection, retry frequency, intervention rate, time spent in uncertain states and the delay between a perceived hazard and a physical stop. These signals belong beside the existing telemetry used by LLMOps teams, but their retention and access controls may be stricter because robot video can capture employees, customers or private facilities.
Google’s documentation explicitly warns that the robotics models can make mistakes and says operators remain responsible for maintaining a safe environment. It also sets notice and consent requirements when identifiable people may be captured in video or audio sent to the service. Engineering teams will therefore need privacy review, data-minimisation controls and region-specific retention decisions before piloting the model in an occupied workspace.
Multi-robot orchestration adds a distributed-systems problem
Gemini Robotics ER 2 can coordinate different machines through a shared high-level plan. Google demonstrated the model using interfaces from Boston Dynamics’ Spot and described collaboration between Apptronik’s Apollo 2 humanoid and a Franka dual-arm system.
For infrastructure teams, the architecture resembles a distributed workflow engine attached to physical actuators. Each robot can have different capabilities, local controllers, network conditions and safety envelopes. Production designs will need idempotent commands where possible, bounded retries, explicit ownership of shared objects and recovery procedures for partial completion.
The model’s streaming path may reduce pauses between reasoning and action, but it also makes availability engineering more consequential. Teams should decide what a robot does when the model endpoint, network link or camera stream degrades: stop safely, finish a deterministic local action or transfer control to a human. That policy should be tested with the same discipline applied to failover and chaos testing in cloud services.
What remains uncertain
Google has not presented ER 2 as a general-purpose autonomous robot system, and the public preview status signals that interfaces, limits and performance may change. The company’s demonstrations and benchmark results show progress, but they do not establish safe autonomy across factories, warehouses, hospitals or public spaces.
Cost and capacity are also workload-dependent. Continuous multimodal streaming can produce a very different spending profile from occasional text inference. Before moving beyond a sandbox, teams should measure end-to-end cost per successful physical task, including video transport, inference, retries, human supervision and idle capacity—not only API pricing.
Developers moving from ER 1.6 should first reproduce existing evaluations against the ER 2 preview, then compare failure modes rather than relying only on aggregate accuracy. The same evaluation discipline used for retrieval-augmented applications applies here, but physical tests should run in simulation and controlled cells before live deployment.
The bottom line
Gemini Robotics ER 2 is a notable developer release because it packages spatial reasoning, live multimodal input and tool orchestration behind accessible model endpoints. Its near-term value is likely to be as a supervised planning layer for bounded workflows, not as a substitute for deterministic control, independent safety systems or experienced robotics operators.
For DevOps and platform teams, the practical work begins at the boundaries: secure tool contracts, traceable decisions, privacy-aware telemetry, failure injection and a safe fallback when either the model or the network is wrong. Teams building broader agent systems can also review GravityDevOps’ guides to prompt engineering for developers and CI/CD tool selection as they design repeatable test and release gates.
Sources
Google’s Gemini Robotics ER 2 announcement; the Gemini API robotics documentation; and Axios coverage of the release.
