RoboFoundry: System-as-Policy Evolution for Self-Learning Embodied Agents

1 Introduction

• Embodied foundation-model work has progressed from high-level planning toward executable code that interacts with the environment.RoboFoundry positions system-as-policy evolution as a further step beyond code-as-policy execution.Source: §1 · pp. 1, 3
• Evolution spans active context and persistent file-system memory, alongside atomic skills, reusable compositions, and failure-conditioned recovery graphs.Source: §1 · p. 2
• The paper advances from code-as-policy execution to treating the agent system itself as a self-evolving policy.Rather than choosing one component in advance, RoboFoundry uses embodied execution history to decide what to change and how far the change should propagate.Source: §1 · pp. 2–3
• Execution traces guide capability diagnosis and targeted system revisions, with recurring improvements promoted from task-specific support to the general system.RoboFoundry validates task-level edits in place and promotes general updates only after an improvement works beyond the held-in task.Source: §1 · pp. 2–3
• A shared semantic interface separates embodiment-invariant decisions from robot-specific execution, allowing evolved capabilities to be reused across heterogeneous robots and tasks.The system can be reused on another platform by swapping embodiment bindings.Source: §1 · pp. 2–3
• RoboFoundry achieves state-of-the-art results across decision-making, long-horizon memory, and perturbation robustness, with transfer and continued evolution tested on real robots.The evaluation spans different foundation models and tests transfer to unseen robots and tasks.Source: §1 · p. 3

2.1 Self-Evolving System as Policy

• RoboFoundry evolves the supporting system H(M) through filesystem edits while keeping the foundation model M frozen, in inner execution and outer improvement loops.Rollouts record system and tool calls, observations, robot states, outcomes, and task feedback; proposed edits are deployed and evaluated in later rollouts.Source: §2.1 · p. 3, Figure 2 · p. 4
• Task-level edits target completion of the current task, while broader trace history can support promoting reusable improvements to the persistent general system.The general system is assessed for capability gaps shared across tasks and embodiments.Source: §2.1 · pp. 3–4, Figure 2 · p. 4

2.2 Inner-Loop System Execution

• Semantic bindings keep task reasoning separate from robot-specific constraints, while execution bindings ground those decisions in embodiment-specific behavior.This separation helps distinguish task-reasoning errors from execution failures; the execution backend may use frozen VLA policies, generated functions, or visuomotor APIs.Source: §2.2 · p. 4
• The context surface manages active context and persistent filesystem memory through event-triggered updates, evidence storage, retrieval, and use in later decisions.SAVE selects task-relevant evidence for storage, RETRIEVE selects evidence for the next decision, and UTILIZE incorporates it into active context.Source: §2.2 · p. 4
• The skill surface combines atomic executable skills, reusable compositions, and a recovery tree that supports replanning from valid states after failures.Execution traces can attribute failures to atomic execution, composition, or recovery.Source: §2.2 · p. 5

2.3 Trace-Grounded Diagnosis and System Improvement

• For task-level improvement, traces are used to diagnose gaps across six capabilities and propose a targeted edit to the corresponding context or skill surface.A candidate edit is evaluated in a new inner-loop execution; successful repairs are stored with capability labels for later general improvement.Source: §2.3 · p. 5
• General improvement tests whether a successful task-specific repair can become a reusable rule, using same-capability records from other tasks as held-out traces.The candidate general edit is abstracted from a successful repair and assessed on those other-task records.Source: §2.3 · p. 5

3.1 System-Level Evolution of Embodied Decision-Making

• RoboFoundry improves all five tested backbones on EmbodiedBench, including a 27.8% gain for GPT-5.5; full RoboFoundry gains 11.2% over Lite on Qwen3.7-Plus.Three quarters of held-in data recover most of the final score, with EB-Habitat saturating at 74.0%.Source: §3.1 · p. 6, Table 1 · p. 7

3.2 Long-Horizon Memory through Context Evolution

• RoboFoundry achieves 53.5% TSR and 72.8% CSR on RoboMemArena, outperforming baselines across all four categories.Context evolution also improves both standalone π0.5 and PrediMem across categories, including a 200.0% relative TSR gain for PrediMem on Transfer.Source: §3.2 · pp. 6–7, Table 2 · p. 7, Table 3 · p. 8

3.3 System Evolution under Distribution Shift

• RoboFoundry leads methods without privileged object poses across six LIBERO-PRO settings, averaging 91.9% success versus 87.8% for Harness VLA (CC).With privileged poses, it reaches 100% on both Object and Goal task perturbations; the authors identify perception as a remaining bottleneck.Source: §3.3 · pp. 7–8, Table 4 · p. 8

3.4 Real-World Evaluation

• On real robots, RoboFoundry reaches 70% nesting-doll success versus 30% for π0.5 and transfers its blue-towel skill to held-out towels with over 80% success versus below 20% for π0.5.It also preserves state across six dependent chemistry subtasks, and demonstrates semantic navigation on a Unitree G1; the real-world setup starts without task-specific adaptation and applies updates only between trials.Source: §3.4 · pp. 8–9, Figure 6 · p. 8, Figure 5 · p. 8

Foundation Models as Embodied Agents

• RoboFoundry formalizes System-as-Policy: executable behavior depends jointly on the foundation model and its supporting system, which embodied experience can change persistently.This contrasts with approaches that optimize interaction harnesses, memory, skills, or programs as separate components.Source: §4 · p. 9

Self-Evolving LLM/MLLM Agents

• A shared semantic interface separates task-level reasoning from robot-specific execution, allowing system revisions to be reused across embodiments.This extends self-evolving agent work to cross-embodied execution.Source: §4 · p. 9

