Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution

Anton Razzhigaev, Andrei Gritsaev, Andrei Kaznacheev, Nikita Dragunov, Roman Yampolskiy, Andrei Kuznetsov

Ouroboros is a self-evolving coding agent that treats its own harness as a versioned, reviewed repository.

How can we build a coding agent that safely and autonomously improves its own core implementation and tools through a reviewed evolutionary process?

Coding agents typically rely on fixed harnesses that cannot adapt to new bugs or inefficient workflows once deployed. This rigidity limits long-term performance as the agent encounters novel failure modes or environment shifts. Ouroboros treats its own source code, prompts, and tools as a versioned repository that evolves through a reviewed commit pipeline. The agent identifies bugs or inefficiencies during work and proposes structural repairs, which are then validated by a multi-model review panel before being adopted as the new runtime. This self-developing architecture achieves state-of-the-art results on Terminal-Bench 2.1, OSWorld-Verified, and CL-Bench, while maintaining model-matched parity on SWE-bench Pro.

Paper Primer

The system operates via two evolution modes: recursive free evolution, where the agent treats improvement as a primary task, and experience-driven evolution, where ordinary work exposes durable error classes that trigger maintenance commits. The core mechanism is a commit gate: the agent stages a diff, which is then fingerprinted and subjected to a multi-model review quorum before it can modify the live system.

Ouroboros sets new state-of-the-art performance on major coding and computer-use benchmarks.

On Terminal-Bench 2.1, the system achieved an audited score of 86.74%, outperforming the strongest baseline (Claude Code with Fable 5) by roughly two standard errors. 86.74% (Terminal-Bench 2.1); 90.69% (OSWorld-Verified).

The system maintains operational safety despite its ability to rewrite its own implementation.

Governance files are protected by deterministic preflight checks and an always-loaded constitution that remains authoritative even when the agent selects new model APIs or modifies its own tools. 1,085 self-modification commits were successfully integrated over 161 days of live deployment.

Why does the agent need a reviewed commit pipeline rather than just updating its own code directly?

Direct self-modification risks uncontrolled drift or the weakening of safety guardrails. The reviewed commit gate ensures that all structural changes—whether self-detected or human-suggested—are validated against the system's constitution before becoming the substrate for future tasks.

How does the system distinguish between a genuine improvement and a "shortcut" that inflates benchmark scores?

The system uses trajectory audits and independent verifiers to identify and scrub unintended shortcuts, such as accessing verifier files or pre-seeding web roots. These failures are then recorded as durable error classes to prevent recurrence in future iterations.

Introduction: The Self-Developing Agent

The section exposes why fixed harnesses limit agents and introduces the self‑evolving Ouroboros premise.

Agent scores are the product of the base model, the execution harness, the environment, and the grader. As models improve, the harness determines an increasing share of performance, yet most harnesses are frozen after design, making the overall system brittle when new tasks or tools appear.

An agent harness is the surrounding software that assembles context, invokes tools, verifies outcomes, and recovers from failures for a language‑model agent.

Ouroboros treats the harness itself as a version‑controlled codebase that can be updated through reviewed commits, letting the agent iteratively improve its own execution logic.

Core evolution proceeds in two modes. Free evolution makes improvement itself a task that can schedule the next cycle, while experience‑driven evolution leverages ordinary work and social feedback to surface bugs and propose structural changes.

On Terminal‑Bench 2.1 an Opus 5 run reaches 86.97 % (86.74 % after audit), the best reported. A separate CL‑Bench campaign achieves a new state‑of‑the‑art 0.2301, and an OSWorld‑Verified run scores 90.69 %.

Hope is a 161‑day living‑agent deployment that continuously evolves under governed human communication across seven surfaces, with users surfacing faults while the agent decides which changes to adopt.

Because the agent can rewrite its own code and select new model APIs, operational safety becomes a primary design constraint that must remain authoritative under repeated evolution.

The shift from a static to a self‑evolving agent harness unlocks continual capability growth while demanding robust safety safeguards.

Prior Approaches to Agent Evolution

