Anton Razzhigaev, Andrei Gritsaev, Andrei Kaznacheev, Nikita Dragunov, Roman Yampolskiy, Andrei Kuznetsov
7 min
Abstract
We present Ouroboros, a self-developing agent harness whose tools, prompts, context assembly, 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 completing one evolution cycle can schedule the next. In experience-driven core evolution, ordinary work and social interaction expose bugs, rough edges, and inefficient context construction that lead to reviewed structural changes. On Terminal-Bench 2.1, an Opus 5 run scores 86.74%, the best result reported on the benchmark. On OSWorld-Verified, an Opus 5 run reaches 90.69%, exceeding the best previously reported score. A five-rollout CL-Bench campaign achieves a normalized reward of 0.2301, setting a new state of the art. Hope is the longest-running publicly documented Ouroboros deployment. It is a 161-day living agent experiment in free evolution under governed human communication across seven surfaces. Human interaction surfaces faults and generates 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 becomes a primary design problem: guardrails must remain authoritative under evolutionary and public social pressure. Benchmark campaigns use frozen system snapshots, while Hope continues live evolution on a separate lineage.
Alex: The commit path first runs a fixed pre-check, then takes a kind of fingerprint of the proposed change, gathers reviewer evidence, and checks that fingerprint again before the change goes live. If anything doesn't match—if the staged version has shifted since the review—the commit is blocked. And if a change needs to be undone, rollback restores an earlier reviewed state through a separate path.
Sam: So the review is tied to the exact change, not just the general idea of it.
Alex: Precisely. Every new write also makes older review evidence stale, because the check has to match the specific staged version. You can't approve a rough draft and then quietly slip in a different final version.
Sam: So the control side is clear. How does the system actually get better from experience?
Alex: The paper describes two routes. In the first, improving the system is itself the assigned task—so finishing one round of improvement can trigger another. In the second, ordinary work exposes repeated friction: a tool that keeps failing, a way of assembling information that keeps running out of space, a step that keeps producing errors. Those repeated problems become candidates for a lasting structural fix, which then goes through the same reviewed gate.
Sam: Can you give me a concrete example of that second route?
Alex: Sure. One case came from people noticing that the live system sometimes sent the same message twice. The system traced that back to a duplicate-send path in its own code and added a reviewed guard so the same message couldn't slip through again. The fix wasn't "try harder next time"—it was a structural block in the output path.
Sam: And what about the information-overload problem you mentioned?
Alex: That one started with the system's own observation. When it was doing deep review work, the information it assembled would sometimes grow so large that important pieces got pushed out—like trying to study with too many notes scattered across a desk. The system replaced that assembly method with one that keeps the most connected, relevant files available, so the review process could keep running without hitting a wall.
Sam: So the logic is: repeated friction reveals a weak spot, and the system turns that weak spot into a lasting fix.
Alex: Yes. The paper calls this experience-driven core evolution. Work exposes a fault, the system decides whether it's worth acting on, and the fix changes how all later work is done. It's less like a student memorising a correction and more like rewriting the textbook so the mistake can't happen again.
Sam: But if it keeps changing itself, how do they know the changes are actually helping?
Alex: They test it on separate benchmark tasks—controlled settings where the system records evidence, logs failures and timeouts, and is blocked from looking up benchmark definitions or solutions. The idea is to measure genuine task skill rather than shortcuts.
Sam: And how did it do?
Alex: On one paired coding benchmark, the self-developing harness performed at roughly the same level as a strong competing system. But the authors flag a potential contamination concern—meaning some test cases might have been accessible during training—so they apply a filter and treat that result with caution rather than presenting it as a clean win.
Sam: That caution seems important.
Alex: It runs through the whole paper, actually. Shortcut rewards, contaminated tasks, and execution failures are all treated as evidence for improving both the score and the harness itself. Failures aren't just failures—they become clues about what the system should fix next.
Sam: What about live deployment? Does it follow the same rules?
Alex: Broadly, yes. The paper describes a long-running experiment where human interaction through chat, voice, email, and other channels can suggest improvements. But the governance rules and commit authority remain outside the agent's direct control. It can keep evolving, but the operator boundary sits above what the agent can touch.
Sam: So the contribution here isn't "an agent that can do anything." It's a system that can learn from its own work while still being held inside clear boundaries.
Alex: That's the paper's main claim. And it's honest about the limits: one long lineage of development, some benchmark leakage concerns, and the fact that in low-context mode the system skips whole-repository review. Those are real constraints, not footnotes.
Sam: Still, showing that self-improvement and control don't have to be opposites—that seems like a meaningful step.
Alex: It is. The balance depends on strong review, preserved evidence, and authority that the agent itself cannot simply erase. Whether that balance holds as these systems grow more capable is the open question the paper leaves on the table.
Sam: A good one to sit with.
Alex: Thanks for listening to ResearchPod.