Annie Wang describes how an agent can improve at its job without receiving a new model: by learning to find useful information, pick the right tool, or verify that a task truly completed before reporting success. For that experience to affect future tasks, something must preserve the lesson — an updated instruction, a memory entry, or a change to the software that runs the agent.
Wang focuses on changes to the agent’s harness: the instructions, context, tools, and surrounding software. Research such as Harness-RSI studies how agents can modify that harness while continuing to use the same underlying model. But changes can also hurt: a saved memory might be incorrect, or a new instruction might solve one issue and create another.
She frames self-evolving agents in three parts: evaluation (how to tell whether a change helped), an improvement process that can increasingly act autonomously, and which parts of the harness the agent is allowed to change.
Evaluation: what counts as improvement?
Before asking an agent to improve itself, Wang argues we must be clear about what “better” looks like. A model’s benchmark score shows performance on that test, but evaluating an agent requires checking whether it used the right information, took the right actions, and met the user’s requirements.
Wang uses a classroom exercise — a restaurant-planning task — to make this concrete. The agent receives a group’s needs and restaurant information and must suggest a place and time for dinner. Success is easy to judge in practical terms: can everyone eat there, afford it, and arrive on time?
In one test the agent recommended an acceptable restaurant, but the evaluation marked the answer wrong because it compared the phrasing to a sample answer written by the evaluator. Wang notes that such lexical comparison can wrongly push a self-improving agent to “fix” decisions that were already valid. A more useful evaluation checks the group’s requirements directly — price, dietary needs, timing — and can incorporate human judgment or another model where questions require interpretation (for example, whether trade-offs were clearly explained).
If the agent is also asked to make a booking, the evaluation must verify that a reservation actually exists; a message claiming “Your table is booked” is not sufficient. Evaluating the system means checking both what it said and what it did.
When the agent proposes a change, we should test the updated version against the current one. The new version should preserve prior successful behavior and handle new cases that were not used to develop the change. The evaluation should also provide actionable failure explanations (e.g., “the meal exceeds the guest’s budget”) so the agent knows where to investigate.
Autonomous improvement: who carries the work forward?
If an engineer must spot every failure, propose every change, and run every test, improvement remains human-dependent. Autonomous improvement delegates more of this work to the system: reviewing past tasks, finding repeated mistakes, proposing changes, and testing whether those changes help.
As an example, a more autonomous dinner planner might notice it repeatedly recommended restaurants beyond guests’ budgets even though budgets were available. It could propose a new instruction: filter out restaurants that exceed any guest’s budget before comparing options. It would then test that instruction on other groups; if results improve and previous correct behavior is preserved, it keeps the change, otherwise it reverts.
Wang distinguishes the agent’s task loop (planning, using tools, reading results, deciding next steps) from the improvement process that looks back across attempts and alters future approach. An agent can plan dinner independently yet still rely on engineers for better planning strategies. The review need not run after every request; it can trigger after multiple similar failures or as a daily batch. Reviewing several tasks together helps surface recurring issues.
Responsibility can be increased gradually: an agent might initially investigate problems and test changes, then request engineer approval. Later it might autonomously retain certain categories of changes. The human team decides what the agent may change, how much resource it may use for experiments, and when human intervention is required.
Which harness modules can evolve?
When an agent makes a poor decision, Wang wants to find the cause before rewriting instructions. If a guest’s budget never reached the model, telling it to “pay attention to the budget” won’t help; the information pipeline must be fixed.
ModularRSI divides the harness into five parts — context management, the agent loop, tool use, observation management, and task completion detection — and studies changes to these parts separately before integrating them. This modular view helps ask precisely what an agent could improve.
-
Context management: Wang places this first. It determines what information the model has when deciding, including which memories are included in the current task. Reflective memory means inspecting past events and saving lessons useful next time (for the dinner planner: check every guest’s budget and dietary needs before comparing restaurants). Memories must discriminate general lessons from specific facts: "check the budget" is general, while "this guest has a $25 budget" is situational.
Wang describes "dreaming" as a way to review and organize memories between sessions: the system revisits prior interactions and stored facts, combines related observations, and saves useful lessons. When memories conflict, the system should check original evidence before deciding what to keep. Anthropic’s Dreams is one example that produces a reorganized memory set for later review. Dreaming only counts as improvement if the reorganized memories lead to better performance on new tasks.
The agent can also improve how it searches for and organizes memories: saving one lesson might help one future task, but changing the selection method could better leverage many experiences.
-
Agent loop: the planning–acting–deciding cycle. The agent could learn to notice repeating unsuccessful approaches and try alternatives.
-
Tool use: which tools the agent has and how it uses them. The agent might add a needed tool or change a tool’s interface to reduce misuse.
-
Observation management: how the agent processes tool outputs. It could change summarization or parsing so important facts aren’t lost.
-
Task completion detection: how the agent judges that a job is done. It could require confirmation of success before reporting completion.
These modules interact: changing a tool can alter the information received, which affects subsequent decisions. Testing individual modules clarifies the effect of a change; testing the whole agent shows whether modules still integrate successfully.
Recursive improvement and the aim
Improvement becomes recursive when the agent uses its updated harness to carry out the next round of improvement. If it changes how it searches past runs for examples of a failure, the next improvement cycle uses that new search method to decide what to investigate and test. A change kept in one round then shapes subsequent rounds.
This enables an agent to get better both at its original tasks and at finding and testing improvements. Each round builds on previously retained changes; to know whether this helps, we must check whether later rounds produce changes that generalize to new tasks.
Wang’s goal is an agent that requires fewer repeated corrections because it has learned a better way to perform its job. Crucially, we should be able to point to what the agent learned, what changed in the harness, and how we verified that the change improved performance — and then confirm those lessons against new tasks.
