Evolving the scaffolding around a frozen model adds 17 points

The model is frozen, the agent still improves

AI agents come with an awkward truth: quality doesn't depend on the model alone. The scaffolding often decides everything — the system prompt, the tools, memory, the rules for choosing the next step, the checks before answering. The same LLM can behave like a careful engineer or like a chaotic intern purely because of how the pipeline is assembled around it.

The DarwinX work proposes treating this as evolution. The model is not fine-tuned and not replaced. Only the scaffolding changes. And not along a single line of "try an edit, keep the best one", but through a population of variants, selection, preservation of useful branches and, later, merging them.

The industry has a bias right now: nearly all attention goes into model weights. DarwinX points at something more mundane. If you already have a strong LLM, a large reserve of quality may sit not in a new model but in how the agent is built around it.

What DarwinX is

The idea is simple: the agent improves not by training the model, but by selecting among versions of its scaffolding.

The authors define scaffolding as everything external to the model:

🟠 system prompts and instructions

🟣 the toolset

🟠 skills and accumulated notes

🟣 control logic: when to call a tool, when to re-check, when to keep searching for a solution

Self-improving agents usually follow a single line. They change their procedure, measure the result and keep the last successful edit. That approach has two old problems.

🟠 It is hostage to early decisions: go the wrong way at the start and the whole branch can stay stuck

🟣 A local win on one group of tasks can quietly damage results on another

DarwinX handles this through "natural selection" over scaffolding versions. Many variants are produced. Each is run on tasks. The survivors are the ones that learned to solve something new without breaking what was already mastered.

The DarwinX scheme: the agent's scaffolding evolves while the model stays frozen, and useful branches are archived and can be merged.

The key move is refusing to pick a single winner too early. Even a version that is worse on average may solve one rare class of tasks. DarwinX doesn't throw such branches away. It files them in an archive and later tries to merge complementary improvements.

Simplified, the logic runs like this:

🟠 make a small edit to the scaffolding

🟣 check whether it got better on part of the task set

🟠 make sure the old skills didn't degrade too far

🟣 save the successful branch to the archive

🟠 later cross several branches if they are useful on different tasks

This no longer looks like "we tweaked the prompt". It looks like an engineering pipeline for finding a stable agent configuration.

How selection works

The most interesting part of the work is the rule that grants a new version the right to live on.

The authors introduce a "preserve and extend" contract. The new scaffolding has to:

🟠 solve at least something new

🟣 not lose too much of what the parent variant could do

DarwinX rewards the accumulation of skills rather than chaotic jumps. If a version fixed one task but broke three old ones, that's a bad mutation. If it added a new capability with almost no regression, it is kept.

The selection loop in DarwinX: the "preserve and extend" rule, an archive of alternative branches, and shared memory across generations.

One more detail: the system separates fast search from strict confirmation. A variant can first be waved through on a noisier signal so evolution doesn't stall. But before it starts influencing later generations, it gets re-checked more thoroughly.

This exists because of a problem common to every agentic benchmark: they are noisy. The same agent can pass a task by chance once and fail it the next time. Trust single lucky runs and evolution quickly starts fitting the noise.

DarwinX damps that in two ways:

🟠 solutions are scored by the benchmark's own verifier rather than against "golden" answers

🟣 candidates are re-measured before they are promoted to new ancestors

Shared memory across generations is separately useful. The system collects the typical causes of failure: a long setup, a tool error, a wrong answer format, weak checking of the result. Those recurring themes then shape the next edits. DarwinX tries to teach the agent not to patch a single task but to grow a general skill for similar failures.

Where the edits come from

DarwinX doesn't change model weights. So every improvement has to be extracted from an analysis of the agent's behavior. There are three kinds of signal for that.

DarwinX stores and uses shared memory of what worked, what broke and which error types keep recurring.

The first comes from failures. When the agent fails a task, the system analyzes the trajectory and tries to work out what was missing: a check on the artifact, a better setup, a different sequence of actions.

The second comes from a stronger solver. When the system has no successful attempt of its own, it can take someone else's successful trajectory and convert it into a scaffolding change. This isn't copying the answer, it's extracting the approach.

The third comes from its own contrasts. When the agent has both successful and failed runs on the same task, you can compare them and find what exactly makes success reproducible.

Compressed, the methodology looks like this:

🟠 failures turn into a diagnosis

🟣 someone else's successful runs turn into demonstrations

🟠 the gap between its own wins and losses turns into a rule

🟣 all of it is written down as a scaffolding change, not as fine-tuning

That constraint matters. The authors want to prove one thing: a frozen model is not yet a fixed agent.

What the benchmarks show

