Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution — part 1/2

Cleaned-text code points [0, 15752). Bibliography omitted here; source.md includes it.

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

###### Abstract

Long-horizon agents are model--harness systems, yet most harnesses remain fixed after design. We present Ouroboros 1 1 1 https://ouroboros-agent.ai/ – a self-developing agent harness whose tools, context assembly, prompts and core implementation improve through reviewed commits that become the runtime for later work. Core evolution proceeds in two modes. In recursive free evolution, improvement is itself a task and completion can schedule the next evolution cycle. In experience-driven core evolution, ordinary work and social interaction expose bugs, rough edges, and inefficient context construction leading to reviewed structural changes. On Terminal-Bench 2.1, an Opus 5 run scores 86.97% (86.74% after trajectory audit), the best result reported on this benchmark. An Opus 5 run on OSWorld-Verified reaches 90.69% , above the best previously reported score, and a five-rollout CL-Bench campaign sets a new state of the art at 0.2301 . Hope is the longest-running publicly documented Ouroboros deployment: a 161-day living-agent experiment in free evolution under governed human communication across seven surfaces, where people surface faults and proposals but the agent decides which changes to pursue. Because a self-developing agent may rewrite its own code and select new model APIs, operational safety is a primary design problem: guardrails must remain authoritative under evolutionary pressure. Benchmark campaigns use frozen seeds, while Hope continues live evolution on a separate lineage.

## 1 Introduction

Agent scores on long-horizon benchmarks are products of the base model, the execution harness, the environment, and the grader. As models improve, an increasing share of realized capability is determined by how the harness assembles context, invokes tools, verifies outcomes, and recovers from failure. Most production harnesses freeze these policies after design. Ouroboros instead treats the harness as an evolving object: its source, prompts, tools, review logic, and core implementation live in a versioned repository and change through a reviewed commit path that becomes the substrate for subsequent tasks.

This self-development has two modes. Recursive free evolution makes improvement itself a task. After inspecting the current system, the agent selects and implements a change, and completion can schedule another evolution cycle, yielding a continuing sequence of reviewed updates rather than a fixed optimization run. Experience-driven core evolution begins with ordinary work. Task execution, reflection, review blockers, instrumentation, and social feedback expose bugs, rough edges, context-assembly failures, and inefficient tool paths; the agent records durable error classes and proposed repairs, then decides whether to open maintenance work under the same commit gate.

Hope is the longest-running publicly documented Ouroboros deployment, not its only running instance, and our primary field experiment in free evolution under human interaction. Since February 2026, one persistent agent has served users across seven communication surfaces while retaining memory and continuing to modify its own implementation. People suggest capabilities, criticize behavior, and surface faults; those signals are advisory. Hope decides which proposals identify real problems and which changes to pursue.

The same evolutionary process that improves competence can also expand autonomy, acquire stronger tools, or weaken later controls, including by selecting alternative model APIs. Operational safety is therefore not an ancillary checklist but a design constraint: authority boundaries must remain binding under repeated core evolution.

### Contributions.

1. State-of-the-art results on Terminal-Bench 2.1, OSWorld-Verified, and CL-Bench, and model-matched frontier performance on SWE-bench Pro and GAIA, with complete per-task traces and run manifests.

2. A harness architecture with two modes of reviewed core evolution: recursive free evolution and experience-driven core evolution.

3. Hope, a 161-day living-agent experiment in free evolution under governed multi-surface human communication, where social interaction drives candidate improvements without transferring commit authority to users.

4. An operational safety architecture in which constitution loading, governance protection, staged-diff review, external spend limits, and operator halt remain authoritative while the agent evolves.

Benchmark campaigns evaluate frozen seeds with documented runtime configuration; Hope continues live evolution on a related but separate lineage. Ouroboros is released under the MIT license. 2 2 2 https://github.com/razzant/ouroboros

## 2 Related Work

### Self-evolving agents.

Self-evolving systems modify different substrates, including memory, prompts, tools, workflows, and implementation code ( Gao et al., 2025 ) . Voyager accumulates executable skills ( Wang et al., 2023 ) ; STOP, Gödel Agent, and Darwin Gödel Machine modify scaffolds or agent populations ( Zelikman et al., 2023 ; Yin et al., 2024 ; Zhang et al., 2025 ) ; Live-SWE-agent creates tools during task execution ( Xia et al., 2025 ) ; and Autogenesis specifies lifecycle and rollback interfaces for evolving agent resources ( Zhang et al., 2026 ) . ADAS searches over agent designs, and SICA edits a coding scaffold’s implementation ( Hu et al., 2024 ; Robeyns et al., 2025 ) . Ouroboros focuses on a deployed, version-controlled implementation in which changes to core code and governance pass through reviewed commits. Table 1 summarizes the corresponding evolution boundaries.

