Self-improving AI agents can inspect their failures and modify the prompts, tools, skills and workflows around the underlying model, or the “harness.” But reliably compounding those improvements is difficult. An edit that helps one task can make the agent worse at another, while repeatedly improving one version of the harness can lead the system down a path that eventually plateaus.
Salesforce AI Research and Salesforce Agentforce's new DarwinX framework takes an evolutionary approach to this problem. Instead of continually rewriting one version of the agent harness, it explores several alternatives, keeps useful discoveries around, and only lets changes advance when they improve capability without regressing on other tasks.
The experiments suggest there is plenty of performance to extract from this layer. Evolving the harness improved the agent's score on all four benchmarks the researchers tested, ranging from a 3.4-point gain on SWE-bench Verified to a 49.5-point jump on WebArena-Infinity, they report.
DarwinX changes only the harness, never the model weights. That makes the approach relevant to application developers who build on hosted models and do not have their own fine-tuning or model-training pipelines.
Why existing self-improvement loops get stuck
Many self-improving agent frameworks use some version of the same basic loop: run the agent on a batch of tasks, inspect the trajectories, identify failures, propose a change to the harness, and test the modified agent against a validation or regression set.
Researchers have already expanded this idea beyond prompt optimization. For example, the Darwin Gödel Machine (DGM) lets an agent modify its own source code and maintains an archive of past variants. HarnessX works directly on prompts, tools and control flow and separates variants across task families to contain interference.
But the Salesforce researchers identify two problems with these approaches.
The first problem is “path dependence.” If each round builds on whichever agent currently looks best, early changes determine the foundation for everything that follows. A locally useful edit might send evolution down a branch that eventually plateaus, while another promising branch is abandoned before it has time to develop.
Imagine that an early edit teaches a coding agent to aggressively install dependencies before working on a task. It fixes several failures, so it becomes the new baseline. Every subsequent edit is now built on top of that behavior. Meanwhile, the system might miss exploring an alternative strategy that first inspects the environment and installs only what is needed.
The second problem is “cross-task interference.” A change that helps one class of tasks can silently damage another. An instruction to perform extensive verification, for example, might improve difficult scientific-computing tasks but make simpler jobs exceed their time budget. The wider the agent’s task distribution becomes, the harder it is to make local improvements without trading away existing capabilities.
The same problems are already familiar to enterprise teams that manually patch prompts and workflows after failures. In comments provided to VentureBeat, Ran Xu, senior author of the DarwinX paper, said, “Manual harness engineering can easily converge to a local optimum: you fix the prompt or workflow for one failure mode, but without broad regression testing, you may silently break something that was already working.”
Agent evaluations add another complication. Results are stochastic, so the same agent can pass a task in one run and fail it in another. The researchers point to previous research that measured multiple percentage point swings between different runs of industry benchmarks. That can be as large as the apparent benefit of an individual harness edit.
This makes broad regression testing as important as fixing the failure that triggered the harness change in the first place.
The challenge, therefore, is deciding which improvements are real, keeping useful alternatives alive, and combining new capabilities without losing old ones.
DarwinX lets improvements compete
DarwinX treats this as a selection problem. Instead of maintaining one continuously rewritten harness, it generates different variants and stores them in an archive. Promising versions can keep evolving, while useful discoveries from other branches remain available for later use. The underlying LLM stays unchanged.
The first key mechanism is what the researchers call “preserve and extend.”
A candidate harness needs to improve something while keeping regressions on previously solved tasks within a bounded tolerance. In simple terms, solving task B does not count as much of an improvement if the same change breaks tasks A and C.
DarwinX also separates exploration from confirmation. A promising edit with limited downside can survive an early screening stage. But before it is trusted to guide future evolution, the system reruns it at higher fidelity and probes tasks that previous versions already solved. This makes it harder for one lucky rollout to redirect the search.
DarwinX can enforce this discipline because its coding and browser experiments have outcomes that can be verified relatively reliably. That allows the system to test whether a harness change adds a new capability while preserving tasks that previous versions already solved.
For software engineers, preserve-and-extend looks a lot like continuous integration for an agent: propose a change, test the new behavior, rerun previously passing cases, and only then let the candidate influence future versions. As Xu put it, “The key is that DarwinX does not simply merge changes and assume the result is better. The merged agent still has to pass preservation and confirmation gates, retaining the complementary wins without regressing previously solved behavior.”
The second mechanism addresses path dependence. DarwinX keeps alternative branches, including variants that are weaker on aggregate metrics. A branch might perform worse overall but contain the only change that solves a particular class of task. Instead of throwing that work away, DarwinX can treat it as a specialist.
When different specialists have complementary strengths, the framework can merge their additive changes into a new harness. The merged version must then prove that it retains the relevant wins of its parents. This allows improvements discovered on different evolutionary paths to meet again instead of remaining trapped in separate branches.
DarwinX can also draw on different sources when proposing the next change. It can analyze failed trajectories, learn from the successful trajectory of a stronger teacher, or compare the agent’s own successful and failed attempts on the same task. All three signals result in edits to the harness rather than changes to model weights.
The researchers also aggregate recurring failures into shared memory. For example, if multiple tasks fail because environment setup takes too long, the system can propose a reusable setup capability instead of creating a patch for each task separately.
This is also where the “natural selection” in DarwinX becomes more literal. The system does not need gold solutions, and researchers do not manually inspect the candidates and choose a winner. Harness variants survive based on their measured fitness under a task evaluator.
That does not mean DarwinX works without an evaluation signal. It still needs a way to determine whether a task succeeded. For example, in their experiments with WebArena-Infinity, the researchers used an LLM judge to score trajectories generated by different variants of their agent.
This selection process is also what distinguishes DarwinX from systems such as DGM and HarnessX. DGM already has an open-ended archive, but it mutates one parent at a time and does not have DarwinX’s cross-lineage merging or explicit preservation contract. HarnessX isolates variants to contain interference, while DarwinX tries to safely bring complementary capabilities back together.
DarwinX in action
The researchers tested DarwinX on Monet, Salesforce’s proprietary agent. In matched comparisons, the underlying model remains frozen.
The evaluations become progressively harder to game through overfitting. In the first round of experiments, the agent is evolved and evaluated on the same benchmark. The second round tests the agents on held-out tasks. In the third stage, the agent harness is evolved on synthetic browser tasks and evaluated on unseen real ones. The final experiment moves a harness evolved on one benchmark to an entirely different benchmark.
On Terminal-Bench 2.1, DarwinX increased Monet’s score on frozen GPT-5.5 from 75.5% to 83.2%, the researchers report, and to 84.7% with a stronger base model. The biggest improvements came from ML and scientific-computing tasks, which rose 14.8 points, and data and database tasks, which increased 13.8 points.
But more important than the jump in scores are the changes that produced these gains. The evolved harness added seven skills that instruct the agent to define what a correct result should look like, check generated files and values before finishing, and ground outputs in real tool execution.
The evolved agent also did not simply spend more inference compute everywhere. On tasks that both versions could already solve, median turns increased only from 12 to 13. In contrast, on six newly solved tasks, they doubled from 11 to 22. This means that the harness had learned where extra verification and retries were worth the cost.
TerminalWorld provides a clearer example of why DarwinX keeps multiple branches. The harness evolved on 94 training tasks and was then frozen before being tested on 41 separate tasks. On Opus 4.8, the base version solved 25 of 41 tasks, or 61%, while DarwinX solved 28, or 68.3%, according to the paper.
More interestingly, four specialist variants solved 24, 25, 26 and 27 held-out tasks on different overlapping subsets. The merged harness reached 28, beating every specialist. The researchers report Opus 4.8 as the headline result because the same procedure on GPT-5.5 reached 56.1%, below a neutral baseline agent, and they describe the one-task margin over the strongest off-the-shelf agent as suggestive rather than statistically decisive.
Xu points to this result as evidence that aggregate scores can hide useful capabilities. “A lower-scoring variant may still contain the only successful behavior for a particular class of tasks,” he said.
A practical enterprise analogue would be an incident-response agent. The best general-purpose version might reliably inspect services, run standard diagnostics and prepare safe code changes. A lower-scoring specialist might have developed a reliable Kubernetes authorization workflow, while another might be better at database recovery and artifact verification. Neither specialist needs to be good enough for deployment on its own for its harness changes to be useful. DarwinX can preserve those behaviors, combine them with others, and then subject the merged version to the same regression checks before promoting it.
The TerminalWorld result is the measured evidence behind that analogy. The paper does not independently isolate how much of the gain comes from recombination itself versus other parts of the DarwinX system.
In the WebArena-Infinity experiments, DarwinX evolved the browser harness on 300 synthetic intents generated from application documentation. The final test included 1,260 unseen tasks with deterministic verifiers, rather than the LLM judge used to score variants during evolution. With GPT-5.5 frozen, the researchers report the agent's performance increased from 43.5% to 93% — more than doubling the score without touching model weights, a figure they report after an audit that screened trajectories for invalid or exploit-style behavior.
Finally, the researchers took the harness evolved on Terminal-Bench and ran it unchanged on SWE-bench Verified. It reached 84.2%, compared with 80.8% for the reference harness, without receiving SWE-bench feedback during evolution, according to the paper. The result provides evidence that some of the learned harness behaviors can transfer beyond the benchmark they were evolved on, although the paper tests this transfer in only one direction.
What DarwinX means for developers
DarwinX’s main practical advantage is that the improvement loop operates in a layer application developers already control. Access to model weights is not required.
As foundation models improve, this surrounding layer may become more important rather than less. A harness has to adapt to each model’s tool-use behavior, context requirements and failure modes. It also carries enterprise-specific information that a general-purpose model cannot simply learn during pretraining: live data, workflows, permissions, identity, governance rules, tools and action surfaces.
“The model may absorb more generic reasoning capability, while the harness increasingly represents the enterprise-specific context, actions, governance, and adaptation layer around the model,” Xu said. “That can be a much more durable source of differentiation than any particular prompt.”
The harder requirement is building the evaluation infrastructure that tells the evolution loop what “better” means. Unlike coding benchmarks, real enterprise workflows rarely have one clean binary verifier.
Xu argues that enterprises should address this by capturing what happens during real work and gradually turning those traces into learning and evaluation signals. Consider a customer-service agent. A company could record the agent’s actions, ticket-state changes, human corrections, escalations, policy checks, approvals and downstream outcomes. Some of those signals can become deterministic tests: did the case reach the correct state, did an approved transaction complete, or did the database contain the expected value? Others might come from human corrections, compliance checks, business outcomes or agreement between multiple evaluators.
“Enterprises do not necessarily need a single perfect reward function,” Xu said. “They need an infrastructure layer that continuously turns real work into increasingly strong enterprise intelligence.”
Over time, that infrastructure can produce a continuously refreshed evaluation suite drawn from the workflows the agent actually encounters. This addresses one of the main practical limitations identified in the paper: production tasks rarely arrive with reliable verifiers. Instead of evolving an agent directly against live requests, teams can periodically run evolution against a maintained proxy suite and deploy the version that clears the regression gates.
Salesforce has also released the infrastructure for experimenting with this approach through Beagle, an open-source framework available on GitHub under the Apache 2.0 license. Monet remains proprietary, but teams can bring their own agent harness in Beagle. DarwinX is the evolution method that searches, evaluates and selects harness variants, while Beagle provides the broader infrastructure for running rollouts and experiments across agents, environments, datasets and evolution methods.
Xu describes Beagle as a “Hugging Face Trainer for agent evolution”: “You bring the agent, the environment, the evaluation signal, and the evolution algorithm, while the infrastructure handles scalable rollouts and experimentation.”
There is a cost to moving from manual prompt updates to this kind of automated harness CI. DarwinX explores multiple variants, repeats evaluations to account for noisy results, and runs preservation probes before candidates can influence later generations. That requires more evaluation compute and more infrastructure than editing prompts by hand. But manual updates also need regression testing if they are going into production. The difference is that the automated loop can run those experiments systematically instead of requiring an engineer to inspect and patch failures one at a time.
Teams can also bound the cost. Evolution can run under a fixed compute budget and stop when improvements plateau. “The goal is to spend evaluation compute until the marginal improvement is no longer worth the cost,” Xu said. For an enterprise, the relevant tradeoff includes engineering time and regression risk as well as inference spend: how quickly does the system reach the required quality level, and how many production regressions does the automated test-and-selection loop prevent?
That also means DarwinX is not a good fit for every agent. Xu recommends evolutionary harness optimization for long-horizon tasks where outcomes can be evaluated with reasonable confidence and which have a large behavioral surface (e.g., prompts, skills, tools, memory, control flow or source code).
In contrast, the added machinery is difficult to justify for a simple and stable workflow, such as mapping a known input into a fixed API call and returning the result. “I would not introduce population-based evolution just for the sake of it,” Xu said. A deterministic workflow will usually be easier to understand, test and govern.
There is also a middle ground. An enterprise customer-service agent might span enough changing workflows to benefit from continuous improvement without requiring a full population-based evolutionary search. Teams can still borrow DarwinX’s core discipline: turn representative failures and human feedback into proposed changes to prompts, workflows, database operations, function calls or integrations, and gate those changes against a regression suite. A simpler linear or best-first search can be enough when the task does not justify maintaining a full population of variants.