The authors test DarwinX not on one benchmark but across four regimes, in which the evolution signal and the final evaluation drift further and further apart. That makes it easier to see whether the system learned a general way of working better or simply fitted itself to one task set.

Results across four benchmarks: the same idea improves the agent without changing model weights, and it transfers between tasks.

The headline numbers:

🟠 Terminal-Bench 2.1: up from 75.5% to 83.2% on GPT-5.5, a gain of 7.7 points

🟣 On a stronger base the result reaches 84.7%

🟠 TerminalWorld on held-out tasks: 68.3%, above the base version and above several off-the-shelf agents

🟣 WebArena-Infinity: up from 43.5% to 93.0% on real web tasks after evolving only on synthetic ones

🟠 Transfer from Terminal-Bench 2.1 to SWE-bench Verified with no changes to the scaffolding: 84.2%

The numbers in brief:

🟠 The average gain across the four regimes is about 17 points

🟣 The improvements come without changing the model

🟠 There is transfer between tasks

🟣 The gain shows up in the terminal and in the browser alike

The most striking result is WebArena-Infinity. There the agent trained not on the benchmark's real tasks but on synthetic intents. DarwinX never saw the final tests and even used a different signal during selection. Even so, it reached 93% clean pass@1 on the real tasks after an audit.

That matters because web agents often cheat: they touch hidden state, reach into the page's internal technical details, use things an ordinary user has no access to. The authors inspected the trajectories separately and showed that the number of invalid solutions dropped sharply after evolution — from 293 to 17. The agent didn't just pass more tasks, it passed more of them the right way.

A short summary of the results:

🟠 The improvements come without changing the model

🟣 There are gains in the terminal and in the browser

🟠 There is transfer to another benchmark

🟣 The web agent became more careful, not merely more aggressive

What actually evolves

One motif recurs through the paper: DarwinX often grows in the agent a habit of first stating the task's contract and only then checking the result before finalizing it.

Shared memory and the selection loop push DarwinX toward accumulating procedural skills rather than one-off patches.

On Terminal-Bench the improvements are clearest where the problem is procedural rather than a matter of knowledge:

🟠 machine learning and scientific computing tasks

🟣 tasks involving data and databases

🟠 long environment setup

🟣 multi-step work with tools

🟠 checking output files and formats

DarwinX doesn't make the model smarter. It makes the agent more disciplined. The agent checks more often what actually counts as the right answer, compares the outcome against the task contract, runs extra validation, and doesn't finish too early.

The same pattern shows up in browser tasks. Instead of routing around the interface through dubious shortcuts, the evolved agent more often:

🟠 states the success condition

🟣 acts through the operations the application actually offers

🟠 checks both the visible state and the saved result

🟣 confirms that the change really stuck

This reads as a set of procedural skills, not as fitting to particular answers.

Why this matters for the industry

DarwinX shows that evaluation compute can be converted into continuous improvement of an agent, even when you never touch the model at all.

Companies today often work like this: take a new LLM, put minimal scaffolding on top, then go compare results. This work shows that approach leaves a lot of quality on the table.

If you build AI agents, four practical conclusions follow from the paper:

🟠 Scaffolding is an optimization layer in its own right, not a technical detail

🟣 One best agent is worse than an archive of different useful variants

🟠 You need checks that old capabilities survive, or edits will quietly break cases that already worked

🟣 Evolving against the task's verifier can beat hand-picking the "right" edits

One more conclusion concerns noise in agent evaluation. If you want to improve an agent automatically, you can't believe single successes. You need repeated runs, careful selection and protection against lucky wins. DarwinX is built precisely around that.

Limitations

The work doesn't close every question.

First, what's tested here is the whole system. The archive, parent selection, branch merging, the different edit signals — all of it works together. So it's hard to say which piece delivers the bulk of the gain.

Second, transfer isn't equally large everywhere. On SWE-bench there is a gain, but a far more modest one than on the original tasks.

Third, some regimes rest on small samples. TerminalWorld, for instance, has only 41 held-out tasks, and a single success moves the final percentage noticeably.

But these limitations don't change the main observation: an agent can be improved through its scaffolding, and it works in more than one sandbox.

Takeaway

DarwinX proposes treating an AI agent as an object of selection, not only of training. The model stays the same. The scaffolding changes. If a new version solves more tasks and barely damages the old skills, it survives. If different branches are good at different tasks, they can be merged.

A practical idea follows from that: a fixed LLM is not yet a fixed agent. Agent behavior can be accumulated, verified and carried between tasks without fine-tuning the model.

The most visible improvements come from discipline: stating the task contract better, working with tools more carefully, checking the result more often before the final answer. For agentic systems that may matter more than the next jump in model size.