FreeEvolveLearning to Evolve Beyond Fixed Loops

The search loop is still designed by hand

An evolver runs a target agent, reads its failures and edits its harness. Around that edit step sits a loop that someone wrote in advance.

The loop decides which tasks are evaluated, how often a measurement is repeated, how candidates are compared and when the search stops. Each choice encodes a guess about evaluation noise, task difficulty, useful curricula and available parallelism. Those guesses differ across agents and environments, and they go stale as evidence arrives. An evolver that only proposes edits cannot act on what it learns, so adapting the loop means re-engineering it by hand.

FreeEvolve moves each of those decisions inside the evolver.

Autonomy alone is not enough

Handing over control does not by itself produce a good campaign. With the hand-written seed skill, the evolver improves a fresh worker by at most 1.1 points. After meta-evolution, the frozen skill improves fresh workers by 2.2 to 13.8 points, and the skill learned on τ³-bench also improves ARC-AGI-2 and ARC-AGI-3.

One invocation, two levels

A conventional evolver framework calls a proposer at fixed stages and keeps control of evaluation, selection and stopping. FreeEvolve invokes the evolver once, and the evolver stays in control until it returns an improved target.

The same interface works at two levels. At the agent level, the evolver improves a worker. At the meta level, the editable target is the evolution skill itself, and each candidate skill is judged by the workers its campaigns produce.

Scroll sideways to see the whole figure.

A bounded environment

Giving control to the evolver needs a clear boundary. Inside it the evolver can explore however it likes, but it cannot change the goal, the evaluation rules or the resource limits. An environment initialized with target \(x_0\) is

• \(g\)the improvement goal
• \(\mathcal{D}\)the evolution data, e.g. the evolution split of a benchmark
• \(x_0\)the initial editable target, e.g. the worker harness
• \(R_{\mathcal{E}}\)runs candidate \(x\) under request \(u\) and returns an artifact bundle \(a = R_{\mathcal{E}}(x, u)\): scores, trajectories, logs
• \(\mathcal{C}_{\mathcal{E}}\)the valid requests: benchmark rules and resource caps

The request \(u\) is where autonomy lives. The evolver picks which tasks to run, how many repetitions and seeds, and how much concurrency and time each execution gets. A prescribed loop fixes \(u\) before the run, so its evolver only ever sees \(R_{\mathcal{E}}(x)\) under one setting.

The evolver runs the whole campaign

The evolver is Claude Code equipped with a single markdown file of instructions, the evolution skill \(s\). A complete campaign is one call:

The framework provides access to \(R_{\mathcal{E}}\) and takes no further role. The evolver decides which candidate to edit, which request to issue, how the returned artifacts change its next move and when to return \(x^\star\). Stable measurements let it move on, close comparisons justify more repetitions, and failures concentrated in one part of the data can be searched there before a candidate is validated broadly.

Meta-evolution learns the campaign policy

Because the skill is a text file, meta-evolution needs no new machinery. A meta-environment makes the skill the editable target and uses worker environments as its data, \(\mathcal{D}^{\mathrm{m}} = \{\mathcal{E}^{\mathrm{w}}_i[w_i]\}_{i=1}^{n}\). A candidate skill has no score of its own. It is installed in an evolver, runs complete worker campaigns, and is judged by the workers and traces they produce:

The outer evolver edits \(s_0\), decides which inner campaigns to launch and reads their outcomes as feedback. \(s_{\mathrm{outer}}\) and \(s_0\) start as separate copies of the same seed, so editing the candidate never changes the controller. Meta-environments are excluded from their own data, which bounds nesting at two levels. The result is a frozen skill that can be installed in new environments without carrying over any source worker or campaign state.

What the evolver actually sees

One call to evolve.sh installs an environment in a fresh run directory and invokes the agent once. The meta-environment uses exactly the same layout.

$ ./evolve.sh --env arc_agi_3
run/
├── ENVIRONMENT.md    # goal, data, limits, how to read results
├── .target           # the editable surface x₀
├── run.sh            # R(x, u): run a candidate under request u
└── workspace-<env>/  # candidates, artifacts, notes (starts empty)

Stronger workers than hand-designed evolvers

We compare against GEPA, OpenEvolve and EvoX (SkyDiscover settings) and HyperAgents (default settings). Every method searches only on the evolution split, picks its final worker by its own rules, and only then is the held-out split revealed. Each returned worker is evaluated on held-out tasks three times.

FreeEvolve improves the primary held-out metric by 13.6 points on average and has the best result on six of seven metrics. It also matches or beats EvoX and HyperAgents, which meta-evolve their own search procedures. Moving the target of meta-evolution from a specific search loop to the organization of the campaign pays off.

Terminal-Bench 2.1 is the exception: FreeEvolve has the best pass@3 but trails GEPA on mean score. Terminal evaluation is CPU-heavy, and a shared concurrency setting causes blocking and uneven throughput that the environment does not yet expose to the evolver.

Meta-evolution produces a better evolver

Each skill is frozen and installed on the same fresh base worker with the same resource budget. No evolved worker or campaign artifact carries over. The no-data variant asks an LLM to improve the seed skill without seeing any execution results.

