Papers
Topics
Authors
Recent
Search
2000 character limit reached

Evo2^2: Evolving the Evolver through Weight-Harness Co-Evolution

Published 9 Oct 2026 in cs.CL | (2610.13025v1)

Abstract: Self-evolving agents are increasingly used to improve LLM systems without human intervention through either weight updates or harness improvements. Existing approaches typically pursue these directions separately: some methods update model weights using self-generated experience, while others rewrite the harness that defines how an agent uses prompts, tools, context, and execution feedback. However, these approaches overlook the relationship between model weights and the agent harness. To connect these processes and ensure effective and smooth agent self-evolving, we propose Evo<sup>2<sup>2, a framework for weight-harness co-evolution. For harness updates, we design a unified dual-role pipeline that a single policy serves as both a Proposer, which writes harness edits, and a Reflector, which diagnoses their effects and guides revision. For weight updates, harness modifications and their execution outcomes guide the training of both the Proposer and the Reflector. We further develop EvoTIDE, a training pipeline that recovers usable trajectories through edit extraction and prefix continuation, then combines SFT with interleaved GRPO across the two roles. Extensive experiments across three coding benchmarks demonstrate that Evo<sup>2<sup>2 significantly outperforms existing self-evolution methods. It achieves 82.1% on Polyglot and 48.3% on SWE-bench Verified, compared with 62.6% and 41.0% for the strongest baseline, respectively. We also show that the evolved harnesses transfer to different tasks without further evolution and rank first in cross-benchmark evaluations. Our dual-role harness improvement framework is also able to extend to self-evolution with proprietary models, improving a GPT-5-mini agent's performance from 24.4% to 48.3%. These results demonstrate the applicability of the framework Evo<sup>2<sup>2 across domains and its broad transferability across models and tasks.

Summary

  • The paper introduces Evo, a co- evolutionary framework that integrates self-eval, harness & model policy.
  • Evo significantly outperforms baselines on coding tasks with improvements up to 19.5% points, demonstrating better effectiveness and efficiency.
  • Email the cost-effectiveness of harness-evolution experience and exposes deployed minimised cost.

Evo addresses a structural limitation in self-evolving agents: model-weight adaptation and agent-harness adaptation are usually treated as separate optimization processes. The paper instead formulates them as a coupled system in which an evolver policy improves the executable harness, while the resulting harness modifications and task outcomes provide training data for improving the evolver. The central claim is that this feedback loop produces a more capable search policy and more effective harnesses than either isolated weight evolution or isolated harness evolution.

Problem formulation and central contribution

An agent harness is treated as an executable program specifying prompts, tool use, context management, control flow, and interaction with a fixed task executor. Evo maintains two mutable objects:

  1. The harness, which changes through code-level edits and is evaluated on task performance.
  2. The evolver policy, whose weights determine how edits are proposed, interpreted, revised, and transferred across search branches.

The task executor remains fixed during co-evolution. Consequently, performance changes are attributed to modifications of the harness and to improvements in the policy that generates those modifications. This separation is methodologically useful, although it also makes the framework dependent on the assumption that the evaluator provides sufficiently reliable feedback.

The evolver uses a unified policy in two roles. The Proposer generates harness edits, while the Reflector analyzes execution outcomes and determines whether the candidate should be revised, combined with a strategy from another branch, or retained. Both roles share parameters, so experience acquired in one role can alter behavior in the other.

Figure 1

Figure 1: Evo alternates between harness modification and policy-weight updates, with evaluated edits providing training experience for the shared Proposer–Reflector policy.

The paper’s principal conceptual contribution is therefore not merely a search procedure over harnesses. It is a co-evolutionary loop in which the policy that performs search is itself trained on the consequences of its search decisions. A successful harness contributes executable behavior, while its associated edit and evaluation trajectory contributes training evidence about how an evolver should act.

Dual-role harness evolution

Harness evolution is organized as a tree. Each node contains an executable harness and its evaluation records; edges encode the edits applied to obtain child harnesses. A parent is sampled from a maintained pool, and the Proposer performs an autonomous Type A modification. The resulting harness is executed by the fixed task executor. The Reflector then receives the source code, edit diff, task-score change, and relevant execution traces.

The Reflector selects among three actions:

  • Revision, issuing a directive for the Proposer to repair or extend the current candidate.
  • Crossover, selecting a strategy discovered in another branch and directing the Proposer to adapt it to the current harness.
  • Retention, preserving the candidate without another edit.

The distinction between the two Proposer modes is important. In Type A, the policy must identify a useful modification from the parent harness and its evaluation history. In Type B, it must translate an explicit Reflector directive into executable source changes. The former measures autonomous search, whereas the latter measures instruction-following and code-level implementation. Training both modes allows the policy to separate diagnosis from implementation while retaining a shared parameterization.

Crossover searching addresses a common weakness of tree-based self-modification: improvements found in one branch may remain inaccessible to other branches. Evo stores extracted strategies in a library, with each strategy represented by its mechanism, observed effect, and compatibility with the current candidate. The Reflector can select a donor strategy when the candidate’s execution traces expose a relevant weakness. The Type B Proposer then adapts that mechanism rather than copying source text mechanically. This design makes crossover a directed, semantically mediated operation rather than unrestricted program recombination.

Figure 2

Figure 2: Harness evolution combines autonomous edits, execution-based reflection, directed revision, crossover from other branches, and trajectory recovery.

The reward for each role is based primarily on the change in externally evaluated task performance. A Proposer receives the difference between the child and parent harness scores; a Reflector receives the difference between the post-intervention and pre-intervention candidates. Invalid, non-executable, no-op, or malformed edits are penalized. The paper also imposes an evidence condition on Reflector gains: an apparent improvement is credited only when execution traces indicate that the added mechanism actually ran. This reduces, but does not eliminate, the possibility of spurious attribution from noisy or underspecified evaluations.

EvoTIDE and trajectory recovery

EvoTIDE—Tree-guided Interleaved Dual-role Evolution—converts harness-evolution traces into training data for the shared policy. The training pipeline has three stages: trajectory collection, SFT initialization, and interleaved GRPO.

A practical difficulty is that model rollouts frequently contain useful partial behavior without producing a formally valid edit. Evo therefore uses two recovery mechanisms. Edit extraction searches incomplete responses for concrete file modifications and converts them into the required action representation. Prefix continuation truncates a rollout after the last successfully applied edit, restores the corresponding intermediate harness, and resumes generation from that prefix when a later edit is malformed or invalid. Recovered candidates still undergo application, startup, and task-evaluation checks.

