In August 2026, Google introduced the Gemini Robotics 2 family, unveiling three models targeting different task levels: the cloud-based Gemini Robotics ER 2 for high-level embodied reasoning, the VLA model Gemini Robotics 2 for action control, and Gemini Robotics On-Device 2 designed to run directly on hardware (see the Model Card evaluation details). If you have experimented with the publicly available ER 2 model in Google AI Studio or the Gemini API, you will notice an interesting pattern: while it understands images, video, audio, and text simultaneously, its output consists strictly of text and Tool Calls function calling. It does not directly output torques, joint angles, or end-effector trajectories for robot arms. If you ask a robot to clear a desk, ER 2 acts more like a high-level dispatcher. It processes live camera streams, assesses task progress, and generates step-by-step text plans to trigger function interfaces written in your code. Low-level physical movements, such as moving a gripper precisely to specific coordinates, are delegated entirely to the underlying VLA model or onboard robot controller.
At first glance, this design raises an obvious question: in the foundation model era, should the architectural evolution of embodied AI not intuitively be a single massive model operating end-to-end, from raw visual pixels straight to motor control? Why does a high-level brain like ER 2 offload action control, seemingly decoupling the system?
The answer lies in two unavoidable hard constraints of the physical world.
The first constraint is the physical tension between execution frequency and compute. A high-level reasoning brain needs to understand complex scenes, interpret human intent, and plan several minutes ahead, requiring substantial model scale. The public streaming ER 2 caps visual input at 1 frame per second, and Google has not disclosed its inference frequency or end-to-end latency. Conversely, at the lower level, Figure’s Helix action policy runs at 200 Hz, while Helix 02’s balance layer processes contact and coordination at 1 kHz (Google has not disclosed corresponding frequencies for Gemini Robotics 2). Given current hardware compute, massive models cannot run at 200 Hz, while lightweight models capable of 200 Hz cannot hold web-scale common-sense knowledge.
The second constraint is software decoupling and hardware isolation. High-level semantic reasoning is agnostic to specific arm lengths or dexterous hand joint counts, making it ideal for a universal cloud API shared globally. In contrast, low-level action control must tightly couple with specific hardware action spaces and physical safety constraints. This separation of high and low frequencies mirrors human physiology, where the cerebral cortex handles slow, deliberate decision-making, while the cerebellum and spinal reflex arcs govern rapid muscle control.
Understanding why high- and low-level division of labor persists clarifies the two genuine mergers brought by foundation models. As early as 1969, when the Stanford Research Institute (SRI) built the mobile intelligent robot Shakey, the engineering team established the classic Sense-Plan-Act architecture, dividing the robot into three components: a vision module to build a world model, a STRIPS symbolic planner to select the next step, and a controller for execution. As discussed in our earlier VLA models vs. physical control analysis, modern foundation models effectively consolidate these components across two distinct boundaries.
The first merger occurs at the high level. Previously, scene understanding and step derivation were handled by separate programs. In VLMs like ER 2, visual perception and logical reasoning are integrated into a single neural network. Upon receiving visual input, the model handles scene understanding and action planning within the same VLM, eliminating the need for separate vision detection pipelines and symbolic reasoning engines.
The second merger occurs at the low level. Previously, bridging planning commands and motor rotation required extensive trajectory optimization code and explicit motion planning algorithms. In VLA models like Gemini Robotics 2 and On-Device 2, neural network weights directly learn trajectory generation, mapping visual frames and high-level instructions straight to motor control signals. This compresses a portion of previously explicit motion planning directly into neural weights, though collision avoidance, balancing, force control, and functional safety remain the responsibility of low-level controllers. From Google’s SayCan project in 2022 using PaLM as a high-level planner, to the RT-2 paper discretizing actions into tokens, to Figure Helix in 2024 combining a 7–9 Hz S2 VLM with a 200 Hz S1 action policy, Helix 02 in 2026 adding a 1 kHz S0 balance layer, and Physical Intelligence’s evolution of the π series models, representative systems are converging on a similar blueprint: combining perception and reasoning at the high level for thinking, and combining perception and motion planning at the low level for control.
Viewed through this architectural lens, Gemini Robotics 2 delivers progress across three main engineering dimensions. First is the standardized API delivery of a high-level embodied reasoning model. Gemini Robotics ER 2 is built on a Gemini 3.5 Flash base with a 128k context window, accepting text, image, video, and audio inputs. While the standard version processes image and video inputs, a streaming preview mode accepts JPEG visual streams up to 1 frame per second via the Live API, outputting Tool Calls that interface directly with backend code like that in Google’s official code samples.
Second is cross-hardware execution using a single model weight checkpoint. Google demonstrated in evaluations that the cloud VLA model runs on a single weight checkpoint across different embodiments: an Apptronik Apollo 2 equipped with SharpaWave multi-fingered dexterous hands, an Apollo 2 with Inspire hands, and a Franka Duo with Robotiq grippers.
Third is a significant reduction in demonstration data required for on-device VLA models. Evaluated primarily on standing bimanual manipulation, the On-Device 2 model demonstrated adaptation curves requiring only hours of demonstration data: on the SO101 embodiment, using just 0.25 to 1.7 hours of demonstration data per task boosted success rate from 6.7% to 53.3%; on the Dexmate embodiment, 0.3 to 2 hours per task increased success rate from 24.4% to 75.6%.
However, task evaluations highlight clear variance in physical manipulation performance. Robots fitted with 22-DoF SharpaWave dexterous hands achieved a 92% success rate in unscrewing lightbulbs, along with 76.3% and 68.4% on shelf and tabletop pick-and-place tasks. Conversely, tasks involving deformable objects or fine force control—such as tying trash bags (44%), sealing ziplock bags (40%), screwing in lightbulbs (36%), and sweeping into dustpans (32%)—show substantial room for improvement.
Once high-level reasoning is delivered as a standardized API, our perspective on universal robot brains shifts. Demonstrating compatibility across multiple robot arms is no longer enough; in real engineering deployments, the core concern is the total cost of integrating a new robot. We can refer to this overhead as the embodiment integration tax. Fitting a universal brain onto a new robotic arm or humanoid embodiment incurs costs across data, compute, control coordination, and safety adaptation.
This integration cost stems primarily from four factors: 1. Demonstration data collection cost: human labor and physical setup required to record successful trajectory data; 2. Model fine-tuning and compute consumption: training time and compute needed to regain generalization across edge or cloud weights; 3. Control frequency and latency alignment: whether high-level API inference speeds can match low-level controller execution rates; 4. Safety assurance and boundary testing: high-level semantic refusal mechanisms (such as hazardous instruction interception evaluated in the ASIMOV-Agentic safety report) cannot replace low-level hardware functional safety certification, requiring independent physical safety controllers and hardware redundancy on-site.
The adaptation experiments shown by Gemini Robotics On-Device 2—requiring roughly 0.25 to 2 hours of demonstration data per task (referring to data collection volume, not training runtime)—offer a compelling engineering reference for lowering integration overhead. Yet moving from lab environments to factory floors and homes requires embodied AI systems to establish a verifiable balance between production-grade reliability and total integration costs.
From human-engineered perception, symbolic planning, and control modules in the Shakey era to the multi-tier foundation model collaboration in Gemini Robotics 2, embodied AI evolution has moved past single-algorithm breakthroughs into a progressive engineering overhaul driven jointly by compute, data, and physical constraints. As high-level reasoning generalizes through standardized cloud APIs, low-level muscle control becomes nimbler through internalized neural weights.
For most developers and AI Builders, the pragmatic focus is not chasing new hardware demos, but building robust workflows and safety boundaries between existing high-level APIs and physical environments. Once the barrier to machine reasoning drops, the real advantage belongs to those who can manage physical integration costs and handle edge cases cleanly in real-world deployment.