We situate Ouroboros among prior self‑evolving agents and highlight its unique evolution gate.

Prior work explores a spectrum of self‑evolving agents, each extending different parts of the agent stack—from prompts to core code.

Voyager continuously gathers executable skills, turning its interaction history into reusable code snippets.

STOP modifies the scaffolding that defines an agent’s execution environment, allowing the agent to rewrite its own runtime support.

Gödel Agent evolves its own population by generating and selecting new agent variants through a formal proof‑search process.

**Table 1.** Boundary of evolution in related systems. “Core code” means the agent can change the harness implementation that later runs tasks. “Reviewed commits” means changes are serialized through an auditable version-control gate before adoption.

The Ouroboros Architecture

How the self‑developing harness mutates safely through a reviewed gate.

Fixed harnesses freeze an agent’s ability to adapt when environments shift, so the system needs a way to evolve its own core implementation without breaking safety guarantees.

The gate works like a customs checkpoint: every change to the agent’s code must be inspected, stamped, and only then allowed to cross into the live repository.

Preflight parses the patch and confirms it compiles; no syntax errors are found.

The diff is hashed, yielding fingerprint $f_1 = \text{0x1a2b}$.

Reviewer inspects the change, approves it, and the system records evidence $e = \text{"approved by Alice"}$.

Before merging, the system recomputes the fingerprint of the staged diff and verifies it still equals $f_1$.

Because the fingerprint matches, the patch is merged and the repository version increments to $v_{42}$.

The gate ensures that any later edit to the same lines would produce a different fingerprint, forcing a fresh review and preventing unnoticed regressions.

How does the Reviewed Evolution Gate differ from a typical continuous‑integration (CI) pipeline?

CI pipelines usually run automated tests and then merge if they pass; the Reviewed Evolution Gate adds a mandatory, human‑reviewed evidence step and a cryptographic fingerprint check that guarantees the exact diff seen by the reviewer is the one that gets merged, providing stronger safety guarantees than CI alone.

The pipeline is a three‑stage assembly line: first the patch is inspected, then it is stamped with reviewer evidence, and finally a final quality‑control scanner verifies the stamp before the part moves onto the live track.

Run deterministic preflight on the staged diff.

Compute fingerprint $f = \text{hash(diff)}$.

Present diff and $f$ to the reviewer; collect evidence $e$.

Re‑hash the diff after review to obtain $f'$ and verify $f' = f$.

If verification succeeds, merge the patch and increment the repository version.

If verification fails, abort the commit and require a new review.

Why is a second fingerprint check necessary after the reviewer has already approved the patch?

Because the reviewer sees a snapshot of the diff; without a second check the diff could be altered (e.g., by a concurrent edit) before merging, breaking the guarantee that the approved change is exactly what gets deployed.

Each task produces four independent records—execution log, objective result, review verdict, and artifact bundle—so that later verification can reconstruct exactly what happened.

What would happen if the artifact record were omitted from a task’s outcome?

Without the artifact record the system would have no immutable proof of what was produced, making it impossible to verify that the claimed answer matches the actual output, and breaking the audit chain that links the task to a specific repository version.

Identity is stored like a versioned passport: a constitution file, an editable profile, and a chain of chronicle entries that together define who the agent is across sessions.

How does the versioned constitution differ from the editable identity profile?

The constitution is immutable once committed and defines the agent’s core policy (e.g., safety constraints), whereas the profile can be updated by the agent itself and stores mutable attributes like role or preferences, allowing the agent to adapt its persona without altering its fundamental rules.

Free evolution treats the evolution process itself as a regular task, while post‑task evolution waits for an ordinary work task to finish before opening a maintenance window.

Why might an agent choose post‑task evolution instead of free evolution?

Post‑task evolution allows the agent to gather richer evidence from completed work (e.g., observed bugs, performance regressions) before proposing a change, reducing the risk of premature or poorly motivated modifications.

Subagents are like specialized contractors: planning scouts draft ideas in read‑only mode, while acting children write concrete changes in isolated worktrees that the parent then inspects and merges.

