How an AI agent changes without retraining the model

An AI Agent Learns to Change Its Own Harness

Once deployed, an AI agent continues operating in a changing world. Tasks, tools, and environmental rules may shift, while the model itself usually stays the same. Researchers propose a different way for agents to adapt: let them modify their own harness—their prompts, memory, workflows, tools, and parts of their code.

Changes persist between runs. The agent gets feedback, proposes edits, tests them, and uses those that pass evaluation on future tasks. This lets it build up procedures and improve how it works without changing the model’s weights.

The authors call this approach harness self-evolution. They examine which parts of a system can be changed, how to evaluate proposed edits, and why improvement on past tasks alone is not enough to establish that a new version is reliable.

How a harness evolves from a collection of instructions and procedures into modifiable executable components.

What Changes

A harness is the software environment that manages how a model operates. It builds context, calls tools, stores memory, assigns tasks, and decides when to stop. The model generates responses; the harness determines how that capability is put to use.

Harness self-evolution starts with experience from performing tasks. The agent collects results and feedback, looks for possible changes, evaluates them, and decides whether to keep them. An accepted version is loaded on the next run, while the update process continues.

The authors distinguish between two kinds of changes:

🟠 State changes: The agent updates prompts, memory entries, or the order of operations while staying within a predefined set of tools and capabilities.

🟠 Executable-component changes: The agent modifies tool code, control logic, error-recovery rules, or the way services are connected.

For example, adding the instruction “check the column names before processing a spreadsheet” changes stored instructions. Rewriting the tool that reads the spreadsheet changes an executable component. Changing the logic that assigns work across multiple agents affects the system’s overall control.

This distinction matters for oversight. If only memory changes, the effects are usually easier to check. But if an agent can modify shared control code or connect new components, a mistake could affect many tasks.

Two conditions must be met for a system to count as self-evolving. It must use feedback from its own runs to choose changes, and accepted changes must persist and be applied later. Simply accumulating logs does not qualify: the system has to change a reusable part of how it works.

From a Single Edit to a New Architecture

The article describes three levels of change. At the first, an agent edits individual skills and tools. The boundaries are usually set in advance: for example, it may change how a function is implemented but not touch the rest of the system. This approach is easier to check, but even a local change can affect other components that rely on its outputs.

At the second level, the agent can change code across the whole project: its operating loop, context assembly, task scheduling, error recovery, and stopping rules. This offers more freedom but also raises the risk. A new memory system, for instance, could change the context available to tools that were not themselves modified.

The third approach is built around pluggable components. An agent can create and connect tools at runtime, provided they meet specified interfaces. An interface can help establish that a component is compatible with the system, but it does not prove that the component behaves safely. The whole system’s output must be checked, not just each component in isolation.

One example in the article involves processing office spreadsheets. For recurring tasks, the agent creates tools for batch searches and summaries. On the first task, the number of tool calls drops from 13 to 3. But the costs initially rise: processing takes 24 seconds instead of 15.49, and token usage increases from 41,119 to 47,572. The savings emerge on later tasks: after five tasks, the cumulative results show a reduction of 110,351 tokens and 22.97 seconds.

The authors note that the figures for the first task and the cumulative results do not fully align, so they should not be combined into a single running cost estimate. The key point is that creating a reusable tool can pay off over time, even if the first task costs more.

When Does an Improvement Really Work?

A change that helps on familiar examples may fail on new ones. That is why the authors frame harness self-evolution as a search followed by evaluation. Ideas from evolutionary optimization can guide the search: the system generates several candidates, compares them, and keeps the most promising.

But selecting candidates based on past tasks creates a risk of overfitting. A harness may learn to perform well on the examples used to improve it, while doing worse on others. Separate evaluation data is needed to measure how well changes transfer to new tasks.

The authors draw on ideas from machine-learning theory. In particular, they discuss the conditions under which a successful harness version can be expected to work on new examples, and how to prevent accumulated improvements from causing too many errors. These estimates depend on assumptions about the training process and the data; the equations alone do not guarantee that any self-updating system will be reliable.

One practical rule from the article is to test each candidate on fresh, independent examples that were not used to develop the change. If the new version passes this evaluation at the required error rate, it can be approved for use. The evaluation must be independent both of candidate generation and of the data used to select candidates.

The problem does not go away after deployment. Tasks, environments, and ways of evaluating results all change. That means testing must be repeated: a version that is reliable today may no longer be suitable tomorrow.

What the Approach Offers—and What It Doesn’t Solve

Changing a harness is easier than retraining a model. Prompts, memory, and the code around a model can be updated without creating a new set of weights. This is especially useful when a model is available only through an API or its weights cannot be changed. Edits to code and prompts are also easier to compare and evaluate than changes to the model’s internal parameters.

Transparency is not the same as safety. If an agent can change its tools and execution logic, it may affect access to files, network resources, or actions with real-world consequences. The authors therefore stress the need for independent safeguards: oversight of the system’s learning process, limits on its permissions at runtime, and controls on actions that could have serious consequences.

Deployment requires three distinct layers of protection:

🟣 Change evaluation: Test new versions on independent tasks.

🟣 Access control: Give the agent only the permissions it needs.

🟣 Consequence control: Require separate approval or review for risky actions.

Harness self-evolution also changes how teams work. When a successful procedure is saved and reused across tasks, other agents or team members may use it too. That saves time, but it also raises the cost of mistakes: a bad change can spread just as easily.

Conclusion

Harness self-evolution lets an AI agent learn from experience without changing the model itself. It can preserve successful procedures, create tools, and revise its control rules. The more of the system it is allowed to change, the greater its potential—and the harder it becomes to assess the consequences.

The key questions are whether results will hold up on new examples, whether performance will suffer in other situations, and who is responsible for changes the agent makes to its environment. Self-updating is useful only when paired with continuous evaluation and independent safeguards.