DarwinX: Evolving Agent Harnesses Through Natural Selection

Yifan Zhang, Yutong Dai, Juntao Tan, Luyu Yang, Rishi Mullur, Thai Hoang, Zhiyuan Hu, James Zhu, Phil Mui, Silvio Savarese, Ran Xu, Zeyuan Chen

DarwinX evolves agent harnesses via population-based selection, turning frozen models into durable, general-purpose agents.

How can we evolve LLM agent harnesses (prompts, tools, control flow) to improve performance without retraining the underlying model?

Modern LLM agents rely on harnesses—prompts, tools, and control flow—that are often brittle and prone to regression when updated. Single-lineage self-improvement loops frequently plateau or trade one capability for another, failing to accumulate general competence across diverse task distributions. DarwinX treats self-evolution as a population-based selection problem rather than a training task. It maintains an archive of harness variants and uses a "preserve-and-extend" contract to admit only edits that solve new tasks without regressing existing ones, recombining complementary specialists to build durable capabilities. On Terminal-Bench 2.1, this approach reaches the verified frontier at 84.7% pass rate, while on WebArena-Infinity, it lifts audit-clean performance from 43.5% to 93.0%—all while keeping the underlying model weights frozen.

Paper Primer

DarwinX functions as an evolutionary optimizer for agent scaffolds: it treats the harness as a mutable artifact and the agent's performance as a fitness signal. The core move is a two-speed selection loop: a permissive "enabler" admits promising variants into the archive, while a strict "preservation probe" confirms which variants earn the right to steer future search.

DarwinX achieves frontier-level performance on Terminal-Bench 2.1 using only harness evolution.

The evolved harness on a frozen GPT-5.5 base reaches 83.2% avg@5, matching frontier agents like Codex and outperforming the base Monet agent by 7.7 points. +7.7 percentage points improvement on a frozen base model.

Evolved harnesses demonstrate robust generalization across modalities and task distributions.

The harness evolved on synthetic WebArena-Infinity intents transfers to 1,260 real-world tasks, achieving 93.0% audit-clean pass@1, a 49.5-point gain over the base agent. 49.5 percentage point gain on held-out real-world tasks.

Why use a population-based archive instead of a single-lineage update loop?

Single-lineage search is path-dependent and prone to cross-task interference, where fixing one task regresses another. DarwinX retains all variants, allowing it to merge complementary specialists that solve different task subsets, preventing the search from collapsing into a single, brittle local optimum.

Does the performance gain come from the harness or simply from increased test-time compute?

The gain is harness-specific. Controlled comparisons show that neutral harnesses at higher effort settings fail to match DarwinX's performance, and the additional compute DarwinX uses is targeted specifically at tasks where the agent previously failed, rather than being applied uniformly.

The Agent Harness Bottleneck

We expose why static harnesses and single‑lineage search limit LLM agents.

LLM agents rely heavily on their harness—prompts, tools, skills, and control flow—yet most self‑improvement systems edit this harness in a single‑lineage fashion. Such single‑lineage search is path‑dependent: early edits bias later ones and cause the process to plateau. Moreover, edits that improve performance on one task often regress on others, leading to cross‑task interference.

A harness is the collection of prompts, tools, skill definitions, and control‑flow logic that mediates a frozen LLM’s behavior.

**Figure 1.** With the base model frozen, evolving the harness alone matches or beats the strongest prior agent on four benchmarks. Left: variants survive on measured fitness (avg@k, no gold solutions) and complementary survivors are merged. Right: bars within a panel share one frozen model; the hatched bar is zero-shot transfer of the Terminal-Bench 2.1 harness. y-ranges are truncated and differ per panel.

Table 1 positions DarwinX among prior prompt‑optimization methods, showing it uniquely supports tools, control flow, population archives, cross‑lineage merges, bounded regression, noise‑aware avg@k, and both teacher and self signals. Table 7 further contrasts agent‑optimization approaches, emphasizing DarwinX’s archive of typed nodes and preservation probe for managing cross‑task interference. Across the four benchmarks—Terminal‑Bench 2.1, TerminalWorld, WebArena‑Infinity, and SWE‑bench Verified—the evolved harness consistently raises performance, illustrating why single‑lineage search fails.

