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: Welcome to another episode of ResearchPod.
Sam: So what are we looking at today?
Alex: A paper about a coding agent that can improve its own working setup over time, rather than staying frozen after it's launched. The central question is how to let that happen without losing control of what the system does.
Sam: So it's not just the model itself getting better—it's the whole environment around it?
Alex: Exactly. Think of it like the difference between a capable student and a messy desk. The student might be talented, but if the workspace is disorganised, the instructions are unclear, or the tools are broken, they'll still waste time and make mistakes. The paper argues that the workspace itself—what the authors call the harness—should be allowed to improve alongside the agent.
Sam: What's actually in the harness?
Alex: It can include the task loop, the tools the agent uses, the instructions it works from, how it gathers and organises information, the review logic, and even the core code. Basically, everything around the model that shapes how it operates in practice.
Sam: And all of that can be changed?
Alex: Yes, but only through a controlled path. Changes don't go straight into the live system. They pass through a version-control gate—think of it like submitting a pull request in software development—where the edit is recorded, checked, and approved before it becomes part of future work. The system can evolve, but every change stays auditable and reversible.
Sam: So the system is changing itself, but only through a process it can't simply bypass.
Alex: Right. And the paper is careful about what can be changed at all. The owner can set different runtime modes that limit the scope of edits. One mode blocks any changes to the repository entirely. Another allows ordinary edits but protects the governance files—the rules that keep the system safe. A third allows even those protected files to be edited, but only if a human reviewer approves them first.
Sam: Why does protecting those governance files matter so much?
Alex: Because self-modification creates a second problem beyond task performance. If the same process that improves the system can also rewrite its own rules, then the rules stop meaning anything. The paper's position is that the safety boundaries have to stay more authoritative than any change the agent can make. So the most sensitive files are simply unreachable through ordinary write tools.
Sam: That makes sense. How does the review process actually work in practice?
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.