These procedures increase data yield, but they introduce a potential distributional issue: recovered trajectories are not necessarily sampled from the same process as fully valid trajectories. The paper treats recovery primarily as a way to preserve useful supervision rather than explicitly quantifying its effect on policy bias or optimization stability.

The initial policy is trained with SFT on successful autonomous edits, directed edits, and Reflector outputs selected using downstream evaluation results. Online training then uses GRPO separately for Proposer and Reflector groups. A frozen snapshot of the policy supplies counterpart behavior within each training round: during Proposer optimization, it generates the Reflector directives; during Reflector optimization, it implements sampled directives. This avoids allowing both sides of a single training comparison to change simultaneously.

Parent sampling is designed to expose the policy to both strong and weak harnesses. The pool preserves the root, retains nodes at multiple depths, reserves capacity for high-performing candidates, and samples additional executable candidates using a score-dependent weighting scheme that favors both low- and high-performing harnesses. The intended effect is to train two complementary capabilities: incremental improvement of strong harnesses and repair of weak ones.

The use of a single policy for both roles creates an explicit coupling between diagnosis and implementation. An improved Proposer supplies better candidate modifications for Reflector training; an improved Reflector supplies better directives for Proposer training. The paper’s claim is therefore stronger than that of conventional self-training from successful outputs: the policy is trained on a structured interaction in which edit generation, evaluation, diagnosis, and revision are mutually dependent.

Coding benchmark results

Evo is evaluated with Qwen3.8-27B as both the fixed task executor and, in the main setting, the evolver. It is compared with SICA, DGM, HGM, and GEA on Polyglot, SWE-bench Verified, and LiveCodeBench.

Method Polyglot pass@1 SWE-bench Verified resolved LiveCodeBench pass@1
SICA 60.2 20.5 39.0
DGM 60.2 30.0 54.0
HGM 61.8 41.0 56.0
GEA 62.6 25.0 49.0
Evo 82.1 48.3 58.0

Evo improves Polyglot performance by 19.5 percentage points over the strongest baseline, GEA, and improves SWE-bench Verified by 7.3 points over HGM. On LiveCodeBench, the gain is smaller but remains positive: 58.0% versus 56.0% for HGM. The consistency across all three benchmarks supports the paper’s claim that the method is not narrowly optimized for one coding distribution.

The Polyglot result is particularly large and suggests that Evo discovers harness mechanisms that materially alter the executor’s ability to solve tasks. However, the benchmark-level comparison conflates several factors: tree search, crossover, dual-role prompting, trajectory recovery, and weight evolution are all present in the full system. The subsequent ablation is therefore essential for determining whether the gains arise from co-evolution rather than from harness search alone.

Transfer across coding tasks

The paper evaluates each benchmark-selected harness on the other two coding benchmarks without further evolution. Evo achieves the best result in five of six transfer directions.

Source benchmark Target benchmark Evo Best baseline
Polyglot SWE-bench Verified 21.0 20.0
Polyglot LiveCodeBench 44.0 45.0
SWE-bench Verified Polyglot 72.4 69.9
SWE-bench Verified LiveCodeBench 53.0 50.0
LiveCodeBench Polyglot 74.0 63.4
LiveCodeBench SWE-bench Verified 43.0 29.0

The largest transfer advantage occurs when the harness evolved on LiveCodeBench is evaluated on SWE-bench Verified: Evo reaches 43.0%, compared with 29.0% for the strongest baseline. The LiveCodeBench-to-Polyglot transfer advantage is also substantial, at 10.6 points over the best baseline. These results imply that the evolved harnesses contain mechanisms that are not restricted to the source benchmark’s task distribution.

The one exception is Polyglot-to-LiveCodeBench, where Evo reaches 44.0%, one point below the best baseline. Thus, the claim of broad transferability should be interpreted as a strong majority result rather than universal dominance. Transfer also depends on the compatibility of the harness’s prompts, tools, and control flow with the target executor and benchmark.

Fixed-weight proprietary-model experiments

The dual-role harness-improvement procedure is also tested without weight evolution. GPT-5-mini and Claude Haiku 4.5 serve simultaneously as executor, Proposer, and Reflector, with their parameters fixed. This isolates the contribution of harness search, reflection, and crossover from EvoTIDE.

Method GPT-5-mini Claude Haiku 4.5
SICA 24.4 42.2
DGM 23.9 43.3
HGM 24.3 45.0
GEA 19.4 44.4
Evo 48.3 47.8

On GPT-5-mini, Evo nearly doubles the strongest baseline, increasing the resolved rate from 24.4% to 48.3%. On Claude Haiku 4.5, the improvement is smaller but still positive, reaching 47.8% compared with 45.0% for HGM. The GPT-5-mini result is important because it demonstrates that the dual-role harness mechanism can produce large gains even when the evolver cannot be fine-tuned.

There is, however, an evaluation asymmetry: Evo reports the better of its two top-ranked harnesses, whereas each baseline reports its top-ranked harness. The experiments average across three independent searches, but this selection rule should be considered when interpreting the magnitude of the proprietary-model comparison.

Generalization to memory tasks

Evo is instantiated on memory tasks by adapting the editable harness and evaluator while retaining the Proposer–Reflector interaction, crossover search, and training procedure. The harness is evolved on LoCoMo and evaluated both on held-out LoCoMo conversations and on LongMemEval-S without further evolution or selection.

Method LoCoMo F1 LongMemEval-S accuracy
SICA 54.6 59.7
DGM 55.8 60.3
HGM 56.2 64.4
GEA 53.2 48.9
Evo 60.4 71.5

Evo exceeds HGM by 4.2 points on LoCoMo and by 7.1 points on LongMemEval-S. The cross-benchmark result is especially relevant because LongMemEval-S is not used for evolution or selection. The reported Evo searches range from 67.9% to 73.9% on LongMemEval-S, indicating that the result is not attributable to a single anomalous run.

The memory experiments support a domain-general interpretation of the framework, but they do not establish that the same evolved harness is domain-independent. The harness is adapted to memory tasks, and the evaluator, retriever, and task interface differ from the coding setting. The evidence therefore supports portability of the co-evolution procedure across domains, not direct transfer of coding harnesses to memory workloads.

Ablation of weight evolution and efficiency