Single‑lineage search fails because early edits lock the search trajectory and because improvements on one task can silently degrade others.

The DarwinX Evolutionary Loop

DarwinX evolves static harnesses via population selection, preserving gains while exploring new edits.

DarwinX treats agent improvement as evolving the harness around a frozen model: it repeatedly proposes tiny edits, tests them on real tasks, and keeps only those that add new solves without breaking existing ones.

Parent solve vector: $(1.0, 1.0, 0.0)$.

Child solve vector after edit: $(1.0, 1.0, 1.0)$.

Per‑task changes $\Delta_t = (0, 0, +1)$.

Net gain $g = +1$ and regression $R = 0$ (no loss).

Since $g>0$ and $R\le\delta$, the child is admitted to the archive.

The example shows how a single additive edit can increase coverage without any backward loss, satisfying the Preserve‑and‑Extend contract.

How does DarwinX differ from simple hill‑climbing where each edit replaces the previous one?

Hill‑climbing discards the old solution and keeps only the latest edit, so capabilities trade off. DarwinX records every edit in an ever‑growing archive, allowing later merges to combine complementary edits from different branches.

The contract forces a child harness to improve on at least one task while losing no more than a tiny tolerance of its parent’s solves, ensuring that progress never erodes existing capability.

$\Delta$ for $A$: $0$, for $B$: $-0.1$, for $C$: $+1$.

Net gain $g = (+1) + (0) + (-0.1) = +0.9$.

Bounded regression $R = \max(0,-0.1) = 0.1$.

Since $g>0$ and $R=0.1\le\delta$, the child passes the contract.

The verifier promotes the child, which is later re‑tested before influencing the archive.

The contract tolerates a tiny loss on an already‑solved task, allowing the child to bring in a brand‑new capability.

Why not simply require zero regression ($R(c)=0$) instead of a tolerance $\delta$?

Zero regression would reject many edits that introduce a new solve but cause a negligible drop on a noisy task, starving the search of useful diversity. The small tolerance $\delta$ absorbs measurement noise while still protecting core capabilities.

The archive is a tree of harness snapshots; each node records the additive edit that created it and the tasks it solves, preserving both winning and losing variants for later recombination.

Merge creates $\Delta = \Delta_1 \oplus \Delta_2$.

Apply $\Delta$ to the common ancestor $H_0$, yielding child $H$.

Child $H$ solves $\{A,B\}$, covering the union of $v_1$ and $v_2$.

Since $S(H) \supseteq S(v_1)\cup S(v_2)$, the merge is accepted.

The new node $H$ is added to the archive with lineage gain $G(H)=G(v_1)+G(v_2)$.

Even though neither $v_1$ nor $v_2$ alone could solve both tasks, their additive edits combine to produce a more capable harness.

Why keep a variant that solves fewer tasks than its parent?

Such a “stepping‑stone” variant may contain an edit that, when merged with another complementary variant, yields a harness that solves both tasks. Discarding it would eliminate the genetic material needed for that synergy.

**Figure 2.** DARWINX’s selection loop with the model frozen. **Left:** the preserve-and-extend contract. **Middle:** the archive of alternative lineages. **Right:** shared memory carried across generations.

**Figure 3.** DARWINX’s per-generation operators. **Left:** the mutation loop and the three learning signals that drive it. **Middle:** variants classified by how their solved set changes, where those preserving inherited solves stay eligible for recombination while the rest contribute only distilled lessons. **Right:** the merge operator and its acceptance criterion.

Measurement and Audit Standards

Evaluation design quantifies DarwinX’s harness gains across five benchmarks.

DarwinX is evaluated on an 89‑task suite, covering diverse domains.

The evaluation uses the 89‑task suite described in RQ1–RQ4.

The Audit‑Clean Pass Rate measures the fraction of candidate harnesses that survive repeated measurement without being flagged as failures.

How does the Audit‑Clean Pass Rate differ from a simple success rate?

