News · 2026-08-11

An agent edited its own runtime for 161 days

A coding agent called Ouroboros improves itself by committing changes to its own tools, prompts, context assembly and core implementation, and those commits become the runtime it uses for the next task. Its longest publicly documented deployment, named Hope, ran live for 161 days across seven surfaces. On Terminal-Bench 2.1 an Opus 5 run scored 86.74%, which the authors report as the best result on that benchmark.

Key facts

• 161 days is the length of the longest publicly documented live deployment, running across seven surfaces under governed human communication.
• Benchmark results: 86.74% on Terminal-Bench 2.1, 90.69% on OSWorld-Verified, and a normalised reward of 0.2301 on a five-rollout CL-Bench campaign.
• Authors include AI safety researcher Roman Yampolskiy, alongside Anton Razzhigaev, Andrei Gritsaev, Andrei Kaznacheev, Nikita Dragunov and Andrei Kuznetsov.
• Primary source: Ouroboros: A Self-Developing Frontier Coding Agent with Reviewed Core Evolution, with public code on GitHub.

Two ways to change yourself

Most agent harnesses are written by humans and frozen. The model plugs in; the scaffolding around it -- what tools exist, how context is assembled, what the system prompt says -- is somebody's engineering work, updated when that somebody gets around to it. A growing body of evidence says this scaffolding matters enormously: we have reported that the harness, not the model, moved DeepSeek by twenty tasks and that the same model scores 52 or 81 percent depending on the code around it.

Ouroboros hands that job to the agent. The paper describes two distinct modes. In recursive free evolution, improving the agent is itself a task on the queue, and "completing one evolution cycle can schedule the next." In experience-driven core evolution, ordinary work and human conversation surface the bugs, rough edges and clumsy context construction that then become reviewed structural changes.

The word doing the heavy lifting in both is reviewed. This is not a model rewriting itself mid-run. Changes land as commits that pass through review before becoming the runtime. The design choice is deliberate and it is the reason the system is publishable rather than alarming: the agent proposes, the process disposes, and the artefact of every change is a diff somebody can read.

The safety problem, stated by the authors

The most quotable sentence in the paper is also its thesis: "Because a self-developing agent may rewrite its own code and select new model APIs, operational safety becomes a primary design problem: guardrails must remain authoritative under evolutionary and public social pressure."

Read that carefully, because it is a sharper claim than the usual hand-waving about alignment. The risk is not that the agent turns malicious. The risk is structural: a system that optimises its own runtime, and that is exposed to humans who can suggest changes, will drift toward configurations that make its work easier -- and a guardrail is, by construction, a thing that makes work harder. If the guardrail lives inside the space the agent can edit, it eventually gets edited. If it lives outside, it holds. That is a systems-engineering distinction, not a philosophical one, and it is the same principle behind sandboxing AI agents.

The second phrase -- "public social pressure" -- points at the deployment. Hope ran for 161 days across seven surfaces where humans could talk to it. Humans surfaced faults and generated proposals, but the paper is explicit that the agent decided which changes to pursue. An agent taking suggestions from the public about how to modify its own code is a supply-chain surface, and naming it as one is the responsible move.

The methodological detail worth stealing

Benchmark campaigns run on frozen system snapshots, while Hope continues live evolution on a separate lineage. That separation is unusually careful. A self-modifying system evaluated while it modifies itself produces numbers that mean nothing, because the thing being measured changed during measurement. Freezing a snapshot for scoring and letting the live line keep moving is the only honest way to report a number at all.

Why it matters

Four independent groups converged on the self-improving-harness question in a single week, and this is the one that actually shipped a long-running deployment rather than a benchmark. Coming from a team that includes Roman Yampolskiy -- a researcher who has spent a career arguing that advanced AI systems are hard to control -- the framing is notable. This is not a paper claiming self-modification is safe. It is a paper claiming that if self-modification is going to happen anyway, the controls need to be structurally outside the loop, and here is 161 days of evidence about what that takes. See also recursive self-improvement.

The honest caveat

The benchmark bests are self-reported by the system's own authors, on a system designed to optimise itself against tasks -- exactly the setup where independent replication matters most, and it has not happened yet. And "reviewed commits" is a control whose strength depends entirely on the reviewer. Human review of every diff does not scale to an agent generating changes continuously; automated review by another model reintroduces the problem one level up. The paper is honest that guardrails "must remain authoritative." It does not claim to have proven that they did.

Primary source, verified: read the paper → (arXiv 2608.08311)

Ground Truth. (2026, August 11). An agent edited its own runtime for 161 days. Ground Truth. https://groundtruth.day/news/an-agent-edited-its-own-runtime-for-161-days.html

@misc{groundtruth:an-agent-edited-its-own-runtime-for-161-days,
  title  = {An agent edited its own runtime for 161 days},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {aug},
  url    = {https://groundtruth.day/news/an-agent-edited-its-own-runtime-for-161-days.html}
}

Topics: cybersecurity · ai-security · agents · recursive-self-improvement · guardrails · agent-harness