The weight-evolution ablation fixes the search procedure, executor, and parent harnesses while comparing the base Qwen3.8-27B evolver with the EvoTIDE-trained policy.

Benchmark Untrained evolver Trained evolver Improvement
Polyglot 61.8 78.0 +16.3
SWE-bench Verified 46.0 51.0 +5.0
LoCoMo 47.2 56.5 +9.3
LongMemEval-S 57.1 67.7 +10.6

Training improves the selected champion on every benchmark. The Polyglot improvement is statistically reported as significant, with a 16.3-point gain and P=.001P=.001. The SWE-bench gain is only 5.0 points and has P=.086P=.086, so the paper’s evidence for a reliable improvement on that benchmark is weaker. The LoCoMo and LongMemEval-S gains further suggest that the trained evolver learns transferable editing and reflection behavior rather than only benchmark-specific code modifications.

The paper also reports that crossover contributes an additional 4.1 points on Polyglot. This supports the claim that branch-to-branch strategy transfer is not redundant with local revision, although the available results do not fully disentangle crossover from the other components of the search process.

A further claim is that Evo improves performance without increasing inference cost at deployment. On LiveCodeBench, the Evo harness uses approximately 3.6K completion tokens and 10.2 LLM calls per task, compared with 6.6K–6.9K tokens and 26–37 calls for HGM and DGM. Evo therefore achieves the highest reported accuracy while using substantially fewer executor calls. On Polyglot, its champion uses 36 calls and 3.6K tokens, compared with 43 calls and 4.0K tokens for the unevolved harness. The implication is that harness evolution changes the allocation and sequencing of inference rather than simply increasing deliberation.

These efficiency comparisons concern the deployed evolved harness, not the cost of evolution itself. Evo may require considerable search-time evaluation, model inference, SFT, and GRPO computation. Thus, the result establishes improved task-time efficiency, while the total amortized cost of producing the harness remains an open empirical quantity.

Limitations and open questions

The evaluation relies heavily on benchmark execution scores as rewards. This is appropriate for coding and memory tasks with external evaluators, but it leaves Evo exposed to evaluator noise, incomplete test coverage, and reward hacking. The paper penalizes invalid edits and requires execution evidence for some Reflector rewards, yet it does not establish that the learned policy reliably distinguishes genuine functional improvement from benchmark-specific exploitation.

The fixed-executor assumption also limits the interpretation of co-evolution. It permits clean attribution of performance changes to harness edits, but real deployments may involve changing model versions, tools, repositories, or execution environments. It remains unclear whether strategies learned under a fixed executor remain stable when the executor or tool interface changes.

The main comparisons do not isolate every design choice. The reported advantage of full Evo reflects the combined effects of shared-role training, tree maintenance, parent sampling, trajectory recovery, GRPO, and crossover. The ablation establishes a contribution from weight evolution and reports a crossover gain, but a more complete factorial analysis would be needed to quantify interactions among these components.

Finally, the Reflector’s textual diagnosis is treated as useful supervision, although language-model explanations are not necessarily faithful descriptions of the causal mechanism behind a performance change. The evidence-based reward condition partially addresses this issue, but the question of whether the Reflector learns causal program diagnosis or merely correlational heuristics remains unresolved.

Conclusion

Evo presents a unified framework for co-evolving an agent harness and the policy that modifies it. Its Proposer–Reflector architecture combines autonomous editing, execution-based diagnosis, directed revision, and cross-branch strategy transfer. EvoTIDE then trains the shared policy using recovered trajectories, SFT, and interleaved GRPO over a dynamically maintained harness tree.

The empirical results support the central design: Evo reaches 82.1% on Polyglot, 48.3% on SWE-bench Verified, and 58.0% on LiveCodeBench, transfers effectively across coding benchmarks, improves fixed-weight proprietary agents, and extends to memory tasks. Weight evolution contributes substantial gains, particularly on Polyglot and LongMemEval-S, while deployment-time inference costs are lower than those of several baselines. The remaining questions concern evaluator robustness, evolution cost, executor dependence, and the causal validity of Reflector feedback.

Whiteboard

Explain it Like I'm 14

1. What is this paper about?

This paper introduces Evo, a system that helps an AI agent improve itself.

The main idea is that an AI agent can improve in two different ways:

  1. Changing its “brain” — updating the model’s internal settings, called its weights.
  2. Changing its “working instructions” — editing the program that tells the agent how to use prompts, tools, memory, and feedback. This program is called a harness.

Earlier systems usually improved only one of these things at a time. Evo improves both together. The AI learns how to make better changes to its harness, and the results of those changes help train the AI itself to become a better improver.

The paper describes this as weight–harness co-evolution.

2. What questions are the researchers asking?

The researchers wanted to find out:

  • Can an AI learn to improve the program that controls how it works?
  • Can the AI use the results of those improvements to train itself?
  • Is it better to have one AI act both as:
    • a Proposer, which suggests and writes changes, and
    • a Reflector, which studies the results and suggests fixes?
  • Can useful ideas discovered in one version of the program be combined with ideas from another version?
  • Do improvements learned on one task, such as coding, also help with other tasks?
  • Can this method improve powerful AI systems even when their internal weights cannot be changed?

A simple way to imagine this is a student who is not only solving homework problems but also improving their own study plan. After trying a new study method, the student checks whether it worked, keeps useful parts, and changes the parts that failed.

3. How does Evo work?

The AI agent has a “harness”

A harness is the program around a LLM. It decides things such as:

  • what instructions the model receives,
  • which tools it can use,
  • what information it remembers,
  • how it checks its own work,
  • and what steps it follows before giving an answer.

The LLM itself is like the student’s brain. The harness is like the student’s notebook, study routine, calculator, and checklist.

Two roles: Proposer and Reflector

Evo uses the same LLM in two roles.

  • The Proposer suggests a change to the harness, such as adding a better way to search files or check code.
  • The Reflector looks at what happened after the change. It studies the successes, failures, and computer feedback, then decides whether to:
    • suggest another revision,
    • borrow a useful idea from another version,
    • or keep the current version.

Using the same AI for both roles allows it to learn both how to create improvements and how to judge them.

Searching through many versions

Evo organizes different harness versions like the branches of a tree:

  • The original harness is the starting point.
  • Each new edit creates a new branch.
  • Successful branches can be improved further.
  • The system can compare branches and combine useful ideas.

This combining process is called crossover. It is similar to taking the best feature from one sports team’s strategy and combining it with the best feature from another team’s strategy.

Training the “evolver”