Success rate counts any single pass, even if due to a lucky rollout; Audit‑Clean requires consistent performance across repeated measurements, filtering out noise.

Measurement uses binary avg@k throughout, treating agent timeouts as real failures while separating infrastructure glitches. A preservation probe re‑samples known solved tasks before promoting a child, ensuring that local wins survive the same regime as final selection.

In-Domain Performance Gains

DarwinX evolves a frozen model’s harness to achieve state‑of‑the‑art performance on TerminalBench 2.1.

TerminalBench 2.1 evaluates agents on 89 tasks using a binary pass‑rate and the avg@5 metric.

DarwinX achieves state‑of‑the‑art performance on TerminalBench 2.1, surpassing the previous verified leaderboard leader by +2.9 points.

84.7 % avg@5 versus the next best verified entry at 81.8 % (OpenAI reference) and 83.8 % (Claude Code).

It is a suite of 89 short‑answer tasks where each run is judged by a binary pass‑rate and the average success over the top‑5 attempts (avg@5).

**Table.** Comparison of agent performance on the leaderboard.

**Figure 4.** Where evolution helps. This figure breaks the improvement down by assigning each of the 89 tasks to a capability cluster and comparing base vs. evolved pass-rate per cluster.

**Figure 5.** Per-task compute on TerminalBench 2.1 (median over clean attempts). The evolved harness spends its extra turns and tokens on the six tasks it newly solves; compute on already-solved tasks barely moves.

Generalization and Archive Diversity

Monet (DarwinX) markedly outperforms baselines on held‑out TerminalWorld tasks.

Monet (DarwinX) on Opus 4.8 achieves the highest held‑out pass@1 (68.3 %) on TerminalWorld, surpassing all baselines.

Table 3 shows Monet (DarwinX) solving 28 of 41 held‑out tasks (68.3 %) versus the next best Opus 4.8 at 65.9 %.

Other agents trail behind: Opus 4.8 reaches 65.9 %, Claude Code and the base Monet each hit 61.0 %, GPT‑5.5 scores 58.5 %, Terminus‑2 56.1 %, and Codex 48.8 %.

**Table 3.** TerminalWorld held-out pass@1 (41 tasks, single attempt).

**Figure 6.** Held-out generalization reflects archive diversity: four evolved specialists each solve a different subset of the 41 tasks, and the merged Monet (DARWINX) exceeds every specialist and Claude Code (dashed).

Real-World Generalization

DarwinX’s evolved harness boosts audit‑clean pass@1 to 93.0%, a 49.5‑point gain over the base.

Recall that DarwinX evolves static harnesses by preserving successful variants while exploring new ones. Here we test whether that evolution transfers from synthetic intents to the real‑world WebArena‑Infinity (WAI) benchmark.

Monet (DarwinX) reaches 93.0% audit‑clean pass@1, a 49.5‑point improvement over the base harness.

Table 4 shows the per‑application audit‑clean pass@1 scores, with the overall row rising from 43.5% (base) to 93.0% (DarwinX).

**Figure 9.** Per-application success on the real WAI suite, raw pre-audit (left) vs. audit-clean (right). The audit collapses the base’s inflated successes (53.0→43.5%) while leaving Monet (DARWINX) nearly unchanged (94.4→93.0%).

**Figure a.** Best-so-far screening score over accepted generations.

Ablation and Mechanism Analysis

We isolate which harness changes drive the observed performance gains.

To understand why DarwinX’s evolved agents outperform the base, we run a series of ablations that remove individual harness components and measure the impact.

**Figure b.** Archive lineage tree (node size $\propto$ screening score).

The TB2.1‑specialized harness transfers to the SWE‑V benchmark, achieving 84.2% pass@1.

On 500 SWE‑V issues the harness scores 421/500, a +3.4‑point improvement over the 80.8% fix‑skill reference.

On the WebArena‑Infinity benchmark the audit‑clean metric improves by 49.5 points (43.5%→93.0%).

This large jump confirms that the same population‑based selection loop works across domains.

The evolved harness adds a cohesive set of verification‑oriented skills that let the agent establish contracts, check artifacts, and ground outputs in real tools.

