How does Evo 2 co-evolve model weights and agent harness for self-improvement?

Co-evolution joins two loops that ran apart

Self-evolving agents improve a language model system without human intervention, and the paper separates two existing routes. Weight-update methods let a model generate solutions, keep the useful ones using task feedback, and train on them. Harness methods instead rewrite the executable program that governs how an agent uses prompts, tools, context, and execution feedback. The paper's claim is that running these routes separately misses a two-way dependency: the model's capabilities shape which harness edits it proposes and how it reads execution feedback, while each evaluated edit reveals which changes help, why an edit fails, and how improvements interact.

Evo 2 makes that dependency the mechanism. A better evolver builds better harnesses, and the edits and outcomes from those harnesses train a better evolver. The task executor, the model that actually runs inside each candidate harness, stays fixed during co-evolution, so a candidate's measured performance reflects the harness change rather than a change in the executor. That design choice is what lets the authors attribute score differences to harness edits.

One policy writes edits and diagnoses them

The harness side runs as a tree search over harness variants. Each node stores a harness and its task evaluation records, and each edge records the edits made to its parent. At each iteration the system samples a parent, applies a Proposer edit, and evaluates the candidate. The Reflector then reads the candidate source, the diff against its parent, the change in task performance, and execution traces from relevant successes and failures, and chooses one of three actions: revise with a concrete directive, crossover to import a strategy from another branch, or keep the candidate unchanged.

The Proposer has two modes that train different skills. In Type A it receives a parent harness and its measured performance and decides on a modification itself, which develops independent improvement. In Type B it receives an explicit directive from the Reflector and must turn that feedback into working code. Both roles are implemented by the same model parameters under different role prompts, so proposing edits and judging them are learned by one policy rather than two separate agents.

Crossover searching addresses the fact that different branches may find complementary improvements. The system keeps a library of strategies extracted from evaluated harnesses, each describing a mechanism, its observed effect, and whether it already exists in the current candidate. The Reflector can pick a donor strategy that targets a weakness exposed by execution, and the Type B Proposer adapts it to the recipient's source. The combined harness is then evaluated, so an imported strategy is kept only if the integration actually helps.

EvoTIDE recovers failed rollouts as training data

EvoTIDE converts search activity into training data for the shared policy. Each propose-evaluate-reflect-revise cycle yields an autonomous Proposer trajectory, a Reflector trajectory, and, when revision is requested, a directed Proposer trajectory. The pipeline first collects an initial dataset and runs supervised fine-tuning, then keeps collecting experience from the evolving tree while training both roles with group relative policy optimization, or GRPO, a reinforcement method that compares a group of responses to the same prompt against their group mean reward.

Two recovery procedures matter because a rollout can be useful yet fail to produce an executable edit. Edit extraction searches recorded reasoning and chat messages for concrete file edits and converts them into the required action format when a rollout ends without an explicit edit. Prefix continuation handles a sequence of edits where a later one is invalid: the rollout is truncated after the last successfully applied edit, the intermediate harness is restored, and generation resumes from that prefix. Recovered proposals still pass the same application, startup, and task evaluation checks before entering training data.

Training interleaves the two roles. Each optimization step uses a Proposer group and a Reflector group with advantages computed separately per prompt, and both updates change the live parameters while a frozen snapshot supplies the counterpart calls. After a round, the snapshot is refreshed and new cases are collected. The authors also balance modes: Type A and Type B Proposer prompts are interleaved, and half of Reflector inputs are sampled with an empty strategy set so the model keeps a useful diagnosis even when donor information is unavailable.

Gains hold across three coding benchmarks

The main experiments use Qwen3.8-27B served in FP8 with greedy decoding as the fixed task executor, and the same model as the evolver: the untrained base model for baselines and the EvoTIDE-trained model for Evo 2. Baselines are four self-evolving frameworks, SICA, DGM, HGM, and GEA, each using the untrained model as its evolver and its own selection rule. Reported numbers are held-out performance of the best harness each method evolved on that benchmark.

On Polyglot, Evo 2 reaches 82.1% pass@1 over three evaluation runs, against 62.6% for the strongest baseline, GEA. On SWE-bench Verified it resolves 48.3% of held-out instances, against 41.0% for HGM. On LiveCodeBench it reaches 58.0% pass@1 while the four baselines range from 39.0% to 56.0%. These are three different metrics on three different task sets, so the comparison that matters is within each column, not a single averaged improvement.

Evolved harnesses transfer without further evolution

The transfer test takes the best harness each method evolved on one coding benchmark and evaluates it on the other two, with no further evolution, producing six source-target directions. Evo 2 achieves the best transfer performance in five of the six directions. This separates two outputs of co-evolution: weights that encode how to improve a harness, and harnesses that already contain the improvements found during search.

The distinction matters for anyone deciding what to reuse. A trained evolver can run the same search procedure on a new initial harness given an evaluator for its tasks, while an evolved harness can be deployed directly on new tasks with compatible model and tool interfaces. The transfer results speak to the second path, and they are measured on coding benchmarks only, so they do not by themselves establish transfer to unrelated task families.

Fixed proprietary models also benefit from the dual-role search

The dual-role harness framework is not limited to settings where the evolver's weights can be updated. In the proprietary-model experiments, GPT-5-mini and Claude Haiku 4.5 each serve as both executor and evolver with weights fixed throughout evolution, and evaluation uses a 60-task SWE-bench Verified subset. Under this setup the framework improves a GPT-5-mini agent's performance from 24.4% to 48.3%.

This result should be read on its own terms. It shows that the harness-improvement half of Evo 2 can operate when weight evolution is unavailable, but it does not test EvoTIDE's training pipeline, because those weights never change. The 48.3% figure here comes from a 60-task subset, not the full SWE-bench Verified evaluation used in the main coding experiments, so the two 48.3% numbers are not the same measurement.

Where the co-evolution claim carries the most weight

The paper's own analyses report that weight evolution improves search reliability and that crossover searching reduces the evaluation budget needed to reach strong performance. Those two findings locate the practical value of Evo 2 less in any single benchmark score than in how efficiently search converts into a usable harness and a better evolver. The memory-domain experiments, on LoCoMo with mean F1 over three held-out conversations and on LongMemEval-S with accuracy over 500 instances judged by GPT across three runs, extend the applicability claim beyond coding.

The priority this evidence supports is a split by what a reader wants to reuse. If the goal is a harness for a fixed model and tool interface, the transfer results in five of six coding directions are the relevant evidence, and they are bounded to coding benchmarks. If the goal is an evolver that keeps improving harnesses on new tasks, the relevant evidence is the weight-evolution and crossover analyses, which the paper reports as improving search reliability and lowering evaluation cost rather than as a fixed score threshold. The proprietary-model result sits outside both, since it exercises only the harness half of the framework.

Sources used in this answer