The seed skill already improves workers, but only by 0.6 points on average across the four mean metrics. The meta-evolved skill adds a further 6.9 points, improves every available pass@3 metric and beats the no-data rewrite in every environment. The gain comes from execution experience. Rewriting the instructions without it does not reproduce the effect.

Learned skills transfer across environments and models

A skill captures how to organize improvement, not a particular worker, so it should be reusable. If it is, the compute-heavy meta-evolution runs once and the resulting evolver serves new environments. We freeze each meta-evolved skill and install it on a fresh worker in every target environment.

Transfer is positive on most target metrics. The τ³-bench skill reaches 64.3% on ARC-AGI-2 and 71.0 RHAE on ARC-AGI-3, matching or beating the skills meta-evolved on those environments directly. Both single-source skills lower the Terminal-Bench mean, which marks a boundary when the target's hardware and execution behavior change a lot. Meta-evolving on τ³-bench and Terminal-Bench 2.1 jointly gives a skill that improves every target metric over the seed.

Evolved workers run on cheaper models

Each method evolves its harness with the native Opus worker; the frozen harness then runs unchanged with Sonnet 4.6 and Haiku 4.5. FreeEvolve is the strongest harness in all six settings and keeps a 5.3-point average gain over the base harness on the four non-native ones, while several baseline gains on τ³-bench shrink or reverse. A worker can be evolved with a strong model and deployed with a cheaper one without re-evolution.

A stronger skill for fewer tokens

On ARC-AGI-3 we track the best training RHAE of the worker each method's skill produces against the total tokens spent to produce that skill, counting every evolver, evaluation and model call. FreeEvolve reaches 90.6 at 0.74B tokens. The best baseline stops at 81.7 after 1.3B.

The campaign reorganizes itself as evidence arrives

Here is one ARC-AGI-2 worker-evolution campaign run under a frozen meta-evolved skill. Every marker is one evaluation on the evolution set, plotted against elapsed hours. None of the annotated moves is a stage of the framework. The evolver chose each one when the campaign called for it.

Scroll sideways to see the whole figure.

The harness it returned is not simply the highest single score. When choosing what goes in best/, the evolver weighs how many evaluations and paired comparisons back each candidate.

Removing one decision weakens the result

On τ³-bench we keep the learned skill and budget fixed and take away control of one execution decision at a time. Always evaluating the full set makes the evolver wait on expensive probes, so it makes fewer decisions within the time budget. A fixed concurrency of 24 or no task timeout leaves resources tied up by slow or failed executions; both spend more tokens and still produce a weaker worker. No single configuration is best. The benefit comes from being able to reorganize evaluation as the campaign unfolds.

What meta-evolution writes into the skill

Comparing the four meta-evolved skills with their common seed shows what was learned. The seed gives broad dispositions and leaves the organization of the campaign open. Meta-evolution turns those dispositions into operating rules for task selection, evaluation allocation and search control: use failures to choose new probes, move from cheap tests to confirmation only when warranted, and keep or combine changes according to accumulated evidence.

Read ./ENVIRONMENT.md. It states the goal, how to run an evaluation, and where the results appear. It is the source of truth for what counts as better. ... The evaluation always runs the named agent: edit it in place, and leave it where it is. ...

... Spend the available wall-clock budget and reserve enough time to leave the work in order. When time is up, leave the strongest version at best/ and a short RESULT.md stating what it is and what evidence says it is strongest.

Treat an evaluation as evidence about the learner. Read the inner run, including its raw measurements and trace, before deciding what to change in the evolver instructions. Nominate the best-supported version; do not confuse the last edited state with the best version.

Campaign control needs a capable model

We keep the τ³-bench worker and the meta-evolution setup fixed and change only the model that runs the evolver, from Haiku 4.5 to Opus 4.8.

Haiku 4.5 improves neither held-out metric: its evolution-split score climbs to 52.2 while held-out accuracy falls to 32.2. From Sonnet 4.6 onward, meta-evolution consistently improves held-out performance, and the strongest Opus models produce the best workers. Gains generally grow with newer and stronger models, although Sonnet 4.6 beats Opus 4.6.

The optimization process can be learned

Agent evolvers automated the design of harnesses but left the process that designs them in human hands. FreeEvolve automates that process too. The evolver runs its own improvement campaign inside a bounded environment, and meta-evolution learns from the outcomes how to run it. Across four environments the self-organized campaign matches or beats hand-designed evolvers, and the learned skill keeps improving with experience and transfers to new environments. What it carries is a way of running an improvement campaign, not domain knowledge.

Cite FreeEvolve

@misc{kong2026freeevolve,
  title         = {FreeEvolve: Learning to Evolve Beyond Fixed Loops},
  author        = {Kong, Lecheng and Hui, Like and Kanakaris, Nikos and
                   Jana, Prithwish and Genc, Sahika and Sadagopan, Narayanan},
  year          = {2026},
  eprint        = {2610.09197},
  archivePrefix = {arXiv},
  primaryClass  = {cs.AI},
  url           = {https://arxiv.org/abs/2610.09197}
}