Paper note / 2026-09-15arXiv:2608.10450v121 min read
EvoX Genesis: A Project History That Outlives Its Agents
EvoX Genesis is an autonomous-development system that treats a repository, its accepted versions, and recursive responsibility paths as a persistent “software world.” It addresses a structural problem in long-running agent work: when every agent has a finite context and lifetime, how can a large project continue across more than a thousand work episodes without losing its verified history?
In one sentence: Genesis does not try to keep one agent alive forever. It makes agents replaceable and accepted world state unambiguous: only a candidate change that passes parent-level acceptance advances persistent history.
Why a longer context window still does not solve long-term development
Large software projects operate on three different clocks. One model call lasts minutes, a delegated task may last hours, and a repository evolves for months. Packing more logs into context only delays forgetting. It does not define which version was accepted, whether a failed branch contaminated the baseline, or which constraints remain binding after a model is replaced.
Genesis moves persistent identity from the agent to the software world. The paper represents that world as w = (v, p): v is the accepted version and history, while p is the repository-relative path of responsibility. An agent is a finite-lived worker operating on that world, not the owner of continuity.
Accepted code, test state, and traceable history; the only valid baseline for later work.
A repository-relative scope that aligns recursive delegation with code structure.
Receives a bounded task, produces a candidate diff, and may delegate into deeper paths.
The transition (v,p) → (v′,p′) occurs only after parent acceptance. A rejection does not silently advance history.
How it differs from ordinary coding-agent workflows
| Approach | Where continuity lives | Typical risk | Genesis response |
|---|---|---|---|
| Single agent, long context | Conversation history | Compression, drift, incomplete evidence | Repository and acceptance history persist outside context |
| Parallel agents | Shared task list | Branch conflict and ambiguous ownership | Delegation binds to a repo-relative path |
| Scripted pipeline | Fixed stages | Cannot reorganize around unknown structure | Agents recursively create narrower work worlds |
| Genesis | Accepted world history | A flawed acceptance gate can still compound errors | Candidate diff, constraints, and provenance are archived together |
Delegation can recurse; history advances only through acceptance
Change the parent's decision to see the difference between candidate work and persistent history. This is a teaching redraw of the paper's state transition.
tests: 1,812 / 1,812
path: compiler/backend
candidate Δ: add switch lowering
delegated episode: #1,019
The parent accepts the candidate. Persistent history advances, and the next finite-lived agent continues from v₄₂.
Do not confuse infrastructure with the model: worktrees, BEAM processes, and the scheduler enable concurrent execution. Continuity comes from the accepted version, responsibility path, constraints, and provenance—not from a permanently running agent process.
123.4 hours: forming a C compiler from an empty world
One formation run with DeepSeek V4 Flash at xhigh effort.
Archived agent work episodes, reaching recursive depth 5.
Reported token charges only; infrastructure, storage, and labor are excluded.
| Acceptance suite | Passed | Total | What it establishes |
|---|---|---|---|
| c-testsuite | 220 | 220 | Coverage of common C language features |
| Evaluated LLVM cases | 32 | 36 | Four failures remain; this is not complete compatibility |
| Csmith | 93 | 93 | All random-program tests in this batch passed |
| Rust tests | 2,904 | 2,904 | Internal project test scale, not independent certification |
The repository reached 248,989 physical lines and 750 tracked text files, while also passing LZ4 and SQLite checks. The scale demonstrates sustained maintenance across many files, but line count is not a substitute for complexity, correctness, or production readiness.
The critical test: replace the agent and model, then keep going
The continuation experiment starts from a completed GLM 5.2 jcc world. The GLM branch retains 1,445 of 1,448 LLVM cases; the DeepSeek continuation retains 1,820 of 1,820. Because the branches use different retained test sets and unmatched budgets, these numbers are not a head-to-head model comparison. The narrower supported claim is that a persistent software world can continue across model replacement.
A second case rewrites part of MESA's Fortran scientific code in Rust: 13 mapped module directories and 139,414 physical Fortran lines including tests. It runs for 33.22 hours with 272 agents, producing 89,946 Rust lines including tests and benchmarks. A total of 1,052 tests pass, 18 remain ignored, token charges are $10.64, and relative checksum differences range from 5.1e-15 to 3.1e-9.
| Experiment | Continuity evidence | What it does not establish |
|---|---|---|
| Compiler formation | One new world survives 1,019 episodes | A repeat-run success rate |
| Model continuation | A new model inherits accepted world state | DeepSeek outperforming GLM in a controlled comparison |
| MESA rewrite | Cross-directory decomposition, tests, and numerical checks | A rewrite of all MESA; higher-level star, astero, and binary modules are excluded |
A strong capability demonstration with narrow statistical evidence
Supported in these cases: accepted world history enables hundred-hour development, more than a thousand agent episodes, recursive delegation, and continuation after a model replacement.
Useful for a GM layer: residents can submit bounded mechanic proposals, finite-lived development agents can implement them, and tests, performance budgets, and replay checks can decide whether they enter the world version.
Still unproven: zero human supervision, safe long-running production service, correct prioritization of open-ended needs, or continued adoption of generated mechanics by the original residents.
- Each case has very few runs. One formation, two continuations, and one rewrite demonstrate feasibility but cannot estimate success probability.
- Human actions are incompletely archived. The record cannot strictly prove zero intervention, so “autonomous” should not be read as a mathematical no-human guarantee.
- The cost boundary is narrow. Reported charges cover tokens, excluding compute, storage, monitoring, evaluation design, and labor.
- Test retention is not independent correctness. Agents can overfit an acceptance suite; external behavior, performance, and safety still require separate evaluation.
- The acceptance gate can be wrong. Once a bad version is accepted, persistence propagates it to every successor. The longer the world lives, the more important rollback and provenance become.
For InfiniteAincrad: make GM development a reversible world evolution
Residents state bounded needs
A request must identify world objects, affected modules, acceptance conditions, and a resource budget—not merely ask for “a new game mechanic.”
Build mechanics on isolated branches
Finite-lived agents may delegate recursively but cannot edit the live world directly. Every diff, test, and execution replay enters provenance.
Measure use after release
Technical acceptance only moves v to v′. Resident use, maintenance, forks, and abandonment determine whether a mechanic becomes social infrastructure.
Genesis supplies a layer that SwarmWorld does not explore deeply. When a resident artifact becomes code or a game mechanic, the project needs a version history that outlives every agent and advances only through explicit acceptance. It is a model for the GM development backend, not the resident society itself.