Self-Improving Embodied Agents

• RoboFoundry treats context and skills as complementary intervention surfaces and evaluates task-level repairs on related held-out cases before promoting them into general capabilities.This distinguishes its system-level adaptation from work focused on individual skills, memory, orchestration, or program repair.Source: §4 · p. 9

• RoboFoundry is presented as an embodied agentic framework for System-as-Policy Evolution.Source: §5 · p. 9
• RoboFoundry uses execution traces to improve task performance and promotes validated improvements into general system capabilities for future tasks.Source: §5 · p. 9
• The framework bridges general-purpose models and embodied scenarios while improving decision-making, memory management, and skill execution.Source: §5 · p. 9

• The representative cases illustrate repairs to perception, reasoning, planning, and low-level skill execution.Source: Figure 7 · p. 12, §A.1 · p. 12
• The examples compare GPT-5.5's initial execution with the final candidate promoted by RoboFoundry's evolution.Source: §A.1 · p. 12
• Each initial and final candidate is compared using the same episode and instruction.Source: §A.1 · p. 12

• The accepted revision replaces relatively long action sequences with shorter, feedback-grounded actions and observation checkpoints.It prefers one action, at most two when currently supported, and an observation after navigation before interaction.Source: §A.1.1 · p. 12
• The shared recovery rule does not encode the cleanser, sink, or sofa; runtime instantiation binds it to the failed action, object, and environment feedback.Source: §A.1.1 · p. 12
• The recovery sequence navigates after a not-near pick failure and then completes the cleanser relocation task.Source: §A.1.1 · p. 12

• 15 valid actions did not complete the task, while the accepted revision succeeded at the sixth action.Source: §A.1.2 · p. 12
• The revised insertion strategy keeps holding while aligning and descending, releasing only inside or just below the matching opening.Source: §A.1.2 · p. 12
• The task-conditioned action sequence changes from an early release to a grasp-preserving descent before release.The final action dimension controls the gripper.Source: §A.1.2 · pp. 12–13

A.1.3 Example 3: Support-Surface Grounding in EB-ALFRED

• The accepted revision distinguishes the laptop’s target spatial region from the sofa’s executable support surface.The instruction is to place the newspaper next to the left laptop.Source: §A.1.3 · p. 13
• The laptop supplies a semantic spatial reference, while the sofa supplies the physically valid surface for execution.Source: §A.1.3 · p. 13
• The listed runtime plan finds and picks up the newspaper, then finds the laptop and sofa.Source: §A.1.3 · p. 13

A.1.4 Example 4: Reachable-Floor Reasoning in EB-Navigation

• 3.9 m to 0.9 m: the final target distance decreases under the accepted navigation revision.The revision also uses shorter movement segments, allowing new observations and collision feedback to affect subsequent actions.Source: §A.1.4 · p. 13
• The revised planner reasons about the reachable floor path, not only the target image location.Source: §A.1.4 · p. 13
• For a target on furniture, the revision directs the planner to approach the free floor beside the support surface.Source: §A.1.4 · p. 13

A.1.5 Persistent Filesystem Evolution

• Execution produces grounded traces, while the Evolution Ledger stores bootstrap, parent–candidate, evaluation, and failure evidence; accepted revisions persist reusable rules in the system policy.Source: §A.1.5 · pp. 13–14, §A.2.6 · p. 17

A.2.1 Example 1: Task Progress as Active Context in Transfer

• Transfer and Counting convert recorded stage progress into an explicit next subgoal while retaining the overall task and avoiding repetition of completed steps.Source: §A.2.1 · pp. 14–15, §A.2.3 · p. 15

A.2 RoboMemArena Evolution Case Studies

• Full-task success increases from 40 % to 70 % across the corresponding 10-episode search evaluation and from 60 % to 80 % across the search evaluation; stage completion changes from 50 % to 75 %.Source: §A.2.1 · p. 15, §A.2.3 · p. 15, §A.2.2 · p. 15

A.2.2 Example 2: External Visual Memory under Occlusion

• Occlusion evolution prioritizes the latest frame, uses sparse historical keyframes as reminders, and treats attempted commands as insufficient evidence of physical success.Source: §A.2.2 · p. 15

A.2.4 Example 4: Local Progress Improvement in Sequence

• Sequence adds stage-specific execution constraints and safeguards against repeating completed steps, improving intermediate progress without resolving the complete task.Source: §A.2.4 · p. 16, §A.2.6 · p. 17

A.2.5 Persistent Filesystem Changes

• Persistent context changes modify shared context-management code, while LIBERO keeps shared executable revisions, outer-loop evidence, and trial-local generated task code in separate workspace areas.Source: §A.2.5 · p. 16, §A.3.4 · p. 19

A.3.1 Persistent Evolution

• LIBERO persistent revisions change task-generation prompts, API semantics, reusable physical-motion skills, and launch logic; object-center targets keep TCP offsets inside the execution interface.Source: §A.3 · p. 17, §A.3.1 · pp. 17–18

A.3.2 Example 1: From Long Manipulation Code to Composite Skills

• A manipulation composite skill persists in the shared system while push–regrasp recovery remains trial-local; a bowl example changes execution abstraction without spatial-grounding success.Source: §A.3.2 · p. 18, §A.3.3 · p. 18

A.3.4 Filesystem Organization

• The filesystem separates persistent shared evolution, which stores reusable execution abstractions, from trial-local recovery, which revises generated task code using execution feedback.Source: §A.3.4 · p. 19