How do these verification skills differ from a standard test‑case checker?

Typical checkers only validate final outputs; the evolved skills first derive an explicit acceptance contract, then iteratively verify intermediate artifacts and enforce security constraints before finalizing.

Clusters where the base agent already performed well (system administration, security) show negligible change, confirming that the gains are concentrated where the base had the most headroom.

Related Work

We position DarwinX among prior work, highlighting its unique harness evolution and evaluation policies.

SWE‑V is a transfer and diagnostic benchmark; the official scores across the harnesses we compare range from 80.8 % to 84.2 %.

Our WebArena‑Infinity (WAI) policy permits client‑visible observation and semantic application operations but rejects privileged knowledge, evaluation‑plane access, raw‑state fabrication, database manipulation, and exploits.

The resulting static‑plus‑LLM audit is far stronger than a keyword heuristic, yet it is not a formal sandbox; consequently we report both raw and conservative audit‑clean scores.

Freezing the base model isolates the effect of the harness, making the observed deltas attributable to harness changes rather than to model updates.

Appendix E sketches extensions that become possible when the base model is frozen: coupling harness selection with weight updates, treating the harness as an asset that outlives a generation, and using a preservation probe to guarantee that deployments never regress.

DarwinX draws on three established lines of work—optimizing a designated artifact, evolving the agent’s executable scaffold, and selecting candidates under noisy evaluation—and we discuss each in turn.

Prompt, workflow, and skill optimization families treat prompts, graphs of fixed components, or external libraries as learnable, but the optimizer itself never improves and the harness remains static; DarwinX retains the inner loop while making the harness the learnable component.

Self‑evolving agents edit the executable scaffold: meta‑agent regimes such as ADAS and HarnessX revise target agents, while self‑referential regimes like the Success‑Story Algorithm, Gödel machine, STOP, Gödel Agent, SICA, and Live‑SWE‑agent compound task improvements into better self‑modification.

DGM adds an open‑ended archive with stochastic selection, further expanding the design space beyond deterministic harness evolution.

Discussion and Limitations

We examine the limits of our evidence, cross‑benchmark transfer, and attribution uncertainties.

The preserve‑and‑extend rule (Section 2) expands fragile clusters while keeping solved ones fixed, revealing that the remaining difficulty is procedural—long dependency installs, environment setup, output verification, and multi‑step tool use—rather than a lack of knowledge.

Cross‑benchmark checks on WebArena‑Infinity (WAI) show the evolved browser harness adds the same state‑and‑action contracts, dropping the confirmed‑invalid rate from 23.5% to 1.4% and lifting audit‑clean pass@1 by 49.5 points, especially on state‑changing applications (Section 6).

TerminalWorld emphasizes diversity: individual specialists solve 24–27 held‑out tasks, and the merged harness solves 28, demonstrating that the archive supplies complementary behaviors even when ranking on the training subset is noisy.

These observations suggest that verification‑before‑finalization and contract‑aware tool use constitute a plausible shared mechanism across benchmarks, rather than a per‑skill causal effect.

The strongest matched‑model evidence comes from TB2.1 (75.5 → 83.2%) and WAI (43.5 → 93.0% audit‑clean) with GPT‑5.5 frozen; TerminalWorld adds a disjoint held‑out set where the evolved harness reaches 28/41.

Cross‑benchmark transfer is measured only in one direction: a TB2.1‑evolved harness attains 84.2% on SWE‑bench Verified, a gain that is far smaller than the in‑domain improvements.

Selection quality hinges on proposed diversity; the archive and merge machinery can preserve variants, but population search requires diverse wins before inheritance becomes useful, and the contribution of recombination versus single‑lineage mutation still needs controlled ablation.

Attribution limits arise because the experiments evaluate the entire DarwinX system—archive, parent selector, recombination operator, and inference effort—without independent randomization, so matched‑model deltas support a system‑level harness claim while individual operator effects remain plausible rather than causal.

