Argon makes the planning layer worth another look.
Google's robotics post shows Gemini 4 Argon creating a MuJoCo twin before a Spot robot presses a bin pedal. Another demonstration uses a visual coordinate grid and named action primitives to turn a mug upright and place a napkin inside. A third steers a video world model through repeated visual checks.[1]
The demonstrations matter because they connect language, images, simulation, and action. They also show the seam that teams need to keep visible. The model works through prompts, observations, and callable robot functions. Motion still reaches hardware through another system.
Physical reasoning can choose a move. It cannot replace the machine that limits and stops that move.
The API already exposes the boundary.
Google's Gemini Robotics ER documentation says the model can return points, boxes, trajectories, and tool calls. Its example sends structured coordinates to a robotics API or a vision-language-action model. The same page warns that generative models can make mistakes and places responsibility for a safe operating area on the developer.[2]
The documented limits are practical. Higher resolution and more thinking can increase latency. Outputs can be wrong. Prompt quality affects results. Google recommends splitting complex tasks into steps and querying more than once when precise spatial output matters.[2]
Those are reasons to treat model output as a request. The request needs a timestamp, a bounded workspace, speed and force limits, and an expiry. A stale request should die before it reaches a motor.
Fast control belongs below the model.
The ROS 2 control manager describes a real-time loop that reads hardware state, updates controllers, and writes commands. Its documented default update rate is 100 Hz. It can clamp commands to configured joint limits, deactivate controllers after hardware errors, and start fallback controllers when configured.[3]
That documentation also says to test fallback behavior in simulation before using it on a real robot. It treats jitter, thread priority, memory locking, and kernel choice as control concerns. These details do not fit inside a model prompt because a prompt has no timing guarantee.
Argon's own robotics examples reinforce the split. Google's human-video reconstruction prompt asks MuJoCo to step a dexterous simulation at 500 Hz. The model specifies and revises the scene. MuJoCo performs the timed physics steps.[1]
A stop button is not a chat instruction.
OSHA's industrial robot guide defines a limiting device as independent of the control program and application programs. It defines an enabling device that permits motion only while held in the required position. It also calls for task-based risk assessment, validated safeguards, training, and review after changes.[4]
That guidance covers industrial systems, not every research arm or mobile robot. The engineering lesson still transfers. Do not make the same model that proposes motion responsible for deciding whether its proposal is safe. Keep the stop path, travel limits, and loss-of-contact behavior outside the planner.
Build one command envelope per action family.
Do not expose a raw move_joint function and hope the prompt stays careful. Define a narrow action with a named workspace, maximum velocity, maximum duration, freshness limit, collision conditions, and observable completion state. Reject anything outside that contract.
Separate four modes. Observe can read state. Simulate can build and run a digital twin. Assist can propose bounded actions for operator approval. Actuate can request motion only when the local controller, watchdog, command limits, fallback behavior, and stop path have passed their own tests.
The useful receipt records the model request, the accepted command, the controller state, the stop reason, and the test revision. It does not say "safe" because four boxes were selected in a browser. It says which contract is drafted and which hardware evidence is still missing.