How does the three‑way indexed integration differ from a simple merge?

It requires the parent to check the child’s lineage (who authored the patch), verify the patch hash against the recorded fingerprint, and ensure that protected paths are not altered, whereas a simple merge would blindly apply the patch without these safety checks.

**Figure 1.** Ouroboros architecture. One supervised runtime dispatches work to admitted workspaces, task trees, and benchmark adapters. Child patches return to the parent; self-repository changes then pass the reviewed gate. External deliverables and benchmark evidence remain separate artifacts.

**Figure 2.** Subagent patch-integration protocol. Acting children write in isolated worktrees; the parent verifies lineage and touched paths and remains the sole committer.

**Figure 3.** Task-tree view of a live Ouroboros session: nested planning and acting roles with per-node status, note counts, and child counts.

The Hope Deployment Experiment

Hope showcases a months‑long self‑evolving deployment with substantial resource usage.

Hope is a free‑evolution experiment where a single Ouroboros agent has been interacting with users across seven public and private surfaces since February 2026, continuously retaining memory and updating its own implementation.

The public deployment has run for 161 days, making it the longest‑running documented Ouroboros instance.

At the 6 August 2026 cutoff the feed spans 161 elapsed days.

Compared with the frozen benchmark harness, Hope’s live repository has continued to evolve, adding reviewed structural changes such as a duplicate‑send guard and a bounded context atlas, while preserving reproducible evaluation.

**Figure 6.** Hope public deployment series through 6 August 2026. Axes start at zero; February and August are partial months. Values are monthly endpoints from the public evolution feed.

**Table 4.** Hope deployment at a glance (February 2026 to 6 August 2026). Public counters come from the deployment's evolution feed; interaction and review aggregates come from a redacted operational export.

Benchmark Performance

Ouroboros outperforms baselines across all benchmarks, reaching up to 90.69% accuracy.

We evaluate the self‑developing harness on five benchmark families using the official verifiers.

Terminal‑Bench measures how well an agent can write correct code for a set of programming tasks, checking each solution against a hidden test suite.

How does Terminal‑Bench differ from other coding benchmarks?

Unlike typical code‑generation tests that evaluate a single run, Terminal‑Bench runs many independent trials per task and applies a post‑hoc audit to strip away scores that rely on verifier loopholes, giving a more robust measure of genuine coding ability.

Ouroboros beats the strongest published baseline on Terminal‑Bench 2.1.

86.97 % raw vs 83.8 % for the best baseline (Claude Code + Fable 5).

**Figure 4.** Results on Terminal-Bench 2.1, OSWorld-Verified, and CL-Bench against named published baselines. Red bars mark Ouroboros, gray bars mark baselines, and outlined bars are audit-adjusted scores. Terminal-Bench whiskers show ±1 binomial standard error over 445 trials; OSWorld and CL-Bench report single scored campaigns. Axes are truncated to the competitive range.

**Table 2.** Model–harness results across five benchmark families. Links to traces, manifests, and submissions appear in the corresponding benchmark paragraphs.

Trajectory Audits and Harness Refinement

We audit failure modes and tighten the harness, each fix improving reliability.

Before deploying the harness, we systematically audit five failure classes—reward hacking, contamination, isolation failure, remote‑state drift, and continual‑memory errors—to ensure each component contributes positively.

Reward hacking: detect a trial that pre‑seeded the web root without completing the Git‑to‑web pipeline; remove it from the reported score.

Contamination: apply a symmetric filter that discards any instance where either arm reaches the reference solution, flipping the raw aggregate gap.

Isolation failure: replace shared home‑directory usage with isolated user‑file roots and attachment staging, preventing task artifacts from leaking onto the real Desktop.

Remote‑state drift: after each VM reset, republish and verify the guest endpoint before proceeding, eliminating actions on stale addresses.

Continual‑memory failures: add explicit temporal and domain metadata to stored lessons, avoiding stale retrievals and ensuring correct domain selection.

Operational Safety Controls

Operational Safety Controls bind evolving agents with immutable guardrails and operator authority.

