In Google's July 30, 2026 demonstration, a person asked a Boston Dynamics Spot robot to fetch a popcorn snack. Gemini Robotics ER 2 interpreted the request, planned the sequence, called Spot's navigation and manipulator capabilities, watched the task through video and continued until the delivery was complete. The impressive part was not a new walking controller; it was the connection between language, visual progress and existing robot tools.
The demonstration should be described carefully. It is Google research, not an announced Boston Dynamics product, a new Spot model or evidence of a public commercial deployment. To understand where ER 2 sits in the wider portfolio, see our Google physical AI strategy map and ER 2 explainer.
The fetch demo was a high-level orchestration test
Spot already has a mobile base, sensors, autonomy features and an optional arm. Its software interfaces can expose operations such as moving to a location, positioning the arm and manipulating an object. ER 2 did not replace those capabilities. It decided how to combine available tools in response to an open-ended natural-language request.
That separation is why the example matters for physical AI. The user did not specify every waypoint and grasp step. The model connected the outcome, observed scene and approved functions, while Spot software executed navigation and manipulator commands.
| Stage | ER 2 responsibility | Spot or application responsibility |
|---|---|---|
| Understand | Interpret the request and identify the target outcome | Provide video, environment state and available capabilities |
| Plan | Break the goal into navigation, search, manipulation and return steps | Expose valid functions and operational constraints |
| Execute | Select a function and provide arguments | Validate the call and run navigation or arm control |
| Observe | Review new video and tool results | Return current state, errors and sensor feedback |
| Recover or continue | Retry, revise or choose the next approved step | Enforce timeouts, limits and safe fallback behavior |
Natural language becomes a sequence of constrained function calls
A request such as bring me popcorn leaves many details unstated. The robot must locate the relevant area, identify the correct object, reach it, secure it and return. ER 2 can reason about that sequence and select functions made available by the application. Each function should have a narrow purpose, typed arguments and a clear success or failure response.
For example, the application might expose navigate_to_location, inspect_for_object, pick_object and return_to_user. The model can choose among them, but the application should reject unknown locations, prohibited objects and out-of-range arm targets. Function calling is an interface for controlled delegation, not permission for the model to send arbitrary commands to Spot.
The see-think-act framework helps explain this loop: video supplies the see stage, ER 2 handles high-level thinking, and Spot's own APIs and controllers perform the act stage. New observations then start the cycle again.
Continuous video lets ER 2 monitor progress
Traditional task scripts often assume that a command succeeded unless an explicit error is returned. A visual supervisor can ask a richer question: does the scene now match the expected result? ER 2's continuous-video emphasis lets it follow a task over time, identify relevant moments and classify progress before deciding what to do next.
Google reports 57.4% on progress classification and 91.3% moment-finding accuracy, with a mean absolute distance of 0.96 seconds. These are Google-reported evaluations, not the Spot demo's success rate or a guarantee for another site. Real applications should combine model interpretation with verified telemetry.
.jpg){kind=link}
ER 2, Spot autonomy and the robot controller do different jobs
The phrase AI-powered Spot can blur several systems together. ER 2 is a cloud-accessible VLM that returns text and function calls. Spot's autonomy and SDK translate high-level requests into robot-supported behaviors. Low-level controllers handle balance, leg motion, arm trajectories and feedback at frequencies inappropriate for a networked language model.
Independent safety layers should restrict travel and define behavior after a communication failure. ER 2 cannot certify hardware or replace emergency procedures. Its safety paper covers high-level semantic and orchestration risks, not a mobile manipulator's complete functional-safety architecture.
| Layer | Example responsibility | Not responsible for |
|---|---|---|
| Gemini Robotics ER 2 | Interpret intent, plan, call tools and monitor task state | Real-time leg balance or direct motor torque |
| Spot API and autonomy | Navigation, arm behaviors and robot status | Open-ended language reasoning unless an external model supplies it |
| Low-level robot control | Stable locomotion and actuator feedback | Choosing the user's semantic goal |
| Independent safety controls | Geofencing, stops, limits and operating procedures | Generating a helpful task plan |
The demo demonstrates integration potential, not deployment readiness
Google's example demonstrates that a multimodal model can orchestrate a legged robot's documented capabilities and use visual feedback to pursue a multi-step request. It is useful evidence for natural-language interfaces, high-level recovery and the possibility of sharing a reasoning layer across different robot types.
It does not publish a completion rate across many buildings, users or packages. Google did not announce a retail ER 2 add-on for Spot, and Boston Dynamics did not announce a new Spot product. Reproducing the demo would require hardware, SDK access, tool definitions, mapping, privacy controls and site-specific safety tests.
| Claim | Supported by the public demo? | Reason |
|---|---|---|
| ER 2 can orchestrate Spot navigation and manipulator APIs in a research setup | Yes | Google explicitly describes this demonstration |
| ER 2 directly controls Spot's motors | No | The high-level model calls robot APIs and returns text |
| Google and Boston Dynamics launched a commercial integration | No | No such product announcement appears in the cited sources |
| The system is safe for unsupervised public operation | No | The demo is not functional-safety certification or a field reliability study |
Spot is not Atlas, and the distinction affects the use case
Spot is a quadruped platform designed for mobility, inspection and payload integration, with an available arm for manipulation. Atlas is Boston Dynamics' humanoid program. The ER 2 fetch example used Spot, not Atlas. Substituting the names creates a false claim about both the hardware and the partnership evidence.
The body shape matters. Spot can navigate terrain with a stable four-legged base and carry sensors, while a humanoid may target tasks built around human workspaces and two-handed reach. A reasoning model can abstract part of the task, but the available tools, reach envelope and failure modes remain embodiment-specific.
For the current humanoid context, see our Boston Dynamics Atlas 2026 guide. It should be read separately from the Spot demonstration rather than used as evidence that ER 2 has been shown on Atlas.
A careful prototype would start with a bounded mission
A team exploring a similar architecture should begin with one mapped, access-controlled route and one non-fragile object. Expose only the required Spot functions, validate every parameter, set a maximum number of retries and stop safely when video, network or tool state becomes uncertain. A human operator should be able to take control immediately.
Use staged data during early ER 2 testing. Google states that unpaid API and AI Studio content may be used to improve products and may be reviewed by humans, so sensitive facility footage does not belong in a free-tier prototype. Paid prompts and responses are not used to improve products, although limited safety logging remains. Pricing and data details are in our ER 2 API guide.
Finally, measure more than whether the object arrived. Track planning latency, tool-call validity, interventions, navigation failures, grasp failures, unnecessary retries and near misses. That evidence reveals whether language orchestration adds value over a conventional mission script for the actual site.
Frequently asked questions
Did Google put Gemini Robotics ER 2 inside Boston Dynamics Spot?
Google describes ER 2 orchestrating Spot APIs for navigation and manipulator movement. ER 2 is the high-level reasoning layer; Spot's own software and controllers execute the physical behaviors.
Can Spot owners buy the Gemini ER 2 integration?
No commercial Spot-ER 2 package was announced in the cited sources. ER 2 is a public-preview API, while reproducing the research demo would require robot hardware, SDK integration, tool design and site-specific validation.
Was the Google demo performed with Atlas?
No. The snack-fetching demonstration used Boston Dynamics Spot, a quadruped platform with manipulation capability. Atlas is Boston Dynamics' separate humanoid program.
Official sources checked
- Google: Gemini Robotics ER 2 announcement and Spot demonstration
- Google AI for Developers: Gemini Robotics API overview
- Google DeepMind: Gemini Robotics ER 2 model card
- Google Gemini: official robotics samples repository
- Boston Dynamics: Spot product page
- Boston Dynamics: Spot SDK documentation
Last checked: August 6, 2026