Section 35.3: Dual-system architectures: GR00T N1.5, Helix, Gemini Robotics (with Frontier Watch caveats)

"A robot that thinks slowly and acts quickly still needs a treaty between the two governments."

A Systems Architect

Why Split The System At All?

High-level language reasoning and low-level motor control live on different clocks. A policy that reasons over long-horizon context, open-vocabulary instructions, and spatial semantics may only need to update every few hundred milliseconds. A wrist controller closing on a moving object may need updates an order of magnitude faster. Dual-system VLAs acknowledge that asymmetry instead of forcing one module to do both jobs on the same schedule.

GR00T N1 and N1.5 explicitly present this design as a System 2 vision-language reasoning module feeding a System 1 diffusion action model. Helix and Gemini Robotics make related moves with different packaging: a richer semantic layer provides task or scene context, then a downstream motor policy converts that context into reactive motion. The details differ, but the shared systems idea is a boundary between semantic deliberation and motor execution.

A Timed Interface

A clean formalization uses a slow context variable $c_k$ and a fast control loop:

$$c_k = g_\psi(o_{1:t_k}, q, h_{k-1}), \qquad a_t = \pi_\theta(x_t, c_k), \qquad t_k \leq t < t_{k+1}.$$

The slow module $g_\psi$ updates at times $t_k$ using accumulated observations, instructions, and history. The fast module $\pi_\theta$ consumes the current state $x_t$ and the latest context packet $c_k$ on every control step until a new slow update arrives. This equation forces the designer to specify the refresh rate and the contents of $c_k$.

Code Fragment 1 makes that timing split concrete with a toy scheduler.

# Refresh the semantic plan every three control steps.
# The fast controller reuses the latest plan until a new one arrives.
observations = ["drawer closed", "drawer opening", "drawer open", "grasping mug", "lifting mug"]
latest_plan = None

for step, obs in enumerate(observations):
    if step % 3 == 0:
        latest_plan = f"plan@{step}: open then grasp"
    print(f"step={step} obs={obs} using={latest_plan}")

step=0 obs=drawer closed using=plan@0: open then grasp
step=1 obs=drawer opening using=plan@0: open then grasp
step=2 obs=drawer open using=plan@0: open then grasp
step=3 obs=grasping mug using=plan@3: open then grasp
step=4 obs=lifting mug using=plan@3: open then grasp

The expected output is a trace where the fast motor loop reuses a still-valid plan until the world state crosses a semantic boundary and the slow planner refreshes at `plan@3`. If the planner refreshed on every step, the architecture would be semantically expressive but latency-heavy; if it never refreshed, the controller would drift on stale intent.

How Current Systems Differ