Section 3.6: Dual-system (System 1 / System 2) designs and where they come from

"The fast channel catches you before you fall. The slow channel decides whether the destination was worth going to at all."

A Reflex Arc and Its Supervisor, Briefly in Agreement

Your hand is already moving toward the falling glass before you have consciously decided to catch it; only afterward does the slow part of your mind ask whether the glass was even worth saving, the exact tension Figure 3.6A dramatizes. Embodied robots face the same split second by second, and the contract that governs which decisions go to the fast hand and which to the slow mind is what this section makes precise. Figure 3.6 shows the closed-loop shape we are after: evidence flows into a decision, the decision produces a consequence, and that consequence becomes the next observation, with a router deciding whether each case takes the fast or the slow path.

The key question is practical: what must the agent know, what can it observe, what action is available, and what evidence shows that the action worked under the stated conditions?

Theory

The practical design rule for a dual-system stack is to make the seam between the two paths inspectable before tuning anything. On a Unitree Go2 quadruped, for example, log the exact bytes crossing the boundary. The MPC path emits a 12-dimensional ground-reaction-force vector at 1 kHz. The high-level navigation path emits a body-velocity command at 10 Hz. A useful artifact records both with timestamps, the SI units (newtons, m/s), the actuator torque limits (about 23.7 Nm per joint), and a termination label (fell, reached goal, timed out). When that handoff is visible, a stale-frame torque spike is a two-line diff in a ROS 2 bag; when it hides inside a monolithic policy, the same bug becomes a multi-day mystery.

Dual-system designs borrow a useful distinction from cognitive science, but in embodied AI the distinction must become an engineering contract. "System 1" means a fast, learned, habitual, or reflexive path that can act under tight latency. "System 2" means a slower path that spends extra computation on planning, checking, search, tool use, or explanation before action.

Consider a specific case. Boston Dynamics' Atlas uses low-level whole-body controllers (System 1) running at 500 Hz for balance and joint torque. A separate planning layer (System 2) operating at 5-10 Hz decides foothold sequences on uneven terrain. The timing gap is stark: System 1 closes its loop in 2 ms; System 2 takes 100-200 ms. If you replaced the fast controller with the planning layer, the robot would fall before the first deliberation finished. Google DeepMind's RT-2 (Brohan et al., 2023) follows a similar split. A vision-language model deliberates over the task instruction and scene, then emits a coarse action token that a faster low-level controller converts to joint commands at servo rate. Neither path can substitute for the other: swapping in the slow path destabilizes the control loop, and swapping in the fast path leaves the system with no model of novel objects or instructions. The split also shapes learning. In illustrative training setups of this kind, a whole-body controller can converge in on the order of a few hundred simulation episodes when a fast reflex layer handles balance separately, whereas training with only the slow planner in the loop typically fails to produce a standing policy at all within a much larger episode budget, because the planner is too slow to catch the first perturbation. The exact episode counts are setup-specific and are reported here as an order-of-magnitude illustration, not a benchmark result.

A fast path that cannot think and a slow path that cannot react are not rivals: they are two halves of one controller, and the router is the seam that holds them together.

The routing rule is the core design choice. A simple version is:

Before writing the rule down, it helps to see why it needs two inputs rather than one, because that choice shapes every threshold that follows.

Why uncertainty and risk stay on separate axes

Uncertainty and risk are kept as separate axes because they cause different physical consequences on a real robot. High uncertainty means the fast path's learned policy is extrapolating beyond its training distribution; acting on a bad prediction can damage the end-effector or destabilize a contact. High risk means even a correct action carries large downstream cost, such as a grasp that is near a fragile object. A policy can be certain yet risky, or uncertain yet low-risk. Collapsing both into one score loses that distinction and leads to under-escalation in exactly the cases where hardware damage is likely.

