In an agent, what the model actually does is narrower than it sounds. It only proposes what to say next and which tool to call. Turning that proposal into real action is the job of the software wrapped around the model. That software decides what information the model gets to see, which tools it uses in what order, and when to stop. We call this the harness. Keep the model identical but swap the harness, and the agent behaves like a completely different thing.
So there are only two ways to make an agent smarter: retrain the model itself, or fix the harness around it. This paper digs only into the second. It gives a formal definition of a process in which the prompts, memory, workflow, and execution code — never the model weights — correct themselves by looking at execution results, and then hand that corrected version straight to the next run.
The striking part is that tuning the harness alone can be enough for a small model to pull ahead of a large one. But where the paper really puts in the work is the opposite concern. When a system keeps correcting itself, it becomes hard to tell whether a correction is a genuine improvement or just something cleverly fitted to that one evaluation problem. A correction that looks good may in fact be quietly breaking something that used to work. How do you filter out that illusion — that is the question this piece carries all the way through.
Let me set expectations up front: this is not the kind of paper that builds a new system and sweeps the benchmarks. It is a 66-page synthesis that defines the field of the "self-evolving harness," taxonomizes scattered methods, and derives reliability conditions through PAC learning (a statistical learning theory that aims to guarantee, with high probability and from few samples, that something will hold on unseen data). Even the experimental numbers that appear later were not run by the authors themselves; they are examples borrowed from prior work and attached for illustration. The numbers should be read as "this was observed in one case," not as the paper's own results. The authors call the field "harness RSI" (recursive self-improvement), yet they explicitly note that the word "improvement" in the name does not presume every correction helps.
An agent does not freeze once it is deployed. The work it handles shifts, the environment shifts, the evaluation criteria shift. There is no guarantee that the prompt and workflow you designed on day one are still the best three months later. This is where the options for adaptation split.
One road touches the model weights again. Performance may rise, but you pay the retraining cost, checkpoints pile up, and it gets hard to trace why the model changed. For a model sitting behind a commercial API, weight access is blocked outright. The other road fixes the harness. What actually shapes the behavior of a fixed model is, in the end, the harness; you reuse the existing deployment as-is, so there is no retraining and no checkpoints. Above all, instructions, memory, and code are things a human can open and read, compare across versions, and track changes in. That is unlike a weight diff.
The road itself is not new. It has two roots. One is EURISKO, which revised its own rules based on experience. The other is the Gödel Machine, which rewrote its own code only when a gain could be proven. Today's methods — the Reflexion, ExpeL, Voyager, AFlow, GEPA, Promptbreeder lineage — mostly lean toward the former. They fix prompts from experiential feedback, consolidate memory, and search over workflows. They are flexible. But that very flexibility leaves a gap: there is no way to guarantee whether an experience-driven correction is a real improvement or a lucky hit. And demanding a proof for every correction (the Gödel Machine side) leaves a real-world agent unable to take a single step.
On top of that, every method differed in what it fixed, how it generated candidates, and on what grounds it accepted them. So this paper first builds a common language, and then tries to fill the missing reliability guarantee with "statistical assurance" instead of "proof." It keeps the flexibility of experience, but draws a line against accepting just any correction.
A single scene is faster than any description. Suppose an agent, running a spreadsheet task, skips the output-check step and produces a wrong result. That failure becomes feedback. The party in charge of updates diagnoses the cause ("there is no output-check step"), proposes a fix (add a check step), evaluates it on new data, and adopts it if it got better. The adopted fix is stored and loaded into the next run. If there is no acceptable fix, the existing harness is left untouched.
That is one cycle. The current harness performs multiple rollouts, gathering the trajectory, outcome, and feedback for each; an update operator bundles together diagnosis, proposal, evaluation, and adoption; and the adopted version carries over to the next cycle. Only when two conditions hold — that corrections are generated from the system's own execution feedback and that mechanism keeps running, and that the adopted version is inherited by the next run — do we call it "harness self-evolution." Appending logs or compressing context by fixed rules does not count. That is not learning for itself; it just runs as prescribed.
The harness itself decomposes into seven runtime functions, but rather than memorizing them, it is enough to hold them in three bundles.
What self-evolution touches is, in the end, somewhere in these three.
The paper splits "what you fix" into two branches. One is interpreted state — task-level adjustments that run on top of instructions, stored experience, and a fixed set of capabilities. The other is executable revision — changing the implementation of a capability itself, the repository-level control logic, the service configuration bound as a plugin.
By analogy, the former is rewriting the recipe card you hand to the cook, and the latter is tearing out and rebuilding the kitchen's equipment and plumbing. The one thing this analogy conveys: are you changing the instruction, or changing the apparatus that executes the instruction? The criterion is not what language the edited file is written in, but the role that artifact plays in the system. The same workflow change is an interpreted revision if it only reorders steps on top of a fixed interface, and an executable revision if it touches the runtime mechanism that actually enforces that ordering.
One thing must be kept clearly separate. The kind of a revision and its blast radius are not the same thing. Fixing a single recipe card can still ripple across every branch if that recipe is shared among many stores. Blast radius has to be judged separately, by looking at whether the revision is shared and where it applies. It is true that executable revisions tend to ripple further, but there is no guarantee that interpreted revisions stay narrow.
The spine of this paper is theory. But you do not need to memorize the theory by name. Grab one principle and the rest follows.
The principle is this. Keep revising while looking at the same evaluation problem, and the revision gets fitted more and more to that one problem. It is like seeing the exam in advance and studying to that exam paper alone. So the acceptance decision must be made not on the data used to make the revision, but on fresh, independent validation data you never touched. You accept only when improvement is confirmed there too, with high probability — this is the "high-probability acceptance rule." It is the net that filters out revisions that only look good on the evaluation data.
The second is the regression budget. Regression means a capability that used to work quietly breaking. As revisions stack up one by one, this breakage stacks too. So you decide in advance a ceiling on how much existing capability may degrade, and only accept revisions within that ceiling. For instance, if accuracy on a new task went up but part of what used to work on an existing task broke, then the moment that breakage exceeds the preset ceiling, you hold the revision back. The mere fact that the new performance improved is not grounds for adoption. The retention bound only carries meaning when exactly this cumulative regression is kept within budget. On top of this — an expected generalization bound under explicitly stated assumptions — these three results are derived by mapping candidate search onto evolutionary optimization (a search that generates many candidates and keeps only the good ones to carry into the next generation).
Finally, one design principle. A candidate harness may revise an internal critic or an intermediate check, but it must be barred from touching the evaluator that does the final scoring and validation. The hand holding the answer key must not belong to the test-taker. Without this isolation, the two nets above are rendered useless wholesale.
Now for the numbers — but, as said, these are not the authors' own experiments; they are cases borrowed from prior work. It pays to watch especially carefully which study and which condition each number comes from.
The first case is HarnessOpt on SpreadsheetBench (a spreadsheet-task benchmark). It extends SkillOpt-Lite, which had stopped at skill editing, into runtime revision, improving spreadsheet preview, output checking, and recovery after a tool failure. The figures, converted from the ratios in the prior work (shen2026skilloptlite), appear in the paper's Table 2.
| Model | Initial | SkillOpt | SkillOpt-Lite | HO only | HO + skill |
|---|---|---|---|---|---|
| GPT-5.4-nano | 29.89 | 51.60 | 66.19 | 76.51 | 77.58 |
| GPT-5.4-mini | 28.21 | 47.50 | 73.31 | 81.14 | 82.56 |
| GPT-5.4 | 39.86 | 61.50 | 79.36 | 83.63 | 85.05 |
| GPT-5.5 | 37.37 | 76.20 | 79.72 | 83.63 | 85.77 |
Here is the scene from the top of this piece. The smallest model, GPT-5.4-nano, with HarnessOpt plus skills (77.58%), edges out the larger GPT-5.5 with only SkillOpt (76.20%). Across all four models, HarnessOpt+skill was 5.69–11.39 percentage points higher than SkillOpt-Lite. Putting a good harness on a small model can beat putting a weak harness on a large one — a sign that the match between model and harness divides the outcome as much as model size does.
That said, this crossover does not mean "an edge at equal cost." Even if the small model won, this is not a comparison that also matches the compute spent on optimizing the harness. What this number measures is accuracy under a specific condition, not efficiency per unit of cost.
The second case is "Everything Is a Plugin" (EIP). A Codex plugin builds the tools it needs mid-execution and reuses them on later tasks. In a simulated office workload, the per-region spreadsheets differed in language and content but called for similar calculations, and Codex produced batch-lookup and summarization tools. Thanks to that, the tool calls on the first task dropped from 13 to 3. In exchange, building the tools made the first task cost more tokens and time — an upfront investment, in effect. That investment is recouped from the second task on, and once you accumulate five tasks it tips over into saving tokens and time. The authors do note, however, that the numbers for the first-task tally and the cumulative tally are inconsistent with each other, so the two cannot be stitched into a single cost trajectory.[^1] The upfront cost of building tools and the later reuse gain are the core, and the caveat that the two cannot be drawn as one line is as much as you should take from this case.
ONTLE is a service that attaches AI to small businesses and solo founders — the ones who can't hire enough and watch repetitive work pile up — so the AI handles that repetitive work for them. Let us follow one scene to the end (this is an application scenario, not actual operation).
ONTLE's AI PM handles "writing the weekly progress report" for several client companies. When feedback comes back from Company A that "the report is too long," the PM revises the report-template prompt to "three key lines + a risk section." In the paper's terms, that is an interpreted-state revision. Go a step further — build a new lookup tool that scrapes progress data and slot it into the report-generation pipeline — and that is an executable revision, and closer to plugin configuration at that.
What this paper changes is when you trust that revision enough to spread it to other clients. The revision made from Company A's feedback must pass validation not on the very data used at Company A, but on a different, untouched week's worth of data, before it is adopted. And before handing it to Company B, you check — within the regression budget — that the revision does not shave down Company B's existing report quality. A template shortened to fit Company A may, at Company B where regulatory reporting matters, be a regression that drops a mandatory item.
So what this case leaves behind is not the conclusion "ONTLE does it well," but the design questions you have to solve right now. For each client, who defines the "mandatory items you must not drop," and who evaluates them? Where do you draw the line between a revision to a shared common template used by all clients and a revision that applies to one client only? When evaluation criteria differ by client, how do you secure "fresh, independent validation data" at each site? Only an organization with answers to these questions can actually turn self-evolution on.
The achievement of this paper is in the framework, not in any particular score. It separates scattered methods along two axes — "what gets fixed (the update target)" and "how it is proposed and accepted" — and it takes on, via statistical assurance, the point that experiential choice alone guarantees neither generalization nor retention.
The limits sit in the same place. The theoretical bounds all hold only under explicitly stated assumptions, and the experiments are cases borrowed from prior work, not results this framework reproduced under controlled conditions. The SpreadsheetBench crossover is not an edge at equal cost, and the EIP cost reporting carries the inconsistency seen above. And in an environment where the evaluator's distribution keeps shifting, steadily securing fresh, independent validation data is itself no small homework. The credit for erecting the framework is large; how much predictive power that framework has in real deployment is left to follow-up empirical work.
When you take it to practice, this checklist is all of it.
No. Self-evolution refers to the case where the system generates revisions by itself from its own execution feedback, that revision mechanism keeps running, and the adopted version carries over to the next run. A human fixing things directly is a different activity. That said, even when a human does the fixing, the principles — decide acceptance on fresh validation data and manage a regression budget — apply exactly the same.
The idea is similar, in that it is a structure of generating many candidates, evaluating them, keeping only the good ones, and carrying them into the next generation. The paper pulls classical statistical results like stability and concentration inequalities into this structure to derive its bounds. The key is not the name of an algorithm but that the frame of "evaluate many candidates and pick" is a shape onto which statistical assurance can be layered.
Blocked weight access is just one of several reasons to choose the harness. Even when you can open them, the advantages remain: no retraining cost, and changes a human can read and compare across versions. In an operational setting where you have to trace where and why something changed, fixing the harness is often easier to handle even if you can open the weights.
The paper only assigns the role: "manage it with a budget." How large to set the allowable degradation is not derived as a number; it is a policy judgment the organization makes according to the business risk if that capability breaks. It is natural to set it differently per task — tight for an area like regulatory reporting where a missing item is fatal, loose for an area with slack like an internal memo.
[^1]: First task: tool calls 13→3, tokens 41,119→47,572, wall clock 15.49→24.00 seconds (tokens +15.7%, time +54.9%). Over five accumulated tasks it is reported as saving 110,351 tokens and 22.97 seconds. However, the increase implied by the first task (6,453 tokens, 8.51 seconds) and the first row of the cumulative tally (4,895 tokens, 6.74 seconds) are inconsistent, so the two reports cannot be merged into a single cost trajectory.