Embodied AI Turns to Systems: RoboFoundry Enables Robots to Self-Evolve

The same GPT-5.5, placed into different systems for embodied tasks, can perform vastly differently. RoboFoundry's starting point is exactly this observation: the embodied policy that actually executes in an environment is never just a model, but the model plus the entire system it sits inside—what information is brought before the model, what experience is retained, and how decisions become the robot's physical actions.

The system around the model is mostly still manually built and fixed after deployment. Existing work often improves only one component among memory, skills, and the interaction harness; problems exposed during execution are mostly used only for evaluation or manual debugging, and the same weaknesses repeat round after round. The question RoboFoundry raises is: can an embodied agent treat its entire system as the policy, diagnose where the system is constraining behavior, and then evolve the corresponding parts from embodied experience.

According to a report by Machine Heart, a research team from Nanyang Technological University, Beihang University, the National University of Singapore, Shanghai Jiao Tong University, Yundie Technology, and other institutions proposed RoboFoundry, and positions it as the first embodied agent framework to formalize the agent system itself as a "Self-Evolving System-as-Policy." It should be noted that "first" is the authors' claim, and the source does not provide a complete basis for comparison with other work.

RoboFoundry does not update the base model's parameters; what gets optimized is the system that supports the model in completing tasks. This system exists as files, and the model can view them with cat and grep and modify them with add, modify, and delete, much like a developer maintaining a codebase. The system is divided into two layers: a task-level system serving the current task, and a general system retained across tasks and embodiments.

Evolution proceeds through two nested loops: the inner loop executes tasks and records execution traces; the outer loop proposes modifications based on the traces, which are then handed to subsequent execution for testing. Modifications act on two "evolution surfaces." The context surface manages the active context of the current round and the file-system memory across rounds, deciding what to remember, what to retrieve, and how to use it through three types of operations: SAVE, RETRIEVE, and UTILIZE; the skill surface ranges from atomic skills to composite procedures like "move-grasp-place," and further to failure-recovery trees, so that when execution fails, the system replans from a still-valid state.

Beneath the two evolution surfaces there is also a shared semantic interface. The semantic layer handles only task logic shared across embodiments, while the execution layer adapts decisions to a specific robot; the backend can be a frozen VLA (such as π0.5), a function generated by a coding agent, or a visuomotor interface such as CuRobo. Because evolution acts on the semantic side, a system evolved on one robot can be reused on another robot by swapping the execution adaptation, and can also be connected to different base models.