Evo: Evolving the Evolver through Weight-Harness Co-Evolution
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, 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 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 across domains and its broad transferability across models and tasks.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
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:
- Changing its “brain” — updating the model’s internal settings, called its weights.
- 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:
- The AI changes its harness.
- The changed harness is tested.
- The results show what worked and what failed.
- Those results train the AI to become a better improver.
- 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, , 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 contain the parent's evaluation records and 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, hh'h_0h_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 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 and its measured task performance, chooses a modification, and produces edits to obtain an initial candidate .”
- 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 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”