Evo does not only improve the harness. It also trains the model that proposes and evaluates changes.

The researchers created a training process called EvoTIDE. It uses examples collected during harness evolution, including:

  • which edits were made,
  • whether the edits worked,
  • what errors occurred,
  • and what the Reflector recommended.

The model first learns from successful examples through supervised fine-tuning. This is like studying worked examples in a textbook.

It is then trained using reinforcement learning, where better results receive higher rewards. For example:

  • an edit that improves coding performance receives a positive reward;
  • an edit that breaks the program receives a negative reward;
  • an edit that makes no useful change receives little or no reward.

The researchers also used two methods to save useful attempts:

  • Edit extraction: finding a valid code edit inside an incomplete response.
  • Prefix continuation: keeping the valid beginning of an attempt and asking the model to continue again after a later mistake.

These methods are similar to keeping the correct steps in a homework solution even when the final step contains an error.

How was it tested?

The researchers tested Evo on:

  • Polyglot, a coding benchmark;
  • SWE-bench Verified, which tests whether AI can fix real software problems;
  • LiveCodeBench, another programming benchmark;
  • LoCoMo and LongMemEval, which test an AI’s ability to remember and use information from long conversations.

They compared Evo with other self-improving systems, including SICA, DGM, HGM, and GEA.

4. What did the researchers find?

Evo performed better on coding tasks

Evo achieved the highest score among the tested systems on all three main coding benchmarks.

Benchmark Evo Best competing method
Polyglot 82.1% 62.6%
SWE-bench Verified 48.3% 41.0%
LiveCodeBench 58.0% 56.0%

For example, on Polyglot, Evo solved about 82 out of every 100 test problems, while the strongest comparison system solved about 63.

These results suggest that allowing the AI to improve both its internal training and its working program can make it much more effective.

Improvements transferred to new tasks

The harnesses evolved on one coding benchmark were also tested on other benchmarks without being changed again.

Evo’s harness performed best in five out of six cross-benchmark tests. This is important because it suggests that Evo was not simply memorizing tricks for one particular test. It learned more general ways of working.

It helped models whose weights could not be changed

The researchers also tested Evo with proprietary models such as GPT-5-mini and Claude Haiku 4.5. In these experiments, the models’ internal weights stayed fixed.

Even without changing the model’s “brain,” Evo improved the harness:

  • GPT-5-mini improved from about 24% with the strongest comparison method to 48.3% with Evo.
  • Claude Haiku 4.5 improved to 47.8%, also higher than the comparison systems.

This shows that better instructions, tools, memory handling, and control steps can make a model more useful even when the model itself cannot be retrained.

It also improved memory tasks

Evo was not limited to programming. On memory benchmarks, it achieved:

  • 60.4 F1 on LoCoMo, compared with 56.2 for the strongest comparison system.
  • 71.5% accuracy on LongMemEval, compared with 64.4 for the strongest comparison system.

This suggests that Evo can improve different kinds of AI behavior, not just code writing.

Training the evolver made a difference

When the model responsible for making improvements was trained with EvoTIDE, performance increased compared with using an untrained model.

The improvements included:

  • 16.3 percentage points on Polyglot,
  • 5.0 points on SWE-bench Verified,
  • 9.3 points on LoCoMo,
  • 10.6 points on LongMemEval.

The evolved harnesses also used fewer computer calls and fewer generated words than some competing systems while still achieving better results. In other words, Evo often helped the AI work more efficiently, not just more accurately.

5. Why is this research important?

This paper suggests a new way to build AI systems. Instead of treating an AI model as a finished product, researchers can allow it to improve:

  • its internal abilities,
  • the software that controls it,
  • its use of tools,
  • and the way it learns from mistakes.

The most important idea is the feedback loop:

  1. The AI changes its harness.
  2. The changed harness is tested.
  3. The results show what worked and what failed.
  4. Those results train the AI to become a better improver.
  5. The improved AI makes even better changes next time.

If this approach continues to work, future AI agents may become better at solving difficult problems with less direct human programming. It could help create stronger coding assistants, research tools, and memory systems.

However, there are also challenges. The system must be tested carefully because an AI might make changes that improve its score in an unintended way, break other abilities, or exploit weaknesses in the evaluation. Human monitoring and reliable tests will still be important.