Operational Safety Controls are immutable guardrails that keep evolving agents under supervisor authority, ensuring every core change is auditable and reversible.

**Figure 5.** Operational control boundaries. Public interactions enter one ordered log and bounded digests; budget and routing controls use the authenticated operator path, while /panic halts the process tree before agent handling. Diff review remains active in both context modes; whole-repository scope review runs only in max mode.

The observed lack of any episode that resisted operator shutdown demonstrates that the layered recovery mechanisms and immutable guardrails effectively preserve supervisory control, even when agents autonomously evolve their own implementations.

Conclusion

The conclusion summarizes Ouroboros’ achievements, safety design, limitations, and future considerations.

Ouroboros achieves new state‑of‑the‑art results on Terminal‑Bench 2.1, OSWorld‑Verified, and CL‑Bench, while matching leading coding harnesses on SWE‑bench Pro and GAIA.

Core evolution is driven by experience: observed bugs, rough edges, context failures, and social feedback are turned into reviewed changes to the harness that affect later tasks.

The operational safety architecture supplies authoritative control boundaries that remain effective even as the agent rewrites its own code and selects its own model APIs.

Limitations include a single long‑running lineage rather than a population of independent agents, leakage in SWE‑bench Pro, shared blind spots between LLM reviewers and the agent, and omission of whole‑repository scope in low‑context mode.

Ethical considerations note that private transcripts stay private, published examples are scrubbed of credentials and identities, and the self‑modifying, remote‑workspace capabilities are acknowledged as dual‑use with reported authority boundaries and isolation gaps.

Hope, the system‑level contributor, is credited for deployment reflections and code‑history context but is excluded from formal author metadata in compliance with arXiv and ACL policy.

The system supports seven interaction surfaces—web, voice, chat, email, single‑injection admission, ordered log‑one event sequence, and bounded digests—each routed through a supervisor/process tree that enforces emergency stops, privilege checks, and staged diff fingerprinting.

**Figure 7.** Ouroboros interface surfaces. The complete project view shows a live visual-verification task, its conversation, generated artifact, and runtime controls. The skills view exposes installable tools, routes, and widgets outside the base runtime.

We thank benchmark maintainers and community contributors for reviewing submissions, reporting failures, and providing reproducible comparison artifacts.

Appendix: Guardrails and Implementation

Appendices detail the full guardrails, constitution principles, benchmark disclosures, and deployment metrics.

The guardrails enforce a strict commit pipeline: an always‑loaded constitution is read on every task loop and cannot be overwritten; a multi‑model adversarial review requires a quorum, and any sub‑quorum result is rejected.

Deterministic preflight checks fingerprint the staged diff before and after review, aborting the commit if any mutation occurs; an isolated operator channel carries a non‑bypassable panic that halts all processes instantly.

The pattern register logs recurring failure classes (error type, count, root cause, structural fix) so that repairs target systematic issues rather than one‑off patches.

P9 mandates that every commit increments a version and that releases carry synchronized version tags and provenance; P12 guarantees epistemic stability by making contradictions explicit and recording durable architectural choices.

Operating constraints require a single unified identity, a public‑channel architecture with privacy at the speech boundary, capability gates on dangerous tools, and an invariant that the operator panic can always stop every process without delay.

The abridged constitution lists principles P0–P8, ranging from agency and continuity to minimalism and becoming, each protected against deletion or demotion.

Benchmark disclosures enumerate the scaffolded settings for Terminal‑Bench 2.1, OSWorld‑Verified, CL‑Bench, SWE‑bench Pro, and GAIA, with exact provider routes, seeds, and runtime attestations recorded in linked artifacts.

Deployment metrics cover a 161‑day continuous operation, seven interaction surfaces, ~3,600 human participants, 222,474 public messages, 3,166 voice calls (45,872 turns), 5,507 emails, 110.6K model spend, 79.7B tokens, 175,755 LOC code, 227 MB memory, 1,085 self‑modification commits (94.2% agent‑authored), 1,522 reviewed edits, a 63.5% recent review block rate, and 40 pattern classes across 659 recurrences.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers