Physical recursive self-improvement
Six solved episodes from the run
✳01 · Results
365 tasks solved in 493 episodes
Tasks solved · cumulative
0 / 365
Tasks solved against episodes spent
The final library, run once more on every task
✳02 · Self-improvement rounds
Skills and functions evolved after every round
Size of the skills and functions, by version
✳03 · Final library
Six skills and seventy functions, distilled from trials
Calls into the package from the workers' own code
Function visualization
Illustrated sequence
Drag to inspect each motion
source
✳04 · Harness architecture
Skill-oriented self-improver
The fixed core is the controller. It runs trials and records the simulator’s verdicts, and knows nothing about kitchens or robots. Everything task-specific lives in the library, as general skills of two kinds: Markdown skills for RoboCasa and the rc Python functions. The principal is the self-improver, itself a task-agnostic skill: it reads the trials so far and evolves the library. No model is trained.
Scroll the diagram horizontally to explore the full architecture →
Why this design
- No infinite regress. If the improver had to be improved by another improver, that one would need its own, and so on. Here the chain stops at the fixed core: the improver is a skill like any other (see Who Improves the Improver?).
- One skill for all agents. The self-improver is itself a skill, not part of any one agent. It loads like any other skill into any general agent, including Kinex, which is designed for physical AI.
- Parallel at runtime. The controller starts the workers and the principal as separate agents, so the principal can improve the library from the data already collected while the workers keep running episodes; neither waits for the other. With nested agents, where one agent calls the other, one always waits for the other.
✳06 · Contributors