Overall, the paper’s main message is that an AI can improve not only by learning new knowledge, but also by learning how to organize and operate itself better.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The paper leaves the following issues unresolved:

  • Limited model diversity: Most main experiments use Qwen3.8-27B as both executor and evolver, so it remains unclear whether Evo generalizes across substantially different architectures, parameter scales, training recipes, and reasoning capabilities.
  • Narrow task coverage: The evaluation focuses primarily on coding and memory benchmarks. Its effectiveness on non-verifiable, multimodal, interactive, scientific, mathematical, or long-horizon tasks is not established.
  • Dependence on reliable external evaluation: Evo’s rewards require executable task evaluations and measurable performance changes. The paper does not determine how the method behaves when feedback is sparse, delayed, noisy, subjective, expensive, or unavailable.
  • Risk of evaluator overfitting: Harnesses are evolved and selected using repeated evaluations on fixed task subsets. The extent to which improvements reflect genuine generalization rather than overfitting to benchmark instances, test formats, execution environments, or evaluator quirks is unresolved.
  • Insufficient statistical reporting: Many results provide single scores or means without confidence intervals, per-seed results, variance estimates, or significance tests. The stability of the reported gains across independent evolution runs is therefore unclear.
  • Unequal baseline comparisons: The baselines appear to use their own search procedures and may not receive matched evaluation budgets, model prompts, training data, inference budgets, or implementation effort. A controlled comparison under identical resource constraints is still needed.
  • Incomplete compute accounting: The paper reports some deployment-time token and call costs but does not fully report evolution-time costs, including model-training FLOPs, number of candidate evaluations, rejected candidates, storage, wall-clock time, and proprietary-model API costs.
  • Unclear contribution of individual components: Although the paper reports selected ablations for weight evolution and crossover, it does not isolate the effects of trajectory recovery, prefix continuation, SFT, GRPO, parent sampling, role sharing, frozen counterpart snapshots, reward shaping, and the bounded parent pool.
  • No comparison with separately trained roles: The claimed benefit of a shared Proposer–Reflector policy is not directly tested against independently parameterized Proposer and Reflector models or partially shared architectures.
  • Uncertain causal mechanism of co-evolution: The experiments show performance improvements but do not establish whether gains arise from genuine co-adaptation between weights and harnesses, better search heuristics, additional training data, or simply more effective selection and reflection.
  • Potential reward-credit assignment problems: Proposer and Reflector rewards are based on downstream performance differences after multiple interacting edits. The paper does not quantify how often credit is incorrectly assigned when several changes jointly cause an improvement or regression.
  • Reward hacking and specification gaming are not evaluated: Because the system optimizes externally measured task scores, evolved harnesses may exploit benchmark artifacts, evaluator weaknesses, or unintended execution behavior. No systematic red-team or adversarial evaluation is presented.
  • Safety and security of self-modifying code remain unexplored: The paper does not assess whether evolution can introduce malicious behavior, unsafe tool calls, data exfiltration, dependency vulnerabilities, destructive file operations, or unauthorized changes to the execution environment.
  • No formal safeguards for edits: The method describes validity, startup, and task checks but does not specify sandboxing, permission controls, rollback guarantees, static analysis, or containment procedures for harmful or resource-intensive harness modifications.
  • Reproducibility is incomplete: Important implementation details appear unspecified, including exact prompts, edit formats, temperature and sampling settings, group sizes, learning rates, training-token budgets, pool sizes, search horizons, task splits, and selection criteria.
  • Ambiguous champion selection: The study sometimes reports the best harness, sometimes an average, and in the proprietary-model setting the better of two top-ranked harnesses. This creates possible selection bias and makes comparisons with baseline results difficult to interpret.
  • Limited evaluation of transfer: Transfer is measured across a small set of related coding benchmarks and two memory datasets. It remains unknown whether evolved harnesses transfer across languages, repositories, tool APIs, model providers, operating systems, and substantially different task distributions.
  • Executor–evolver coupling is underexamined: The main setup uses the same model family for the executor and evolver. The method’s behavior when the evolver and executor differ in capability, tokenizer, instruction format, or tool-use protocol requires systematic evaluation.
  • Proprietary-model results are small-scale: The GPT-5-mini and Claude Haiku experiments use a 60-task subset and fixed weights. Their generality to larger task sets, other proprietary models, different API versions, and broader search budgets is not demonstrated.
  • Memory-task evaluation is narrow: LoCoMo evolution uses only seven training conversations, and the reported transfer evaluation does not establish robustness to longer histories, multilingual conversations, noisy memories, privacy-sensitive data, or changing user preferences.
  • Long-term evolutionary dynamics are unknown: The paper does not analyze whether repeated co-evolution eventually converges, stagnates, cycles, accumulates incompatible mechanisms, or degrades previously learned capabilities.
  • Parent-pool sampling may preserve suboptimal candidates: The proposed weighting favors both high- and low-performing harnesses, but the paper does not evaluate whether this improves exploration relative to novelty-based, uncertainty-based, diversity-preserving, or purely performance-based selection.
  • Crossover scalability is unclear: The strategy library is described conceptually, but the paper does not study retrieval errors, duplicate or incompatible strategies, library growth, computational overhead, or performance as the number of stored strategies increases.
  • Trajectory recovery may introduce label artifacts: Edit extraction and prefix continuation alter failed model outputs before training. The paper does not measure whether these recovered trajectories faithfully represent model behavior or create synthetic supervision that is unavailable during deployment.
  • Reflection quality is not independently validated: Reflector directives are judged primarily by whether their implemented edits improve task scores. There is no human or automated assessment of diagnostic accuracy, causal attribution, faithfulness to execution traces, or usefulness when performance is unchanged.
  • Language-model explanations are treated as evidence without faithfulness tests: The method relies on generated diagnoses and strategy descriptions, but it does not test whether these explanations accurately identify the mechanisms responsible for success or merely provide plausible post hoc rationalizations.
  • Robustness to noisy execution feedback is unknown: The method averages repeated runs when available, but sensitivity to stochastic executors, flaky tests, nondeterministic tool outputs, incomplete traces, and measurement error is not reported.
  • No analysis of negative transfer from weight evolution: Training the shared policy on one benchmark or domain may reduce performance on others or alter general-purpose model capabilities. Cross-task forgetting and interference are not measured.
  • Inference-cost claims are incomplete: The reported efficiency analysis focuses on selected evolved harnesses and executor completion tokens. It does not include evolution cost, reflector/proposer calls during deployment, tool execution time, memory usage, or worst-case latency.
  • Benchmark contamination and leakage are not addressed: The paper does not discuss whether the executor, evolver, or training data may have encountered benchmark tasks, repository solutions, harness designs, or evaluation artifacts during pretraining or fine-tuning.
  • Human oversight requirements are unclear: Although the framework is presented as autonomous, the paper does not specify how much human intervention is needed for task setup, evaluator construction, failure triage, strategy-library curation, and unsafe-edit handling.
  • Open-ended improvement is not demonstrated: The experiments cover bounded searches and fixed benchmarks. Whether Evo can produce sustained improvements on changing tasks, shifting objectives, or open-ended environments without continually increasing evaluation cost remains unresolved.

Practical Applications

Immediate Applications