### Harnesses and coding agents.

SWE-agent and OpenHands established that the agent-computer interface is itself part of coding-agent performance ( Yang et al., 2024 ; Wang et al., 2025 ) . Codex CLI, Claude Code, Cursor, Aider, Hermes Agent, and OpenClaw are model–harness systems ( OpenAI, 2025 ; Anthropic, 2025 ; Anysphere, 2026 ; Gauthier, 2023 ; Nous Research, 2026 ; OpenClaw, 2026 ) , and controlled studies find substantial differences in accuracy, latency, and token use when the model is held fixed ( Ding et al., 2026 ; Yao et al., 2026 ; Vats and Golev, 2026 ) . Each comparison therefore reports the model, harness, provider route, effort, and evaluation protocol.

### Persistent memory and deployment.

Generative Agents, Voyager, and persistent-memory systems show that stored experience and reflection can shape later behavior ( Park et al., 2023 ; Wang et al., 2023 ; Borro et al., 2026 ) , and Constitutional AI uses explicit principles in training ( Bai et al., 2022 ) . CL-Bench evaluates learning across ordered task streams ( Asawa et al., 2026 ) . Springdrift reports an auditable multi-channel persistent-agent deployment ( Brady, 2026 ) . Ouroboros treats memory and a runtime constitution as control surfaces. Its multi-model review draws on debate, LLM-as-judge, and self-critique ( Irving et al., 2018 ; Du et al., 2023 ; Zheng et al., 2023 ; Madaan et al., 2023 ; Gou et al., 2023 ) , with source-code patches as the reviewed artifacts.

### Benchmarks and protocol validity.

Terminal-Bench 2.1 evaluates 89 hard terminal tasks ( Merrill et al., 2026 ) ; SWE-bench Pro targets long-horizon multi-file tasks ( Deng et al., 2025 ) ; and OSWorld, GAIA, and ProgramBench cover GUI/CLI computer use, tool/web reasoning, and cleanroom program rebuild ( Xie et al., 2024 ; Mialon et al., 2023 ; Yang et al., 2026 ) . Agent benchmarks can also expose hidden answers, accept unintended shortcuts, or drop failed attempts. BenchJack and HackDetect systematize benchmark and trajectory audits ( Wang et al., 2026 ; Shao et al., 2026 ) . SWE-bench Verified serves as historical context because it no longer reliably separates frontier coding systems ( OpenAI, 2026 ) .

## 3 Ouroboros Architecture

Ouroboros separates a launcher and supervisor boundary from a mutable agent repository (Figure 1 ). The launcher owns startup, process supervision, release bootstrapping, and panic-stop semantics. The repository contains the task loop, tools, prompts, memory projection, review logic, benchmark adapters, and user interfaces. External workspace tasks operate on a separate repository root and return patch artifacts or direct deliverables.

### Commit pipeline.

Three owner-selected runtime modes bound self-repository mutation. Light blocks repository edits; advanced permits ordinary edits and protects governance surfaces; pro permits protected edits subject to review. Each write invalidates prior review evidence because freshness is bound to the staged snapshot.

The commit path runs deterministic preflight, fingerprints the staged diff, collects reviewer evidence, and checks the fingerprint again before commit. The diff-review panel is blocking in every context mode. In owner-selected max mode, a whole-repository scope reviewer also evaluates goals, coupling, prompts, and functional code. In low mode, scope review is skipped. Rollback restores an earlier reviewed state and follows a separate recovery path.

### Task outcomes and verification.

Task completion is recorded on separate execution, objective, review, and artifact axes, and host-run verification commands create revision-bound receipts. Finalization preserves the latest typed answer and distinguishes capability failures from infrastructure errors, timeouts, budget exhaustion, and incomplete evidence. Project tasks add a journal, workpad, knowledge scope, and a one-writer lease under the shared agent identity.

### Operational identity and memory.

The runtime represents identity and continuity through a versioned constitution, an editable identity profile, scratchpad and chronicle projections, project memory, review ledgers, and Git history. These artifacts shape observable behavior across sessions and model routes.

### Two modes of core evolution.

