Persistent Recursive Worlds Enable Autonomous Software Evolution

EvoX Genesis (hereafter, Genesis) is a system that reorganizes long-horizon software development around a persistent recursive project rather than a persistent agent. The paper introduces the concept of a persistent recursive world, where the accepted project state and its history persist; local agents do not. A local software world is defined as a pair w = (v, p), where v denotes an accepted software version and p a repository-relative path. The version fixes the complete accepted project state and its inheritable history, while the path situates agency within that project. Finite-lived agents enter the project from an accepted version and path, perform a bounded task, propose a change, and terminate. Recursive delegation moves work to more specific paths without immediately changing the accepted version, and validation-gated acceptance determines which consequences become part of the history inherited by later agents. The paper states: Genesis does not attempt to make one agent persistent. It makes the project persist and repeatedly re-instantiates agency within it.

The paper evaluates this organization across three stages: formation, continuation, and redevelopment. In the formation experiment, starting from a repository with no compiler implementation, Genesis used DeepSeek V4 Flash to build a Rust-based C compiler. The run lasted over 120 hours (123.4 h), archived 1,019 agent episodes, reached delegation depth five, and incurred only US44.38 in model-token charges. The final repository contained 248,989 physical lines in 750 tracked text files. The compiler passed 220/220 reported c-testsuite cases, 32/36 evaluated LLVM cases, 93/93 executed Csmith programs, and passed 2,904 Rust workspace tests, along with recorded LZ4 and SQLite checks. The paper notes: "Compiler construction couples decisions made at different times: choices in the front end constrain type checking, the intermediate representation constrains optimization and code generation, and later integration can expose problems in components that appeared locally complete. No single agent episode spanned this development."

In the continuation experiment, a separate compiler world generated with GLM 5.2 was continued after repeated agent replacement and a change of foundation model. Two branches started from the same completed jcc repository at commit 37216cfa254a: one continued with GLM 5.2 and the other switched to DeepSeek V4 Flash. Both branches resumed development through repeated replacement of finite-lived agents. GLM 5.2 passed 1,445/1,448 cases in its retained LLVM test set, whereas DeepSeek V4 Flash passed 1,820/1,820. GLM used 98 agents and reached observed depth four, while DeepSeek used 178 agents and reached depth eight. The paper states: "Model replacement changes the process that proposes local changes, yet both branches resumed from the same completed compiler and then diverged in agent counts, delegation depth, commit history, code churn and final repository size. The inherited world therefore acted as a common starting point and a set of obligations rather than a script that fixed the next state."

In the redevelopment experiment, Genesis reimplemented 13 MESA (Modules for Experiments in Stellar Astrophysics) modules with over 100k Fortran lines (139,414 physical Fortran lines) as a Rust workspace with nearly 90k Rust lines (89,946 physical Rust lines including tests and benches). The run completed in 33.22 hours, spawned 272 agents, and passed 1,052 tests with no failures and 18 ignored tests, at a provider-recorded model-token cost of US10.64. Across six audited numerical workloads, EOS lookup and Newton solve were bit-exact; relative checksum differences for the other four workloads ranged from 5.1 × 10−15 to 3.1 × 10−9. Rust had the lower median runtime in all six workloads, with measured speedups from 1.55× to 6.87×. The paper notes: The task was therefore not simply to produce Rust code: implementation could change, but the tested numerical relationships carried by the original software had to survive.

The paper's central design choice is where continuity resides. Many long-horizon agent systems extend an agent process through longer context, explicit memory, a persistent manager or shared state. Genesis instead makes the accepted project the persistent object: Code, path-specific context, constraints, validation results and history remain available to later work, while local agents can terminate. The paper clarifies that the software world is therefore not an auxiliary memory attached to a long-lived agent; it is the project state from which successive agents are instantiated. The world has no persistent private intention, conversation or cognitive identity; reasoning remains in finite-lived agents.

The paper acknowledges causal boundaries: The present experiments establish capability across three distinct regimes, but they do not yet provide a complete causal decomposition of the mechanism. Recursion was operationally central, reaching observed depths of five in compiler formation, four and eight in the two continuation branches, and four in MESA redevelopment, but the paper states these observations do not establish that recursion is causally superior to flat or alternative organizations. The paper also clarifies its use of software evolution is practical rather than biological: Agents do not reproduce, and the present study does not claim Darwinian evolution, open-ended self-modification or learning of the foundation-model parameters. Similarly, autonomous is bounded rather than absolute: humans provide initial objectives, tools, validation sources and controller limits, and within those conditions, Genesis decomposes work, instantiates local agents, executes development actions and determines which validated consequences enter the persistent project.