The paper’s results support deployment primarily in software engineering, AI-agent operations, research workflows, and long-context information management, where task outcomes can be automatically evaluated. The most feasible uses are those that provide a fixed executor, editable agent harness, reproducible tests, and measurable rewards.

  • Self-improving coding assistants for software engineering
    • Use case: Apply Evo to an existing coding agent that edits repositories, runs tests, inspects execution traces, and revises its prompting, tool-use, retry, and context-management logic.
    • Potential workflow:
    • 1. Start with a fixed coding model and baseline harness.
    • 2. Generate candidate harness edits.
    • 3. Run unit tests, integration tests, or repository-level evaluations.
    • 4. Use the Reflector to diagnose failures and the Proposer to implement revisions.
    • 5. Retain validated harness versions in a searchable archive.
    • Potential product: An enterprise “agent optimizer” that automatically improves GitHub issue resolution, code review, debugging, and test-generation agents.
    • Evidence from the paper: Evo improves performance on Polyglot, SWE-bench Verified, and LiveCodeBench, while sometimes using fewer model calls and completion tokens than competing methods.
    • Dependencies: Reliable automated tests, sandboxed repository execution, version control, regression testing, and safeguards against destructive code changes. Benchmark gains may not transfer to poorly tested proprietary codebases.
  • Optimization of enterprise LLM agent harnesses
    • Use case: Improve customer-service, document-processing, internal search, or workflow-automation agents without retraining the underlying foundation model.
    • What can be evolved: System prompts, tool-selection policies, retrieval settings, memory-management code, error recovery, planning loops, and context-window allocation.
    • Potential product: A model-agnostic harness-tuning platform that works with proprietary APIs such as GPT-class or Claude-class systems.
    • Evidence from the paper: The dual-role harness search improves proprietary models with fixed weights, indicating that useful gains can come from modifying orchestration rather than model parameters.
    • Dependencies: Stable model and tool interfaces, access to execution traces, representative evaluation data, and strict controls preventing the system from changing authorization or compliance logic.
  • Automated prompt and workflow engineering
    • Use case: Use the Proposer–Reflector loop to optimize prompts and multi-step workflows for classification, extraction, summarization, question answering, or document analysis.
    • Potential workflow: The Proposer changes the prompt or workflow; the Reflector compares outputs against labeled examples or task metrics; the best changes are preserved and transferable across related datasets.
    • Potential product: An internal prompt-management system that maintains branches, evaluates variants, performs crossover between successful strategies, and rolls back regressions.
    • Dependencies: A sufficiently objective evaluator. Human preference or open-ended quality judgments may require additional human review because the paper’s reward design assumes measurable task performance.
  • Long-context memory assistants
    • Use case: Improve personal knowledge managers, legal research tools, clinical literature assistants, enterprise knowledge bases, and meeting-memory systems.
    • What can be evolved: Retrieval policies, chunking, indexing, memory consolidation, recency handling, query rewriting, and answer verification.
    • Evidence from the paper: Evo improves LoCoMo and transfers to LongMemEval, suggesting that an evolved memory harness can generalize beyond the data used during evolution.
    • Potential product: A continuously evaluated memory layer for assistants that learns which information to store, retrieve, summarize, or discard.
    • Dependencies: Privacy-preserving storage, accurate retrieval metrics, protection against stale or incorrect memories, and domain-specific evaluation. In healthcare or legal settings, human verification would remain necessary.
  • Model-agnostic agent improvement for organizations with limited training resources
    • Use case: Improve an agent built on a commercial API without access to model weights or permission to fine-tune them.
    • Why it is actionable: The paper demonstrates harness evolution with fixed proprietary-model weights.
    • Potential workflow: Maintain a controlled set of prompts, tool policies, and execution code while using API outputs and task scores to select improved variants.
    • Dependencies: API cost, rate limits, output reproducibility, terms of service, and protection of confidential prompts and data. Changes in the provider’s model version may invalidate evolved harnesses.
  • Academic research on self-improving agents
    • Use case: Use Evo as an experimental framework for studying the interaction between model learning and program-level self-modification.
    • Research applications: Compare weight updates with harness updates, study crossover between agent strategies, analyze recovery from malformed tool calls, and measure transfer across tasks.
    • Potential tool: A reproducible benchmark harness containing versioned agent trees, parent-selection policies, execution traces, rewards, and ablation controls.
    • Dependencies: Open implementations, fixed evaluation protocols, multiple random seeds, reporting of search and inference costs, and safeguards against overfitting to benchmark feedback.
  • Continuous regression testing for AI systems
    • Use case: Treat each harness modification as a candidate software release and automatically evaluate it against a suite of task, safety, latency, and cost tests.
    • Potential workflow: Evo proposes changes; the evaluation system checks functionality, security, cost, and performance; only candidates meeting release thresholds are promoted.
    • Potential product: An AI-agent continuous integration/continuous deployment pipeline with automated rollback and champion–challenger testing.
    • Dependencies: High-quality test coverage and multi-objective evaluation. Optimizing only task success could cause higher costs, privacy violations, unsafe tool use, or reward hacking.
  • Personal productivity assistants
    • Use case: Improve email drafting, calendar planning, file organization, research assistance, and task management through controlled evolution of tool-use and memory policies.
    • Potential benefit: The assistant could learn whether it should ask for clarification, retrieve prior context, use a particular tool, or verify an action before execution.
    • Dependencies: Explicit user approval for consequential actions, privacy protection, explainable change histories, and limits on autonomous access to email, finances, files, or smart-home systems.

Long-Term Applications

