How AI agent self-improvement enhances results and saves tokens

When an AI Agent Learns from Its Own Mistakes

An AI agent can perform noticeably better after changing a few prompts, the order in which it calls tools, its memory, and its context-management rules. The model’s weights can remain exactly the same.

This external harness determines whether the agent reads the right file before editing it, notices a command error, recovers from a failure, and manages to finish a long task. As a result, automatically improving the harness has become a research area in its own right.

But there is a trap. If a system evaluates changes repeatedly on the same task set, it starts adapting to that set. Its results improve on familiar examples, while the gains disappear on new tasks.

The paper RRSI: “Regularized Recursive Self-Improvement of the Harness” proposes a way to keep this kind of self-improvement from turning into memorization. The idea is simple: allow any part of the harness to change, but limit how the system proposes and accepts those changes.

The Harness Matters More Than It Seems

The authors treat an AI agent as a combination of two parts:

The harness includes:

This kind of system resembles a program that can be improved based on how it performs on tasks. The model remains frozen while the external layer changes gradually.

A typical cycle looks like this:

1. the agent solves tasks from a development set;

2. another model analyzes its mistakes and proposes changes;

3. new versions of the harness run on the same tasks;

4. the best-performing version becomes the new version.

The problem appears in step 3. The same task set is used over and over. The system gets many chances to discover spurious patterns, exploit quirks in the wording, and accumulate task-specific workarounds.

That creates a gap between performance on familiar tasks and transfer to new ones.

Comparison of conventional harness evolution and RRSI: gains on familiar tasks do not guarantee improvement on new ones.

The paper’s graph makes this especially clear. Conventional methods often achieve a substantial improvement on the set used for development, but retain only a small portion of that gain outside it. Some versions even perform worse after development than the original harness.

What Is RRSI?

RRSI stands for Regularized Recursive Self-Improvement of the Harness. Here, “regularization” means a set of constraints that prevents the system from memorizing development tasks and growing uncontrollably complex.

The authors divide the mechanism into two parts:

The space of possible edits remains open. Prompts, action sequences, memory, tools, and context management can all be changed. RRSI does not ban specific components. Instead, it limits how the search budget is used.

RRSI schematic: constraints apply both when changes are proposed and when they are finally selected.

Proposing Changes

At the beginning of the search, the system may combine several edits. This helps it discover new mechanisms that work. The permitted number of changes is then gradually reduced.

In the final rounds, a candidate usually contains one small edit. That makes it easier to understand what actually affected the result.

RRSI also keeps a history of every attempt. For each edit, it records:

If a particular approach has failed several times, the system treats that as negative evidence. It should not keep rewriting the same prompt indefinitely in the hope of a lucky hit.

There is also an exploration mechanism. If several consecutive rounds fail to produce gains above the level of random noise, part of the budget is redirected to components that have not yet been tested. For example, the system may stop changing instructions and try memory management or tool-error handling instead.

Selecting Changes

Even a strong result on one task set does not prove that an edit is useful. RRSI therefore adds several filters.

Leakage checks. The critic rejects changes that directly hard-code task names, specific values, answers, or other features of the development set. It also removes inert code that does nothing but increase complexity.

Noise protection. Before development begins, the original harness is run several times on the same tasks. This estimates the natural variation in its results. A new version cannot gradually deteriorate if each small decline looks like random fluctuation.

Cost control. Any additional model tokens must be justified by an improvement in quality. If a new version becomes significantly more expensive without improving much, it is rejected.

Removing useless components. If a component produces no positive effect for several rounds, the system proposes removing it. This matters because conventional evolution is good at adding instructions and procedures, but rarely has any incentive to get rid of accumulated baggage.

How the Method Was Tested

The authors ran experiments in three areas:

Eight benchmarks were used in total. The harness was developed on one set and then run unchanged on others.

For programming tasks, the agent worked with a terminal and containers. Its results were checked with hidden unit tests. In professional tasks, the agent created documents, spreadsheets, and other files. In engineering tasks, solutions were evaluated by simulators and test rigs.

The last type of evaluation is particularly useful. There is no language-model judge that might favor a more convincing description. A design either satisfies the physical and technical constraints or it does not.

The base model was Claude Opus 4.8. Additional experiments used Gemini 3.5 Flash, and the final harness was evaluated on Gemini 3.1 Flash Lite.

Key Results

RRSI does not always achieve the best result on the set used for development. That is precisely the point of the approach: it is willing to sacrifice some local improvement in exchange for better transfer.

On tasks that were not part of development, the results changed as follows:

None of the held-out sets showed a decline.

Key RRSI results in programming, professional tasks, and engineering design.

On professional tasks, the original harness averaged 39.7 points across the external benchmarks. Conventional evolution raised that result to 40.3. RRSI raised it to 43.6.

On the development set, however, conventional evolution reached 92.8 points, while RRSI reached 90.5. Looking only at one familiar sample, the conventional method appears better. On new tasks, though, it almost falls back to the original level.

Component Analysis

The authors disabled groups of constraints separately.

When candidate-selection constraints were removed, performance on external tasks fell from 43.6 to 41.0. The cost of running the system also rose substantially.

When candidate-proposal constraints were removed, the external result fell to 41.9. The local result barely changed. This shows that the direction of the search affects transfer, even when the difference is barely visible on the original set.

Without either group of constraints, the system scored 92.8 on familiar tasks but only 40.3 on new ones. The average cost per attempt reached 3.80 million tokens, compared with 2.42 million for RRSI.

Fewer Computations, Better Transfer

Conventional evolution often makes the harness larger. It adds extra checks, reminders, instructions, and reasoning steps. Sometimes that improves quality, but it also increases the cost of every run.

RRSI limits this growth. The final harness uses roughly 30% fewer model tokens than unconstrained evolution.

Comparison of the cost of the final harnesses and their performance on external benchmarks.

The original harness is still the cheapest. It costs about 1.56 million tokens per attempt, compared with 2.42 million for RRSI. In other words, improvement is not free: the agent uses more compute, but RRSI keeps the price of that improvement under control.

In one comparison, another method used 3.82 million tokens per attempt—58% more than RRSI—while scoring 4.4 points lower on external tasks.

Transfer Between Models

One interesting result concerns the base model itself. A harness created with Gemini 3.5 Flash also improved performance on Gemini 3.1 Flash Lite, which was not involved in the search.

On Terminal-Bench 2.1, the smaller model’s score rose from 11.2 to 14.6. The absolute gain is modest, but the mechanism survived the model switch.

This suggests that RRSI can discover general procedures: checking results, recovering from errors, and using tools more carefully. These changes relate to the agent’s overall behavior rather than to the quirks of a single language model.

What Remains Unresolved

The method still depends on the development task set. If the set is small, repetitive, or a poor measure of quality, regularization will not eliminate the problem entirely.

RRSI has several parameters: the edit-budget size, the window used to remove components, the permissible cost increase, and the noise level. The authors tune them only on the development set, but other environments may require these values to be validated again.

The study also covers only the harness. The model’s weights do not change. It is unclear how the same constraints would behave if the model itself, the memory, and the toolset were all evolving at once.

Finally, the experiments cover relatively short cycles. Long-term self-improvement on constantly changing tasks will require additional testing.

Conclusion

Automatically improving a harness can easily turn into overfitting to a familiar benchmark. A high score on development tasks does not necessarily mean that an AI agent has become more useful in real work.

The goal should not be to restrict which edits are allowed, but how changes are searched for and made permanent.

To achieve this, the system:

The result is a smaller local gain, but better transfer to new tasks. For AI agents, this means moving from accumulating prompts to more controlled improvement of the software system around the model.