Log in
An agent can get better at its job without a new model. It can learn to find useful information, choose the right tool, or check that a task is finished before reporting success. For that experience to help with the next task, something has to carry over: an updated instruction, a lesson saved in memory, or a change to the software that runs the agent.
That is what interests me about a self-evolving agent: It can use experience to change how it handles future tasks. Much of that change happens in the harness, the instructions, context, tools, and software around the model. Research such as Harness-RSI explores how agents can change that harness while continuing to use the same model.
Of course, a change can make things worse. A saved memory might be wrong, or a new instruction might fix one problem and create another. I think about self-evolving agents in three parts: evaluation to tell whether a change helped, an improvement process that can do more of the work on its own, and the parts of the harness it is allowed to change.
Evaluation: What counts as improvement?
Before I ask an agent to improve itself, I want to know what doing a better job would look like. A model’s score on a benchmark tells us how it performed on that test. To evaluate an agent built with that model, we also need to ask whether it used the right information, took the right actions, and met the user’s requirements.
In a restaurant-planning exercise I developed for teaching evaluation, an agent is given a group’s needs and information about restaurants. Its job is to suggest a place and a time for dinner. The people and restaurants are fictional, but success is easy to understand: Can everyone eat there, afford it, and make it on time?
In one test, the agent recommended a restaurant that met everyone’s needs. My evaluation still marked the answer as wrong because it compared the wording with a sample answer I had written. But my answer was only one possible solution. A different recommendation could work just as well. That feedback could lead a self-improving agent to “fix” a decision that was already good.
A more useful evaluation would check whether the recommendation met the group’s requirements. If someone’s budget is $25 and the meal costs $28, the plan fails that check. We can build a custom evaluation around those requirements, checking the price, dietary needs, and timing. Other questions require judgment, such as whether the agent clearly explained a trade-off between price and convenience. A person or another model can help assess those.
If we asked the agent to make a booking as well, we would need to check that the reservation actually existed. A message saying, “Your table is booked” would not be enough. Evaluating the system means checking what it did, as well as what it said.
Once the agent proposes a change, we can test the updated version against the current one. It should still handle tasks it already did well. We should also try cases that were not used to develop or choose the change. Getting one dinner plan right tells us less than handling new groups with different budgets, dietary needs, and schedules.
The evaluation should also explain why an answer failed. “The meal costs more than the guest’s budget” gives the agent something specific to investigate. It still needs to find the cause, but it knows where to start.
Autonomous improvement: Who carries the work forward?
If an engineer has to spot every failure, suggest every change, and start every test, improvement still depends on that person. Autonomous improvement means giving more of this work to the system. It can review past tasks, look for repeated mistakes, propose a change, and test whether the change helps.
For example, a more autonomous dinner planner might notice that it repeatedly recommended restaurants people could not afford, even though their budgets were available. It could try a new instruction: remove restaurants that exceed anyone’s budget before comparing the remaining options. It would then test that instruction on other groups. If the results improve and the agent still handles tasks it previously got right, it can keep the change. Otherwise, it keeps the current version.
There are two kinds of work here. While planning a dinner, the agent uses tools, reads the results, and decides what to do next. That is its task loop. The improvement process looks back across those attempts and changes how it will approach future tasks. An agent can plan dinner on its own and still depend on an engineer to teach it a better way to plan.
This review does not have to happen after every request. The system might start it after several similar failures, or review a day’s work overnight. Looking at several tasks together helps it see which problems keep coming back.
We can give the system more responsibility gradually. At first, it might investigate problems and test changes, then ask an engineer to approve them. Later, it might also keep certain kinds of changes on its own. The team still decides what it may change, how much time or money it may spend experimenting, and when a person needs to step in.
Harness modules: What can evolve?
When an agent makes a poor decision, I want to find the cause before rewriting its instructions. If a guest’s budget never reached the model, telling it to “pay attention to the budget” will not help. We need to fix how that information reaches the model.
ModularRSI divides the harness into five parts: context management, the agent loop, tool use, observation management, and task completion detection. It studies changes to these parts separately before putting them together. This gives us a useful way to ask what exactly an agent could improve.
Context management comes first for me. It determines what information the model has when it makes a decision, including which memories are brought into the current task. Reflective memory means looking back at what happened and saving a lesson that could help next time. For the dinner planner, that lesson might be to check everyone’s budget and dietary needs before comparing restaurants.
The memory needs to distinguish a general lesson from a fact about one person. “Check the budget before recommending a restaurant” could help with any group. “This guest has a $25 budget” applies to a particular person and occasion. Without that context, the agent could use an old fact in the wrong situation.
Dreaming is a way to review and organize memories between sessions. The system goes back over past interactions and what it has already stored, combines related observations, and saves useful lessons. When memories disagree, it needs to check the original evidence before deciding what to keep. Anthropic’s Dreams, for example, produces a reorganized set of memories that can be reviewed before later sessions use them.
What I want from dreaming is a better starting point for the next task. The agent should be able to find a useful lesson without reading every previous conversation again. We can test that by comparing how it handles new tasks with the old and revised memories. Organizing memories overnight only counts as an improvement if the results support that claim.
The agent could also improve how it finds and organizes memories. Saving one lesson may help with a future task. Changing the way it selects lessons could help it make better use of many future experiences.
The other four modules affect how the agent does its work:
- Agent loop: The agent plans, acts, and decides what to do next. It could learn to notice when it is repeating an unsuccessful approach and try a different one.
- Tool use: Tools the agent has and how it uses them. It could add a tool it needs or change a tool’s interface to make it easier to use correctly.
- Observation management: The agent handles the information returned by its tools. It could change how it summarizes a result so that an important fact is not lost.
- Task completion detection: The agent decides that the job is done. It could check for confirmation that an action succeeded before telling the user it is finished.
These parts work together. Changing a tool can change the information the agent receives, which can change its next decision. Testing one module helps us understand a change. Testing the whole agent tells us whether the parts still work well together.
Improvement becomes recursive when the agent uses its updated harness to carry out the next round of improvement. Suppose it changes how it searches past runs for examples of a failure. The next time it tries to improve itself, it uses that new search method to decide what to investigate and test. A change made in one round now shapes how it works on the next one.
This gives the agent a chance to get better at finding and testing improvements, as well as doing its original job. Each round builds on changes that were kept from earlier rounds. To find out whether that helps, we need to check whether later rounds produce changes that work better on new tasks.
I want an agent that needs less repeated correction because it has learned a better way to do the job. We should be able to point to what it learned, what changed, and how we checked that the change helped. Then we can see whether that lesson holds up when the agent has a new task to do.