The following applications are plausible extensions of the framework but require additional validation, stronger safety mechanisms, larger-scale infrastructure, or domain-specific research.

  • Healthcare decision-support agents
    • Use case: Evolve clinical literature-search, patient-record summarization, coding, triage-support, or care-coordination workflows.
    • Possible evolved components: Retrieval pipelines, citation verification, uncertainty reporting, escalation rules, and structured interaction with clinical databases.
    • Why long-term: Clinical correctness is not captured adequately by simple task scores, and errors can cause harm.
    • Dependencies: Clinician-validated evaluators, privacy-compliant data handling, prospective trials, auditability, regulatory approval, and reward functions that prioritize safety over superficial answer quality.
  • Financial analysis and compliance agents
    • Use case: Optimize agents for financial document analysis, fraud investigation, risk reporting, customer support, and regulatory compliance.
    • Possible tools: Evolving retrieval and evidence-citation strategies, reconciliation workflows, exception handling, and cross-checking against authoritative records.
    • Why long-term: Financial outputs affect money, credit, and legal obligations; benchmark performance alone is insufficient.
    • Dependencies: Explainability, immutable audit logs, fairness testing, secure data access, human approval, and defenses against strategic behavior that maximizes a metric while violating policy.
  • Robotics and embodied agents
    • Use case: Evolve the software harness controlling perception, planning, tool use, recovery, and language interaction in warehouse, domestic, agricultural, or service robots.
    • Potential workflow: Candidate policies are tested in simulation, evaluated on task completion and safety, and then transferred cautiously to physical robots.
    • Why long-term: Physical environments are less reproducible than coding benchmarks, and failures can damage equipment or injure people.
    • Dependencies: High-fidelity simulation, safe exploration, hardware-in-the-loop testing, formal safety constraints, real-time guarantees, and sim-to-real validation.
  • Industrial control, energy, and infrastructure optimization
    • Use case: Improve agents managing energy scheduling, predictive maintenance, data-center operations, logistics, or industrial process control.
    • Potential product: A supervisory AI that evolves its planning and diagnostic workflow while keeping low-level safety controllers fixed.
    • Why long-term: The paper assumes that candidate systems can be repeatedly executed and evaluated; critical infrastructure often has slow, expensive, or hazardous experiments.
    • Dependencies: Digital twins, constrained optimization, fail-safe fallbacks, cybersecurity review, operator approval, and evaluation under rare but high-impact failure conditions.
  • Education and adaptive tutoring
    • Use case: Evolve tutoring-agent workflows for personalized explanations, misconception diagnosis, practice selection, and long-term learner memory.
    • Potential benefit: The agent could discover better sequences for hints, examples, feedback, and retrieval of prior student interactions.
    • Why long-term: Educational quality includes motivation, equity, developmental appropriateness, and learning gains over time rather than immediate answer accuracy.
    • Dependencies: Longitudinal studies, teacher oversight, age-appropriate safeguards, privacy protections for minors, and evaluation across demographic and linguistic groups.
  • Policy and public-sector service delivery
    • Use case: Improve government assistants for benefits navigation, form completion, public-information retrieval, translation, and case triage.
    • Potential benefit: Harness evolution could reduce failure rates in complex workflows without retraining a government-approved base model.
    • Why long-term: Public-sector systems must satisfy due-process, accessibility, transparency, and nondiscrimination requirements.
    • Dependencies: Public audits, human appeal channels, stable policy evaluators, records retention, accessibility testing, and prohibitions on autonomous decisions affecting eligibility or rights.
  • Autonomous research assistants
    • Use case: Build agents that improve workflows for literature review, experiment design, code generation, data analysis, and scientific hypothesis testing.
    • Potential product: A research platform that evolves its planning, retrieval, verification, and tool-use harness based on reproducibility and experimental outcomes.
    • Why long-term: Scientific objectives are often open-ended and difficult to score automatically; self-generated evaluations may reinforce incorrect or non-reproducible conclusions.
    • Dependencies: Independent verification, human researchers, provenance tracking, domain simulators, replication studies, and evaluators that distinguish novelty from correctness.
  • General-purpose lifelong personal agents
    • Use case: Develop assistants that continuously adapt their memory, planning, communication, and tool-use strategies to an individual over months or years.
    • Potential capabilities: Personalized scheduling, household coordination, learning support, travel planning, financial reminders, and cross-application task execution.
    • Why long-term: Long-lived agents accumulate sensitive data and can produce compounding errors or behavioral drift.
    • Dependencies: User-controlled memory deletion, permission boundaries, identity and access management, transparent version histories, periodic re-evaluation, and mechanisms for detecting harmful self-modification.
  • Safety and governance infrastructure for self-improving agents
    • Use case: Develop policy tools that require every evolved harness to pass safety, privacy, security, fairness, and reliability gates before deployment.
    • Potential tools:
    • signed harness versions and provenance records;
    • isolated execution sandboxes;
    • independent evaluator models;
    • adversarial red-team tasks;
    • rollback and kill-switch mechanisms;
    • multi-objective rewards that include cost and safety constraints.
    • Why long-term: The paper’s reward is primarily based on task-performance changes. Directly optimizing such a signal may encourage specification gaming, evaluator overfitting, or unsafe shortcuts.
    • Dependencies: Independent evaluators, robust threat models, formal or semi-formal constraints, human governance, and standards for documenting model and harness changes.
  • Cross-domain transfer of evolved strategies
    • Use case: Reuse general strategies such as error recovery, verification, context compression, and tool selection across coding, memory, research, and operational agents.
    • Potential product: A library of portable agent strategies that can be adapted through Evo’s crossover mechanism rather than rediscovered independently.
    • Why long-term: The paper demonstrates transfer across related coding benchmarks and from LoCoMo to LongMemEval, but broader transfer across domains may fail because task semantics, tools, and safety requirements differ.
    • Dependencies: Standardized harness interfaces, strategy representations independent of application-specific code, compatibility testing, and safeguards against transferring inappropriate behavior.

Overall, the most immediate opportunity is automated optimization of measurable, sandboxed agent workflows, especially coding and information-retrieval systems. Broader use in healthcare, finance, robotics, public policy, and autonomous personal systems depends on replacing single task-performance rewards with multi-dimensional evaluations covering safety, cost, privacy, fairness, robustness, and human oversight.

