RoboFoundry: Self-Evolving System-as-Policy Boosts Embodied Agents Without Model Updates

RoboFoundry freezes foundation models and evolves the surrounding system — context, skills, and execution interfaces — via a closed-loop of execution, reflection, repair, and promotion, achieving large gains on EmbodiedBench, RoboMemArena, LIBERO-PRO, and real-robot zero-shot transfer and online evolution.

Machine Heart
Machine Heart
Machine Heart
RoboFoundry: Self-Evolving System-as-Policy Boosts Embodied Agents Without Model Updates

Researchers from Nanyang Technological University, Beihang University, National University of Singapore, Shanghai Jiao Tong University, and CloudMinds propose RoboFoundry , the first framework that formalizes the agent's entire system as a Self-Evolving System-as-Policy . The foundation model (e.g., GPT-5.5) stays frozen; evolution occurs in the context system, skill system, and execution interfaces, mediated by a shared semantic layer that enables cross-robot and cross-model reuse.

Core Idea: Model Frozen, System Evolves

RoboFoundry treats the supporting system as files that the model can inspect and modify with cat, grep, add, modify, delete — like a developer maintaining a codebase. The system has two layers:

Task-level system — serves the current episode.

General system — persists across tasks and embodiments.

Evolution runs in two nested loops:

Inner loop : execute task, record trajectory.

Outer loop : diagnose capability gaps from failures, propose modifications on two evolution surfaces :

Context surface : manages active context and cross-episode filesystem memory via SAVE, RETRIEVE, UTILIZE operations.

Skill surface : atomic skills, composite workflows (e.g., move–grasp–place), and failure-recovery trees that re-plan from a valid state.

Below both surfaces sits a shared semantic interface that handles only cross-embodiment task logic; the execution layer adapts decisions to a specific robot (frozen VLA like π0.5, code-generated functions, or CuRobo). Because evolution acts on the semantic side, a system evolved on one robot can be reused on another by swapping the execution adapter, and can be attached to different foundation models.

Diagnosed, Verified Evolution Loop

Failures are attributed to one of six capabilities: perception, reasoning, planning (decision capabilities) or save, retrieve, utilize (memory-management capabilities). Modifications are proposed only on the relevant surface and only committed if they fix the current task's failure.

Accepted changes are abstracted into candidate rules. The system then replays other tasks that exhibited the same capability gap, applies the candidate rule, and compares the new repair against the historically successful repair. Only if the average score matches or exceeds the original repair does the rule get promoted to the general system.

An example evolution trace on EB-Habitat (spatial-reasoning subset, GPT-5.5) shows six candidate evaluations:

First three accepted: held-in success rate rises from 21.4% to 50.0%.

Next two rejected (only 42.9%).

Final candidate pushes success to 78.0% and passes held-out check → promoted to general system.

Accepted modifications become concrete file diffs. For the instruction “move all cleaner from sink to sofa,” the system rule changed from:

- Each plan should include no more than 20 actions.
+ Prefer one action; at most two when both are currently supported.
+ After Navigation, observe before Pick/Place/Open/Close.
+ Trust environment feedback over visual appearance for proximity.
+ After a not-near Pick failure, navigate before retrying.

The new rules mention no specific objects, enabling cross-task sharing. The full evolution history is stored in .robofoundry/ (the “Evolution Ledger”).

Benchmark Results

EmbodiedBench (1,128 tasks across four environments)

GPT-5.5 : 56.9% → 72.7% (+27.8% relative). Evolved GPT-5.5 surpasses unevolved GPT-6 Astra (71.9%).

All five foundation models improve.

Gap between strongest and weakest base models shrinks from 19.6 to ~11.5 percentage points.

Strongest model (GPT-6 Astra) still gains +8.5% relative.

Ablation: full system beats task-level-only “Lite” by +11.2% relative (Qwen3.7-Plus). Context-budget increase (4K→16K) yields mixed base-model results; RoboFoundry still adds +7.9%–13.1% relative on top of 16K baselines.

RoboMemArena (long-horizon memory, 26 tasks)

Qwen3.7-Plus + RoboFoundry: 53.5% TSR, 72.8% CSR — leads all four task categories.

TSR exceeds every baseline by ≥39.0%, including PrediMem (which uses Qwen3-VL-8B-Instruct for memory).

Evolved mechanisms go beyond prompts: e.g., converting task progress into current sub-goal, and explicitly forbidding “attempted instructions” as evidence of physical success.

LIBERO-PRO (perturbation robustness)

Among methods without privileged object poses, RoboFoundry achieves 91.9% average success vs. 87.8% for Harness VLA (CC).

Outperforms CaP-Agent0 by 243.8%–679.7% (relative).

Evolved improvements split into long-term reusable composite skills (kept in shared system) and trial-specific recovery logic (kept only for that trial).

Real-Robot Experiments

Base model: GPT-5.5; execution backend: π0.5 (same fine-tuned checkpoint for fair comparison). RoboFoundry starts with zero task-level adaptation; each task tested 10 times, online evolution trials counted in success rate; system updates only between trials.

Nesting dolls (AgileX COBOT MAGIC) : requires size-order stacking and precise insertion. Trial 1 fails (drop) → skill-surface adds alignment check. Trial 2 uses aligned insertion but loses task progress → context-surface adds progress tracking to resume from last completed sub-task. Trial 3 succeeds fully. Final success: RoboFoundry 70% vs. π0.5 alone 30%.

Towel folding (zero-shot transfer) : skill evolved only on blue towel; directly applied to unseen green/pink towels (different appearance, geometry, material). RoboFoundry >80% success; π0.5 <20% and needs further fine-tuning.

Humanoid navigation (Unitree G1) : via shared semantic interface, “Find drinking water” maps to recognized water cooler in RGB, then embodiment-specific execution binding converts to navigation actions.

Chemistry experiment (long-horizon dependencies) : six dependent sub-tasks (insert funnel, place weigh boat, tare balance, add powder with spatula, return spatula, pour into flask). RoboFoundry chains task-state records — final pour reads “funnel ready” state written several sub-tasks earlier. π0.5 alone cannot complete the full sequence.

Conclusion

From language-model planning to Code-as-Policy to System-as-Policy evolution, the foundation model's role in embodied systems keeps moving upward. RoboFoundry demonstrates a concrete path: keep the base model fixed, let execution trajectories drive targeted system modifications, verify each fix on the current task, and only promote fixes that generalize across similar capability gaps. As foundation models grow stronger, embodied intelligence progress may come not only from “training a stronger model” but also from “letting the model's surrounding system continuously grow stronger.”

Paper: https://arxiv.org/abs/2609.32862

Project page: https://jingsongliang.com/robofoundry

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Embodied AISelf-Evolving SystemsZero-Shot TransferRoboMemArenaEmbodiedBenchLIBERO-PROOnline EvolutionRoboFoundrySystem-as-Policy
Machine Heart
Written by

Machine Heart

Professional AI media and industry service platform

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.