The paper concludes: "EvoX Genesis reorganizes long-horizon software development around a persistent recursive project rather than a persistent agent. A local world is situated by an accepted version and a repository path; finite-lived agents propose changes; recursive delegation moves work across paths; and accepted consequences advance the version history inherited by later agents. Under this organization, the reported runs formed a large C compiler from an implementation-empty repository, continued an existing compiler after foundation-model replacement and redeveloped selected MESA modules in Rust while preserving the audited numerical behaviour. These results motivate a broader hypothesis: persistent project state can carry software development across changing episodes of intelligence. Determining exactly which persistent records and recursive mechanisms are necessary is the next step."

Improvements to AI systems:

1. Implement persistent, versioned project state as the primary memory mechanism – Replace agent-centric memory (context windows, scratchpads, or manager states) with an immutable, path-addressed repository of accepted versions, validation results, and history. The AI system’s “memory” becomes the project’s commit graph, not the agent’s internal state. This allows finite-lived agents to terminate cleanly without losing critical context.

2. Enable recursive delegation via path-specific sub-worlds – Allow an AI system to spawn child agents that operate on narrower repository paths (e.g., src/compiler/type checker/) without modifying the accepted global version. Each child proposes changes that are validated against the parent’s constraints before merging. This enables hierarchical decomposition of long-horizon tasks without requiring a single agent to hold the entire problem in context.

3. Use validation-gated acceptance as a hard filter for state advancement – Require that any proposed change pass a defined set of tests, checks, or numerical tolerances before it becomes part of the persistent project history. This prevents error accumulation across many agent episodes and ensures that later agents inherit only verified consequences, not speculative or broken intermediate states.

4. Support seamless foundation-model replacement mid-task – Design the system so that the persistent project state is model-agnostic. When a new or different AI model is introduced, it can resume from the last accepted version and path without needing to replay or re-learn prior agent conversations. This allows continuous improvement as better models become available, without restarting the project.

5. Maintain explicit, auditable numerical and behavioral invariants across reimplementation – For tasks like porting or rewriting code, the AI system should store and enforce a set of invariant checks (e.g., bit-exact outputs, checksum tolerances, or test suites) that must survive any code changes. This ensures that the system’s output preserves the functional contract of the original software, even when the implementation is entirely new.

6. Decouple agent lifetime from task duration – Allow agents to be short-lived (e.g., minutes to hours) and focused on a single bounded task, while the project persists indefinitely. The AI system should automatically spawn new agents from the latest accepted state as needed, eliminating the need for long-running, context-heavy agents that degrade in performance or cost.

7. Track and archive every agent episode for post-hoc analysis – Record each agent’s actions, proposals, and outcomes in the project history. This enables the AI system to audit its own decision-making, identify which delegation paths were effective, and potentially improve future delegation strategies without requiring a persistent agent to remember them.

What the improved AI system can do:

• Build a large, complex software artifact (e.g., a compiler, a numerical library, or a full application) from scratch over 100+ hours of cumulative work, using thousands of short-lived agent instances, with total token costs under 50 and no single agent ever needing to hold the entire project in context.

• Continue development of an existing codebase after a complete change of the underlying AI model, resuming from the last accepted commit and producing new, valid improvements without any loss of prior progress.

• Rewrite a legacy codebase (e.g., 100k+ lines of Fortran) into a modern language (e.g., Rust) while preserving exact numerical behavior, passing all original test suites, and achieving significant runtime speedups—all within a few days and at minimal cost.

• Handle tasks where decisions made at different times are deeply coupled (e.g., front-end choices constraining back-end code generation) by delegating to specialized sub-agents that work on isolated paths, with the persistent project state ensuring that later integration catches and resolves cross-component conflicts.

• Operate with bounded autonomy: the system can decompose, execute, and validate work autonomously within human-provided constraints (objectives, tools, validation sources), but does not require a persistent cognitive identity or long-term memory to do so.