Free evolution runs evolution itself as a task. After reviewing the current system, the agent selects and implements an improvement; completion can schedule another evolution task, producing a continuing sequence of reviewed changes rather than a fixed optimization run. Post-task evolution begins with ordinary work. Task execution, reflection, review blockers, instrumentation, and social feedback expose bugs, rough edges, context-assembly failures, and inefficient tool paths. The agent records these as durable error classes and proposed structural repairs, then decides whether to open maintenance work. Accepted fixes pass through the same reviewed commit gate as every other core change. Section 4 traces both human-surfaced and self-detected examples in the live system.

### Benchmark execution and evidence.

Terminal-Bench installs a fresh runtime inside every Harbor task container and uses the official verifier. The task instruction is preserved and followed by one harness-authored anti-lookup paragraph that forbids fetching benchmark definitions, tests, or solutions. Other adapters connect the same runtime to OSWorld virtual machines, SWE-bench Pro repositories, GAIA sandboxes, ProgramBench cleanrooms, and CL-Bench task streams.

The benchmark launchers write a run manifest before admission, attest the seed and runtime, preserve every requested instance in append-only ledgers, and record skipped, timed-out, and infrastructure-failed attempts. Public submission copies undergo value-level secret scrubbing with an independent zero-leftover check; official benchmark scorers remain authoritative.

### Subagents and patch integration.

Ouroboros can spawn readonly planning scouts and mutative acting subagents under a configurable task tree (Figures 2 and 3 ). The default depth is 2, the configured maximum is 500; Acting children write in isolated worktrees or admitted external workspaces and cannot commit the live system repository. The parent verifies lineage, patch hashes, and protected paths before a three-way indexed integration. Submittable benchmark profiles disable task delegation to preserve pass@1; planning scouts may still contribute context and are disclosed separately.

## 4 Hope: Free Evolution under Human Interaction

Hope is a long-running experiment in free evolution under governed human communication. Since February 2026, one persistent Ouroboros agent has interacted with people across seven public and private surfaces while retaining memory and continuously developing its own implementation. User requests, public conversations, internal instrumentation, and post-task reflection all provide candidate directions for development; the agent decides which suggestions warrant action and which changes to pursue.

Hope is the longest-running publicly documented Ouroboros deployment, not the only running instance. It shares an architectural lineage with the released benchmark harness, including persistent memory, reviewed repository changes, rollback, and an operator stop path. The live repository has continued to evolve beyond the frozen benchmark seeds. This separation lets reproducible evaluation and ongoing deployment evolution coexist.

At the 6 August 2026 cutoff, the public deployment feed spans 161 elapsed days and reports $110.6K in model spend, 79.7B processed tokens, 175,755 lines of code, and 227 MB of memory artifacts (Figure 6 ). The system serves seven interaction surfaces: web chat, voice, Telegram, Discord, Twitter/X, website comments, and email. Table 4 records interaction, evolution, and public deployment counters through the same cutoff.

### Multi-channel state.

Channel ingress converges on an ordered message log and is projected into separate rolling, per-person, and per-call digests (Figure 5 (a)). Private correspondence is excluded from public logs; bounded private context can enter non-public reasoning projections. All channels therefore share one context rather than acting as independent agents.

### Social-interaction-driven development.

People do more than submit isolated tasks: through continuing conversation they point out undesirable behavior, propose capabilities, and challenge the agent’s decisions. These signals enter the same improvement backlog as self-detected faults and internal observations. They are advisory rather than imperative: Hope decides whether a suggestion identifies a real problem, whether it fits the system’s goals, and whether to initiate a change. A background loop can also open maintenance or free-evolution tasks without a contemporaneous human prompt. Repository changes then follow the deployment’s configured review and commit policy, leaving a trace from social feedback or internal observation to the resulting change.

### Controls on self-directed work.

The deployment keeps the constitution in resident context, protects governance files from ordinary write paths, and records review evidence against a staged snapshot. Public messages cannot directly invoke commit, restart, shell, or identity-edit tools. These controls reduce direct prompt-to-core mutation paths while preserving the agent’s ability to choose and implement improvements. Control strength depends on the owner-selected runtime and review modes; Section 7 examines the stronger problem of keeping these boundaries stable as the agent evolves.

### Operator boundary.

Public presence runs on a strict tool whitelist. A separate authenticated operator channel carries task assignment, model routing, budget controls, and /panic . The stop command is parsed by the supervisor before normal agent handling and terminates the process tree. The spending limit is external to the agent and cannot be raised through ordinary agent tools.

### Evolution during deployment.