Keeping those two dials separate only helps if each can actually be measured on the incoming observation, so it is worth saying concretely how each score is computed. In practice, \(u(o_t)\) is estimated from predictive variance: Monte Carlo Dropout (a technique that keeps dropout active at inference and runs the network several times so the spread of outputs approximates the model's uncertainty) samples the fast network multiple times and computes variance across outputs, while conformal prediction (a calibration method that turns raw scores into sets with a guaranteed error rate on unseen data) sets the threshold so that the coverage guarantee holds over a held-out calibration split. \(r(o_t)\) is typically a domain-specific function of the current state, such as proximity to obstacles or payload mass. Both scores are computed on the incoming observation before either path executes, keeping the router itself on the critical latency path at under 5 ms.

$$\text{route}(o_t)= \begin{cases} \text{System 1}, & u(o_t) < \tau \text{ and } r(o_t) < \rho \\ \text{System 2}, & \text{otherwise} \end{cases}$$

Here \(u(o_t)\) is uncertainty, \(r(o_t)\) is estimated risk, and \(\tau,\rho\) are deployment thresholds. The assumption is that uncertainty and risk are measurable enough to decide when fast action is safe. The failure mode is false confidence at the router: the fast path acts on a case that should have been escalated, or the slow path consumes time on a routine case until the physical opportunity disappears.

Worked Example

The dual-system design lives or dies by its router, so the example makes the routing rule from the equation above executable and then measures it. System 1 is a fast reflex with a known competence region; System 2 is a slow path that is reliable but expensive. The router escalates whenever uncertainty \(u\) or risk \(r\) crosses a threshold, and we score the policy on latency and safety together.

import numpy as np
rng = np.random.default_rng(0)

TAU, RHO = 0.85, 0.85        # uncertainty / risk escalation thresholds
LAT1, LAT2 = 10, 250         # path latencies in ms

def system1(u):              # fast path: reliable only when confident
    return rng.random() > (0.03 + 0.15 * u) # failure rises with uncertainty
def system2(_u):             # slow path: reliable but expensive
    return rng.random() > 0.02

def route(u, r):
    return "S1" if (u < TAU and r < RHO) else "S2"

lat, fails = [], 0
for _ in range(2000):
    u, r = rng.random(), rng.random()
    if route(u, r) == "S1":
        ok, lat_ms = system1(u), LAT1
    else:
        ok, lat_ms = system2(u), LAT2
    lat.append(lat_ms)
    fails += (not ok)

print(f"mean_latency={np.mean(lat):6.1f} ms   "
      f"failure_rate={fails/2000:.3f}")
# Compare against always-S1 and always-S2 baselines by setting
# TAU=RHO=1.0 (always fast) or TAU=RHO=0.0 (always slow).

Expected output: the routed policy keeps mean latency far below the always-System-2 cost while keeping the failure rate far below the always-System-1 cost, because it spends the expensive path only on uncertain or risky cases. Set TAU=RHO=1.0 to force everything onto System 1 (fast but more failures) or 0.0 to force System 2 (safe but slow); the routed numbers should dominate the relevant axis of each. The near-threshold cases are where calibration matters, which is why the router, not either subsystem, is the first thing to diagnose.

Practical Recipe

1. Write the observation, action, and success metric before choosing a model.
2. Build a baseline that is simple enough to debug by inspection.
3. Add the library implementation only after the baseline behavior is understood.
4. Record failures as structured cases: perception error, state error, planning error, control error, or evaluation error.
5. Run at least one perturbation test before trusting the result.

Dual-system designs earn their keep only when tied to a closed-loop contract that arranges perception, estimation, planning, learning, and control into one system. The contract names five things: the observation stream, the action representation, the timing budget, the safety boundary, and the result artifact. Naming them turns a readable concept into a system a skeptical builder can test.

Separate the conceptual claim, the systems claim, and the evidence claim. A good explanation, a clean API, and one successful rollout are different kinds of evidence, and the section should keep them distinct.

A robust implementation starts with one inspectable baseline whose artifact records observations, actions, units, timestamps, seeds, termination reasons, and the perturbation applied. The maintained-tool version is useful only if it preserves that schema and lets the comparison remain construct-matched.

1. Write a one-paragraph task contract with observation, action, success, failure, and safety fields.
2. Start with the smallest simulator, dataset, or wrapper that exposes the task contract faithfully.
3. Run one deterministic smoke test and one perturbation test before scaling.
4. Save one artifact containing configuration, seed, metrics, traces, and failure labels.
5. Compare methods only when the same script evaluates the same panel, split, seed set, and metric.

When Dual-system (System 1 / System 2) designs and where they come from fails, avoid labeling the whole method as weak. First assign the failure to perception, state estimation, planning, control, timing, data coverage, or evaluation. Then rerun one controlled perturbation that isolates the suspected cause. This pattern turns a disappointing rollout into a reusable diagnostic asset.

For dual-system designs, diagnose the router before blaming either subsystem. Log the uncertainty score, risk score, selected path, deliberation time, and action taken for every episode. Then examine near-threshold cases: these are the examples that reveal whether the handoff policy is calibrated. A useful router improves both safety and latency, not only one of them.