Recursive Evolution•Florian•20h

Meta²: Carrying Experience Forward and Adjusting Along the Way

The difficulty in getting an agent to complete a long task often lies midway through. It may have already written the code but missed the actual delivery steps; it may also have simply encountered an ordinary error and be looking for an alternative on its own. At this point, we want it to correct its course promptly, but we also don't want to interrupt it every time something happens. Meta² studies exactly this question: How can an agent adjust how it works based on experience while it is carrying out a task? It assigns “executing the task” and “deciding whether adjustment is needed” to two roles, and organizes guidance experience in advance from training tasks. To understand the paper, it helps to start with a concrete deployment task. 1. Working Rules 1.1 What Counts as Done One task in the paper is to build a web publishing workflow: after pushing a web page to a code repository, the page should be deployed to a designated server, and visiting it should display “hello world.” Here, “pushing” means committing local code to a remote repository, and the task requires that this step trigger an actual deployment. Looking only at the code, it is easy to think the task is already complete: the installation script has been written, the deployment logic is in place, and only a few checks remain before delivery. One run in the paper stopped at this point. The agent tested in a temporary environment, but never ran the installation program in the environment required by the task, and the server was never actually started. It verified the code it had written, but not the entire deployment process from pushing the code to accessing the page. To correct this gap, the standard for “done” first has to be made clear: the repository should actually be cloned, the web page should be committed and pushed, and then the server should be revisited to confirm that it returns the content just deployed. In the paper, the system with guidance experience raised this requirement early on, after which the executor installed the service, completed the process, and verified the result. In this example, guidance plays a specific role: it makes the executor demonstrate completion with the real delivery result, rather than ending the task based on code that merely looks correct. 1.2 Rules Can Change Too Adding a completion requirement like this to an agent changes how it works. The prompt specifies what must be followed, the tools determine what operations are possible, and continuous checks help it remember the requirements in subsequent steps. The paper collectively refers to these arrangements around the model as the Harness. Here, it can be understood as the agent’s “working framework”: the model handles thinking and generation, while the working framework governs how those capabilities are applied to the task. The simplest approach is to write a set of rules before the task begins, such as “you must test before delivery.” But the same rule has to be applied to different objects in different tasks. Deploying a web page requires checking the actual access result; modifying a program requires checking whether the corresponding function works; handling a file requires inspecting the delivered file itself. Exactly what was missed often cannot be seen until the agent has been executing for a while. Meta² therefore adds a guide: the executor continues writing code and running commands, while the guide periodically reviews what it has done and what results it has obtained, then decides whether the working framework needs adjustment. In the paper, the two roles use the same underlying model, the model parameters remain unchanged, and the adjustment takes place around the task's working rules and tools. This raises a new problem. The guide can promptly identify omissions, but if it has to improvise a correction every time, its judgments may not be reliable, and the calling cost will also increase. Meta² therefore moves the preparation work ahead of deployment: it first learns some guidance experience from training tasks, then uses that experience to observe new tasks. The paper's overview diagram shows this choice. At the top are an approach that optimizes a fixed working framework in advance and an approach that makes adjustments at different points in time. Meta² at the bottom instead passes previously learned experience to a guide during a run. The performance comparison on the right will be explained later in conjunction with the evaluation conditions. Figure 1: Meta² first accumulates guidance experience, then uses it to adjust an ongoing task 2. Guidance Experience 2.1 Learning to Wait as Well Once there is a guide, it is not a matter of sending as many reminders as possible. Suppose the executor encounters an error while running a helper command but has immediately switched tools and continued doing the same thing. At that point, another reminder saying “there was an error just now” provides little new information and instead consumes a guidance opportunity. The paper's experience repository therefore preserves a judgment like this: after a one-off environment error, if the executor is already recovering on its own, let it continue; only when the same kind of failure repeatedly appears and there is still no progress should intervention be considered. There is another situation that is even easier to misjudge. The executor's current approach may not have succeeded yet, but every attempt is producing new clues. If the guide therefore insists that it switch approaches, it may interrupt an exploration that is converging. What needs to be avoided here is “changing direction too early,” not stopping observation. Guidance experience therefore has to answer three questions at once: When should the guide intervene, when should it leave things unchanged for now, and what kinds of adjustments may be harmful? The paper names these three categories of knowledge act, hold, and avoid, respectively. Together, they help the guide distinguish between a substantive gap, normal recovery, and effective exploration that has not yet finished. Figure 2: Guidance experience links observable situations with corresponding ways of handling them 2.2 Learning Through Comparisons How are these judgments obtained? Merely saving successful experience is not enough. After a task succeeds, a reminder from the guide may indeed have helped, or the executor may have been capable of solving the task on its own. To learn how to provide guidance, guided and unguided runs have to be examined together. Meta² collects three kinds of run records on training tasks: A is the executor working independently; B is the guide providing guidance using the current experience; and C allows the guide to know the acceptance criteria and acceptance procedure for that training task. All three use the same underlying model and start from a common initial working framework. When A fails and B succeeds, the system looks back at the specific reminders to see whether they filled a gap exposed by the executor. When A succeeds and B fails, it looks for adjustments that may have steered the task in the wrong direction. If both succeed, that is also worth examining: in what kinds of situations can the executor recover by itself, allowing the guide to do less? C provides a reference point for difficult tasks. When both A and B fail, the system may still not know where adjustment is worthwhile. A guide that knows the acceptance criteria during training has a chance to find missed checks and recovery methods. Whether C performs better or worse than B can provide clues for organizing the experience. It is important to distinguish “learning with acceptance information” from “telling the executor the answer.” The guide in C can use the acceptance information for the training task only to assess risk; it cannot directly pass hidden requirements or answers to the executor. The paper also checks whether such information leaks and excludes any records that violate the rules. During a new task, the guide sees the public requirements and actual execution evidence, not the hidden acceptance information used for final scoring. After collecting the records, the system uses a language model to complete a three-step organization process: extracting candidate experience from concrete runs, merging similar situations across different tasks, and finally updating the experience manual. Any merged experience that is retained must be supported by at least two different training tasks. Filenames, ports, and concrete answers remain in the reference examples, while the general rules describe “what situation is worth paying attention to and how it should be handled.” For example, experience distilled from the web deployment task can be expressed as: “When completion requires a result that can only be confirmed through external observation, check that external result before declaring completion.” It preserves the basis for the judgment, while the guide determines for itself which particular website or service to inspect on the next occasion. The paper calls this textual manual Meta-Skill. The “precomputing reusable knowledge” in the title refers precisely to organizing this experience in advance. It is produced by reading training runs, comparing results, and rewriting text; the model parameters remain unchanged throughout this process. These comparisons provide guidance clues. Multiple executions of the same task can follow different paths, and results may also be affected by random variation and the working configuration. Organizing experience therefore also requires looking back at what evidence was available, what the guide specifically did, and how the executor proceeded afterward, so that it is possible to determine which situations an experience applies to. 3. Reusing Experience 3.1 Retaining Experience, Replacing Rules At this point, we have an executor, a guide, and an experience manual. How do they work together when entering a new task? Return to the web deployment example. The guide can turn general experience into a rule for the current task: before completion, actually push the web page and then access the target server to confirm the result. This rule is well suited to the deployment work at hand. On the next task, if all that is needed is to convert a local file, continuing to require a server check would become an irrelevant burden. Meta² therefore stores two things separately: guidance experience is reused across tasks, while specific working rules apply only to the current run. The next task can still refer to the judgment about “checking the actual delivery result,” but which object to inspect and how to inspect it must be determined anew based on the new task. The paper's deployment setup therefore has a clear boundary: the experience manual is built in advance and kept frozen during deployment; every task starts from the same initial working framework. Rules, tools, and the guide's conversation records produced during a run are discarded when that run ends. The system does not directly turn an adjustment that has not undergone reliable validation into a rule that every future task must follow. 3.2 Adjusting Midway Through During an actual run, the guide does not watch every command continuously. In the paper, it checks once after the executor completes its first step, then by default every five execution steps, and once more when it is ready to deliver. At each check, the guide can see newly performed operations and their results, read the workspace content it is permitted to view, and know whether its previous modification loaded successfully. Using the experience manual, it makes a top-level choice: keep the current working framework or modify it. The original diagram labels these two options KEEP and EVOLVE. Adjustments can have different durations. Pointing out an immediate omission can be a one-time notification; preserving a completion requirement for later steps can change persistent instructions; repeatedly reporting file status can add a checking mechanism; and missing an operational capability can add a tool. If the modified framework cannot be loaded, the system rolls back the modification and passes the error to the guide. All of these modifications serve the original task. The executor does not need to restart the environment or rewrite code it has already completed; it can continue with the new rules. If the executor has already declared completion but the guide finds that the delivery still lacks evidence, it can also send the executor back to the same run to complete the verification within the remaining budget. The number of notifications and amount of rework are both budget-limited, and adjustments that expand tool permissions or the scope of the task must still receive human approval. Now that the paper's complete architecture diagram can be viewed, its two stages can be connected. The upper half is predeployment experience learning: A/B/C records go through comparison, reflection, merging, and updating to form Meta-Skill. The lower half is postdeployment task execution, with the guide using the manual at checkpoints. The entries on the right bring together applicable situations, handling recommendations, reasons, and reference examples. Figure 3: Previously learned experience guides mid-run adjustments while the executor continues completing the same task The arrow at the top of the original diagram returning to the “next training batch” represents the loop through which the experience manual continues to improve during the training stage. By the time the lower part reaches a new task, the manual has been frozen; what changes is the working framework for that task. Offline learning accumulates the basis for judgment, while online guidance applies that basis to the current situation. 4. Results and Costs 4.1 Whether the Experience Helps To assess whether this design helps, two questions can be considered first: Does adding a guide improve the task completion rate, and does organizing experience in advance yield additional benefits? The paper evaluates two sets of tasks. Terminal-Bench 2.1 examines complex operations in command-line environments, while DeepSWE 1.1 examines software modifications in code repositories. The authors use 29 and 38 tasks, respectively, to construct training experience, and then evaluate another 60 and 75 tasks; the test tasks are repeated five and three times, respectively, and the average pass rates are reported. The following results use GPT-5.6-Terra with medium reasoning settings, with the executor and guide using the same underlying model. Configuration Command-line tasks Software modification tasks Executor only 66.33% 34.67% Guide added, but no experience manual 74.67% 36.44% Meta²: Guide uses experience learned through comparisons 81.00% 44.44% On this set of test tasks, the guide itself already helps, and experience organized in advance further improves the pass rate. The difference in software modification tasks is particularly notable: adding only the guide yields a limited improvement, whereas after using comparative experience, the result rises from 36.44% to 44.44%. The ablation diagram in the original paper also compares another form of self-distilled experience with an approach that retains current modifications for subsequent tasks. The left side shows command-line tasks, the right side shows software modification tasks, and each panel compares different configurations internally. Figure 4: Comparative experience provides additional benefits, while leaving specific modifications for the next task causes performance to fall After directly carrying the working framework produced by the previous task into the next task, the results for the two sets fall from 81.00% and 44.44% to 78.33% and 39.11%, respectively. This supports the division of responsibilities described earlier: what should be passed on is guidance experience, while specific modifications need to be tailored to their respective tasks. The self-distilled experience in the diagram also produces no stable additional benefit on software modification tasks, indicating that how the experience is formed affects the results as well. These results come from the test sets partitioned by the authors and are average pass rates across multiple runs. They answer the question of effectiveness within the scope of the tasks above; more open-ended research tasks and work without clear acceptance criteria require further validation. The paper also constructs experience separately for different models, and the current results do not directly test the effect of using the same manual across models. 4.2 Guidance Also Has a Cost The guide has to read execution records, assess the situation, and propose modifications, all of which require additional model calls. “Learning experience in advance” can reuse the preparation work, but observing the run still incurs costs. As an example, across 300 test runs on command-line tasks, Meta² cost $110.19 to build experience in advance and $64.72 to perform the formal executions; execution with only the initial executor cost $34.09. These are the cumulative calling costs for the entire evaluation. The experience manual can be reused afterward, allowing the preparation cost to be amortized; but in this experiment, the online cost after adding guidance remains clearly higher than that of the initial executor. Observation frequency also reflects this tradeoff. When checking every five steps, Meta² achieves an 81.00% pass rate at the online cost of $64.72; when checking every step, the cost rises to $83.41, while the pass rate actually falls to 79.00%. More checking opportunities do not lead to better results on this set of tasks. The next optimization target is therefore to decide when guidance is needed based on actual execution signals. An error that the executor has already recovered from on its own and a persistent gap that could affect delivery should receive different degrees of attention. This is also why “learning to wait” enters the experience manual. 5. Summary In the deployment task at the beginning, what was missing was not more complicated code, but a working requirement that turns “it is written” into “it has actually been delivered.” Meta² makes two layers of preparations around this problem: first learning from training tasks when guidance is worthwhile, then turning those judgments into specific working adjustments in new tasks. The most useful lesson from this paper is managing guidance experience separately from the current task's rules. The former describes which signals deserve attention and can be organized and reused repeatedly; the latter specifies what to inspect now and how to proceed, and must be determined anew for each task. This allows the guide both to identify omissions and to remain restrained when the executor is recovering normally. Improvement in a long task does not always have to wait until failure and require a restart. Bringing reliable experience into the execution process, making adjustments while there is still time to do so, and preserving the work already completed are precisely the problems Meta² is designed to address. References Meta²: Precomputing Reusable Knowledge for Online Harness Evolution in Long-Horizon Agents https://arxiv.org/abs/2611.05139

MetaHarnessTerminal-Bench 2.1RSI

1 / 5‹›