Glossary

  • Agent harness: An executable program that controls an agent’s prompts, tools, context, and execution flow. “A harness, hh, is the executable program that manages an agent's prompts, tools, context, and control flow.”
  • Autonomous Proposer trajectory: A recorded sequence of actions in which the Proposer independently modifies a harness. “One propose-evaluate-reflect-revise cycle provides an autonomous Proposer trajectory, a Reflector trajectory, and, when a revision is requested, a directed Proposer trajectory.”
  • Crossover searching: A search strategy that transfers and adapts useful mechanisms between different branches of a search tree. “We organize the search as a tree of harness variants and introduce crossover searching to combine useful strategies discovered on different branches.”
  • Directed editing: Modification of a harness performed according to an explicit directive generated by the Reflector. “Type A develops the ability to identify improvements independently; Type B develops the ability to turn feedback into working code.”
  • Edit diff: A representation of the changes made to a source program relative to an earlier version. “Let zpz_p contain the parent's evaluation records and z0z_0 contain the candidate's edit diff and execution feedback.”
  • Edit extraction: A recovery procedure that identifies concrete code changes in a rollout and converts them into an executable edit action. “Edit extraction handles rollouts that end without an explicit edit action: we search the recorded reasoning and chat messages for concrete file edits and convert them into the required action format.”
  • Evolver: The language-model policy responsible for improving an agent’s harness or behavior. “A LLM policy, ,servesastheevolver,actingasbothProposerandReflectorthroughdifferentroleprompts.”</li><li><strong>Executionfeedback</strong>:Informationproducedwhenacandidateharnessisrun,includingtraces,successes,failures,andtaskscores.“TheReflectorthenexaminestheexecutionfeedbackandrecommendsarevision,integrationofastrategyfromanotherbranch,orretentionofthecandidate.”</li><li><strong>Executionreward</strong>:Areinforcement−learningrewardbasedonthechangeintaskperformanceresultingfromaneditorintervention.“ForavalidProposereditfrom, serves as the evolver, acting as both Proposer and Reflector through different role prompts.”</li> <li><strong>Execution feedback</strong>: Information produced when a candidate harness is run, including traces, successes, failures, and task scores. “The Reflector then examines the execution feedback and recommends a revision, integration of a strategy from another branch, or retention of the candidate.”</li> <li><strong>Execution reward</strong>: A reinforcement-learning reward based on the change in task performance resulting from an edit or intervention. “For a valid Proposer edit from hto to h',andavalidReflectorinterventionfrom, and a valid Reflector intervention from h_0to to h_1$, the execution rewards are”
  • FP8: An 8-bit floating-point numerical representation used to reduce the memory and computational cost of model inference. “Our main experiments use Qwen3.8-27B, served in FP8 with greedy decoding, as the fixed task executor.”
  • Group relative policy optimization (GRPO): A reinforcement-learning method that compares multiple sampled responses for the same prompt using rewards relative to their group mean. “We then continue collecting experience from the evolving tree while training both roles with group relative policy optimization (GRPO)”
  • Greedy decoding: A decoding strategy that selects the highest-probability next token at every generation step. “Our main experiments use Qwen3.8-27B, served in FP8 with greedy decoding, as the fixed task executor.”
  • Harness evolution: The iterative process of modifying and evaluating the program that governs an agent’s operation. “Harness evolution proceeds through iterative tree search.”
  • Harness transfer: The use of an evolved agent harness on tasks or benchmarks different from those used during its evolution. “The evolved harnesses also transfer across benchmarks without further evolution.”
  • Held-out performance: Evaluation performance measured on data or tasks not used during training or selection. “Table~\ref{tab:self-evolution} reports the held-out performance of the best harness evolved by each method on each benchmark.”
  • Inference budget: A limit on the computational resources used while a model performs inference, such as token generation or model calls. “These results show that harness evolution improves how effectively the agent uses a fixed inference budget.”
  • Interleaved role training: A training procedure that alternates optimization between multiple roles implemented by the same policy. “We optimize a single policy for both roles.”
  • Interleaved SFT: A training arrangement in which supervised fine-tuning examples are incorporated across different roles or modes. “EvoTIDE uses supervised fine-tuning and interleaved GRPO to train a unified Proposer--Reflector model on evaluated edits and their outcomes.”
  • Mean F1: The average F1 score, a metric combining precision and recall, across evaluated examples or runs. “For memory tasks, we evolve harnesses on LoCoMo and report mean F1 on three held-out conversations.”
  • No-op edit: A proposed modification that produces no meaningful change to the program or its behavior. “No-op edits, unusable harnesses, and invalid crossover directives are also penalized.”
  • Parent pool: A maintained collection of candidate harnesses from which new evolutionary search branches are sampled. “A maintained parent pool exposes the policy to harnesses at different depths and performance levels”
  • Pass@1: The probability that the first generated solution for a task is correct. “We report held-out pass@1 on Polyglot tasks over three evaluation runs”
  • Policy optimization: Training a model’s decision policy by adjusting its parameters according to rewards or advantages. “We average the losses from the two role groups and take one update per sampled batch.”
  • Prefix continuation: A recovery method that resumes generation from the valid prefix of a partially failed sequence. “Prefix continuation handles a sequence of edits in which a later edit is invalid”
  • Proposer: The role that generates or implements modifications to an agent harness. “The Proposer writes harness edits, while the Reflector examines their execution outcomes and provides feedback for further revision.”
  • Reflector: The role that analyzes the outcome of a harness modification and recommends revision, crossover, or retention. “The Reflector identifies the strategy attempted by the Proposer, diagnoses remaining problems, and chooses one of three actions”
  • Reinforcement learning: A learning paradigm in which a policy is optimized using rewards obtained from its actions. “EvoTIDE uses these data for supervised fine-tuning followed by interleaved reinforcement learning.”
  • Resolved rate: The proportion of benchmark instances for which the agent successfully produces an accepted solution. “We report the held-out pass@1 on Polyglot tasks over three evaluation runs, the resolved rate on SWE-bench Verified instances”
  • Rollout: A generated sequence of model actions or responses during an interaction or task attempt. “An otherwise useful rollout may fail to produce an executable edit because of how the response is expressed.”
  • Self-evolving agent: An agent that improves its own model parameters, executable harness, or behavior using experience generated during operation. “Self-evolving agents offer a way to improve LLM systems through their own experience and without human intervention.”
  • Self-play: A training approach in which a system generates or evaluates its own tasks, solutions, or interactions. “Absolute Zero and R-Zero develop tasks and solvers through self-play”
  • Semantic voting: A method that aggregates judgments or outputs according to their meaning rather than exact surface-form agreement. “Other methods improve training signals through trajectory selection, semantic voting, or learned evaluators”
  • SFT warm start: Initial supervised fine-tuning used to provide a policy with useful behavior before reinforcement learning. “These trajectories support an SFT warm start, followed by interleaved GRPO across the two roles.”
  • Strategy library: A collection of mechanisms extracted from previously evaluated harnesses for possible reuse. “To make these discoveries available to the Reflector, we maintain a library S={sj}\mathcal{S}=\{s_j\} of strategies extracted from evaluated harnesses.”
  • Task executor: The fixed model or program that runs inside a candidate harness and performs the target task. “The task executor, denoted $M_{\mathrm{exec}$, runs inside each candidate harness and remains fixed during co-evolution”
  • Trajectory: A recorded sequence of prompts, model responses, actions, edits, and outcomes from an agent interaction. “For each evolution attempt, we record the role prompts, model responses, applied edits, parent and child harnesses, and task evaluation results.”
  • Trajectory recovery: The process of reconstructing usable training sequences from incomplete or invalid agent rollouts. “We further develop EvoTIDE, a training pipeline that recovers usable trajectories through edit extraction and prefix continuation”
  • Tree search: A search procedure that represents alternative candidates as nodes and their modifications as branches or edges. “Harness evolution proceeds through iterative tree search.”
  • Type A Proposer: The Proposer mode that independently selects and applies a modification to a parent harness. “In Type A, it receives a parent harness hph_p and its measured task performance, chooses a modification, and produces edits e0e_0 to obtain an initial candidate h0h_0.”
  • Type B Proposer: The Proposer mode that implements a specific revision directive supplied by the Reflector. “In Type B, it receives a harness and an explicit edit directive dd from the Reflector.”
  • Weight-harness co-evolution: Joint improvement of a model’s parameters and the executable harness that determines how the model operates. “We introduce Evo, a framework for weight-harness co-evolution in self-evolving agents”
  • Zero-shot transfer: Applying a learned or evolved capability to a new task without additional task-specific training or evolution. “The evolved harnesses transfer to different tasks without further evolution”

Open Problems

We found no open problems mentioned in this paper.

Tweets

Sign up for free to view the 6 tweets with 4457 likes about this paper.