TerminalWorld’s held‑out suite contains only 41 tasks; a single solve shifts pass@1 by 2.4 points, and the McNemar test ($p=0.45$) indicates the observed improvement is not statistically significant.

Conclusion

The conclusion highlights DarwinX’s gains, noisy evaluation handling, and remaining open accounting questions.

DarwinX leverages a preserve‑and‑extend contract, an archive of alternative lineages, and a signal interface to evolve harness variants for frozen‑model agents. Across four evaluation regimes it delivers roughly a 17‑point average improvement, e.g., WebArena‑Infinity audit‑clean pass@1 jumps from 43.5 % to 93.0 % and invalid trajectories drop from 293 to 17. The authors note that internal accounting of the archive, selector, and merge operator remains unisolated, leaving this as an open limitation.

Appendix: Method Positioning

Appendix details methods, evaluation protocols, and additional data tables.

Table 7 expands the summary marks of Table 1 into the concrete mechanism each method uses. It contrasts two families: optimizers that improve a single artifact under a fixed outer loop, and agents that edit their own executable scaffold. The rows show that DarwinX differs mainly in how candidates are searched, promoted, and retained, rather than in what it edits.

Table 8 lists the protocol for each benchmark: which base model is frozen, what data drives evolution, what data is reported, and the selection signal. Two conventions apply across all benchmarks: an open‑ended archive with stochastic single‑parent mutation and no merge operator, and a staged single‑lineage pipeline where variants remain isolated.

Table 9 reports TerminalWorld held‑out results before and after retrying infrastructure‑error trials. All specialists gain resolved tasks after the retry, while the DarwinX‑evolved harness remains unchanged at 28 resolved tasks, demonstrating its inherent robustness to infrastructure failures.

Section D.1 describes how the 300 synthetic intents for the WebArena‑Infinity (WAI) evolution split are built. Seeds are generated from application documentation, expanded by two frontier models, filtered through quality heuristics, duplicate removal, and TF‑IDF pruning, then balanced across 12 served applications to obtain the final 300‑intent set.

Section D.2 details the anti‑cheating detection pipeline. It defines a validity rubric that accepts UI clicks, app‑owned state reads, and documented product APIs, while rejecting privileged host knowledge, evaluation‑plane access, raw‑state fabrication, direct database manipulation, and exploit‑based actions. The pipeline combines a static analyzer with an LLM judge to label trajectories as Valid, Invalid, Invalid‑Attempted, or Review.

Section D.3 provides baseline provenance and raw results. It explains how Monet (base) and Monet (DarwinX) are matched runs on the same frozen GPT‑5.5 model, establishing the controlled measurement behind the reported +49.5‑point gain. It also notes that audit‑clean scores dramatically reduce inflated successes for other agents, widening the performance margin.

Two observations follow from Table 9: (1) the retry policy lifts every specialist by 5–10 resolved tasks but leaves the DarwinX harness unchanged, confirming its superior infrastructure robustness; (2) a separate skill‑bundled reference also reaches 28 / 41, clarifying that the TerminalWorld claim concerns the archive‑plus‑preservation selection, not a universal search boost.

**Table.** Classification of operations as Admissible or Inadmissible.

**Table 14.** The evolved browser prompt replaces an absolute UI-only rule with a bounded semantic fallback and persistence verification.

This table compares "Base prompt (before)" and "Evolved prompt (after)" across two aspects: "Interaction policy" and "Finishing (verification)".

**Figure 8.** Invalid trajectories before vs. after evolution, by application (left) and mechanism (right). Evolution cuts invalid trajectories from 293 to 17, leaving only raw-state mutations.

This table outlines the experimental setup for four benchmarks: TB2.1, TerminalWorld, WAI, and SWE-V (transfer). It details the "Frozen base" model used, the "Evolution data" source, the "Report data" used for evaluation, the "Selection signal" mechanism, and the "Report metric" for each benchmark.

**Table 9.** TerminalWorld held-out results before and after infrastructure-error retries. Cells report resolved tasks / errored trials.

**Table 11.** Regex patterns used to detect invalid state access or mutation.

This table lists three regex patterns used to identify specific application behaviors or data interactions.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers