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

A Careful Control Loop

This section develops the technical contract for dual-system (system 1 / system 2) designs and where they come from into a usable mental model. First we define the object of study, then we connect it to the agent loop, then we test it with a compact implementation.

The key question in Dual-system (System 1 / System 2) designs and where they come from 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

For Dual-system (System 1 / System 2) designs and where they come from, the practical design rule is to make the interface inspectable before optimization begins: inputs, outputs, units, latency, bounds, and failure labels should all be visible in the saved artifact.

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.

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

$$\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: 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 (System 1 / System 2) designs and where they come from becomes useful when it is tied to a closed-loop contract for how perception, estimation, planning, learning, and control are arranged into a system. The contract names the observation stream, the action representation, the timing budget, the safety boundary, and the result artifact. That is the bridge between a readable concept and a system a skeptical builder can test.

For Dual-system (System 1 / System 2) designs and where they come from, 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.

For Dual-system (System 1 / System 2) designs and where they come from, 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.