Get Started
Home
Topics
Search
Library
Agents · Evaluation · Jul 31, 2026

DarwinX: Evolving Agent Harnesses Through Natural Selection

Source: research paper via Hugging Face Daily Papers
Hand-tuning an agent harness plateaus because every prompt edit that fixes one task silently regresses another. DarwinX evolves the harness around a frozen LLM, admitting a child only if it regresses nothing its parent solved, and merging losers — lifting a browser agent’s pass rate from 43.5% to 93.0%.
TL;DR
DarwinX keeps the base LLM frozen and evolves the agent’s harness (prompts, tools, control flow) as a population under a preserve-and-extend contract: a child is admitted only if it solves something new without regressing what its parent already solved, lifting a browser agent’s audit-clean pass rate from 43.5% to 93.0%.
Why It Matters
You’ve shipped a coding or browser agent. It works on 60% of your regression suite. You try tweaking the system prompt to fix the failing 40%, and now three tasks that used to pass are broken. You revert. This is the daily loop of anyone hand-tuning an agent harness against a real task distribution: every prompt edit that helps one task family silently regresses another, so you plateau early.
A growing body of work automates this loop by having the agent edit itself. The most prominent point of comparison is the Darwin Gödel Machine (DGM), which keeps an archive of self-modifying agent variants but mutates one parent at a time and scores each child only against that parent. Complementary specialists in different lineages never get recombined, and a win carries no obligation to hold what it displaces. DarwinX targets exactly that gap.
How It Works
The base model never trains. What changes is the harness around it: prompts, skills, tool code, and the agent’s control loop. DarwinX repeatedly proposes a small additive edit to that harness, runs the edited agent on a batch of tasks, and decides whether to keep the edit.
The promotion rule is the contribution. A child variant is admitted only if two conditions hold on measured per-task solve rates: net gain is positive (it wins somewhere) and total regression is bounded (it doesn’t lose too much anywhere). A verifier agent reads the trial evidence and either promotes or reverts. Promoted children face a stricter re-test at higher avg@k before they earn the right to steer future search. This two-speed design (permissive about trying an edit, strict about trusting it) keeps the tree moving without letting lucky rollouts accumulate.
Everything scored is kept in an archive, even losers, because a variant that loses overall may hold the one edit that combines with another branch to unlock a task neither solves alone. When variants solve complementary tasks, DarwinX merges their additive edits and keeps the merged child only if it covers the union of its parents’ wins. Proposals draw on three interchangeable signals: failure traces, a teacher’s successful trajectory, and contrast between the agent’s own passing and failing rollouts. None of them touch model weights.
for generation in range(N): parent = sample_parent(archive) # exploit high-gain, sometimes broaden signal = pick_signal(parent) # failure | teacher | self-contrast child = propose_edit(parent, signal, shared_memory) scores = run_avg_at_k(child, tasks) if net_gain(child, parent) > 0 and regression(child, parent) <= delta: archive.add(child) # provisional: can steer only after probe if complementary_specialists_exist(archive): merged = merge_edits(specialists) if solves(merged) >= union(solves(specialists)): archive.add(merged)
Core Insight
The prevailing approach to self-improving agents is a single lineage of keep-best edits, or an archive where each child is judged only against its parent. This paper shows the opposite. A child should earn its place not by beating its parent, but by refusing to regress anything the lineage already solved, while the archive keeps even the losers around as genetic material for later recombination. The load-bearing evidence isn’t the headline benchmark score. It’s that on TerminalWorld, the variant that best fits the in-loop selection signal is not the best generalizer, and the merged harness beats every individual specialist.
What They Found
The most telling result is the overfitting story on TerminalWorld. During evolution, the training-subset score saturates from 0.505 to 1.000, but held-out pass@1 is only 68.3%: a 31.7-point gap between the proxy the search maximizes and the truth it never sees. Four high-scoring specialists solve 24, 25, 26, and 27 of the 41 held-out tasks on overlapping but distinct subsets. The merged harness solves 28, above every specialist. That’s the mechanism the archive is for: greedily following the in-loop score would have collapsed to a single proxy-saturated harness.
Secondary evidence, all with the base model frozen:
•
Terminal-Bench 2.1: 75.5% → 83.2% on GPT-5.5 under the strict leaderboard rule (errored trials score zero); reaches 84.7% on GPT-5.6 Sol at medium effort, at the verified leaderboard frontier. An effort-controlled comparison rules out “just more compute”: a neutral harness at higher effort on the same base scores only 78.0%. The extra compute is targeted, roughly doubling turns on the six newly solved tasks and barely moving on the 69 already-solved ones.
•
WebArena-Infinity (WAI): audit-clean pass@1 rises 43.5% → 93.0% after evolving only on 300 synthetic intents (LLM-judged) and evaluating on 1,260 real tasks (deterministic verifiers). Every application improves. Invalid trajectories drop from 293 to 17, and evaluation-plane, privileged-host, and exploit mechanisms disappear entirely: capability and compliance improve together.
•
Cross-benchmark transfer: the best Terminal-Bench 2.1 harness, run unchanged on all 500 SWE-bench Verified issues, scores 84.2% with no in-domain feedback, +3.4 over a fix-skill reference.
•
What the search actually discovered: the evolved harness adds seven skills, all in one family, verification and artifact-contract behavior (establish an explicit acceptance condition, check the rendered state and the persisted state before finalizing). No domain knowledge was added.
What’s Useful
Reach for this when you’re maintaining an agent against a fixed regression suite that returns binary pass/fail per task, and you’ve hit the wall where prompt or tool edits keep trading wins for losses. The recipe: score every candidate edit with repeated sampling (the paper uses avg@3 to screen, avg@5 to confirm), admit an edit only if per-task regression stays within a bounded budget, and keep every scored variant, including losers, because merging specialists later is often where the real gain lives. The verifier is whatever your CI or test suite already provides. No gold solutions are needed.
The paper is from Salesforce AI Research and evolves their proprietary agent Monet, so the DarwinX code and evolved harnesses are not released as an open artifact in the paper. The benchmarks used (Terminal-Bench 2.1, TerminalWorld, WebArena-Infinity, SWE-bench Verified) are all public. If you want to reproduce the selection loop, you’d be reimplementing from the algorithm description; the paper doesn’t link a repository.
Takeaway
Judge every agent edit against what your system already solves, not just against what it newly solves; keep the losers, because the specialist that fails alone is often the one that recombines into a winner.
Caveats
•
The system is evaluated as a whole. The archive, parent selector, merge operator, and confirmation probe are not independently ablated, so the paper cannot say which piece contributes how much. The verification-and-contract skill family that recurs across benchmarks is offered as a plausible explanation, not a causal one.
•
Cross-benchmark transfer is measured in one direction only (Terminal-Bench 2.1 → SWE-bench Verified) and the transferred gain is small (84.2% vs an 80.8% fix-skill reference), far below the in-domain lifts. Don’t expect a harness evolved on one benchmark to be a general-purpose upgrade.
•
The whole approach requires a task-level verifier that returns binary pass/fail cheaply and repeatedly (avg@5 means five rollouts per candidate per task). In production settings where verification is expensive, human-in-the-loop, or unavailable, the selection signal collapses and the method has nothing to promote against.
Topics
Don't miss new content
Log in to follow topics and personalize your feed.
By content type
Research Paper171 episodes
AI171 episodes