REA runtime lifts robot success on LIBERO-Pro to 95.9% and cuts control steps by 25%

A team from the National University of Singapore, UC Berkeley, the University of Tokyo, HKUST and other institutions has proposed REA (Routed Embodied Agent), a single runtime in which a slow "brain" built on a large model and fast "reflex" policies run asynchronously. The system's core rule: no executing policy ever waits for the brain. On 3000 test episodes across 60 LIBERO-Pro tasks (a variant of the manipulation benchmark with a perturbed test set), REA succeeded in 95.9% of episodes, against 94.7% for the strongest single baseline, Agents SDK + GPT-6. Control steps fell by 25% and control time by 17%.

Three layers instead of one control loop

Large models reason well, but they are too slow and expensive to act as controllers. Fast VLA policies and whole-body controllers such as SONIC are reflexively precise but generalize poorly. REA's architecture has three layers. System 2 is the agent "brain": offline, it generates policies (frozen Python programs); online, it gives advice and rules on whether a task is complete. System 1 is a router that issues no actions itself. It decides which policy to launch and when to consult the brain. System 0 is the fast policies: programs, VLA models or whole-body controllers. They run at their own pace and hand control back to the router at segment boundaries.

The router relies on three mechanisms. The first is route memory: before evaluation, each policy is run on dev episodes, and its success rate and cost are recorded in a table, so choosing a policy at test time comes down to a lookup. The second is a boundary judge: when a policy returns control, a vision model compares the initial and current frames against the instruction and decides whether the task is done. The third is an escalation ladder with a shared budget of steps and time.

Why the simple designs fail

The authors show that two obvious ways of linking brain and reflexes break down. If the agent calls a fast policy and the router waits for the agent's advice, the robot sits idle for 2.6 s per LIBERO-Pro episode, about 20% of control time. If instead a policy calls the agent only on error, most failures go unnoticed: a router with an exception trigger escalated just 6 times across 590 episodes, even though 166 of them failed. Re-running a task that is already complete can ruin the result, so the judge also protects finished work.

Using a model as a direct controller does not work either. In probes, models that emit single tokens or Cartesian IK actions solved 1 of 1987 and 0 of 600 LIBERO-Pro episodes. Policy generation is not cheap: the median is 43 minutes per LIBERO task, and the Codex + GPT-6 pipeline spent 89 million input tokens on 60 LIBERO-Pro tasks. VLA models that score above 90% on standard LIBERO degrade sharply on the perturbed LIBERO-Pro set.

Results and limitations

REA came within 1 percentage point of the per-task "retrospective oracle" (the ideal policy choice for each task) and was the fastest of the methods measured on time: 17% less control time than Agents SDK + GPT-6 and 25% less than the blocking advisor. The boundary judge improves quality over the exception trigger, but it spends 2.1 times more time per success.

In a separate RoboTwin 2.0 study (50 clean and 50 randomized episodes each), REA with VLA policies reached 84%, and 86% with code added. The strongest single VLA baseline, MEDex, scored 80%. Trained and programmatic policies run in the same runtime. On BEHAVIOR-1K, the system solved 27 of 50 episodes against 25 for an Agents SDK-based agent, but the authors note that the difference is not statistically significant. On another RoboTwin sample, REA scored 97 of 200 against 75 for Codex CLI. On a real Unitree G1 humanoid, the robot walked to a chair and pushed it in 8 of 10 attempts.

The caveats are as follows. The main gain over the best single policy on LIBERO-Pro is 1.2 percentage points, and a significant part of the effect comes from efficiency: fewer steps and less time. Route memory is tuned on dev episodes before testing, and the policy pool is assembled from programs written by coding agents, so the result depends on the quality of that pool. The practical takeaway for robot developers: a "large model plus fast policies" stack is better built as a dispatcher with pre-measured statistics, where the expensive model is called rarely and off the critical path.