Stop wasting your time on those long-winded, half-baked harness engineering posts on X. Compared to this article, those are absolute garbage. Lilian Weng’s latest blog post is the clearest, most accessible explanation of harness engineering I have ever read, and it’s also the best-written piece on recursive self-improvement harness engineering. The article provides a comprehensive framework that details the entire knowledge architecture of self-improvement harness engineering. Here is the link to my Chinese version: https://pandatalk8.com/blog/harness-engineering-self-improvement/document…

Harness Engineering for Self-Improvement

Source: Lilian Weng · Harness Engineering for Self-Improvement (https://lilianweng.github.io/posts/2026-07-04-harness/) · 2026-07-04
Full Chinese Translation · Local Knowledge Base Clip · Reading time ~28 minutes

The concept of recursive self-improvement (RSI) dates back to I. J. Good (1965) (https://philpapers.org/rec/GOOSCT), who defined a “superintelligent machine” as a system that can surpass humans in all intellectual activities and design better machines to improve itself. Yudkowsky (2008) (https://www.lesswrong.com/posts/JBadX7rwdcRFzGuju/recursive-self-improvement) used the phrase “recursive self-improvement” to refer to a specific feedback loop: AI uses its current intelligence to improve the cognitive machine that produces its intelligence.

In modern AI, this feedback loop could mean the model directly rewrites its own weights; or more broadly, the model improves the training pipeline and deployment system, which in turn enables successor models to perform better on economically valuable tasks. The pace of AI R&D has been shown to accelerate dramatically in frontier labs (Anthropic (https://www.anthropic.com/institute/recursive-self-improvement); OpenAI (https://openai.com/index/how-agents-are-transforming-work/)).

I explicitly mention “deployment system” because the layer between the raw model and real-world context appears as important as the model’s raw intelligence (i.e., evaluations done immediately after pretraining). Harness is a crucial part of AI deployment, as demonstrated by successful coding agent products like Claude Code and Codex. Harness is the system surrounding the base model, orchestrating execution and determining how the model thinks and plans, calls tools and actions, perceives and manages context, stores artifacts, and evaluates results.

This post will focus on research related to harness engineering and how it contributes to RSI. Many recent works on automated research, self-improving agents, and evolutionary program search can be organized around this question. Other work on self-play, synthetic data, test-time training, and more broadly continual learning also fits the RSI vision (e.g., Yuan et al. 2024 (https://arxiv.org/abs/2401.10020), Chen et al. 2024 (https://arxiv.org/abs/2401.01335), Zhao et al. 2025 (https://arxiv.org/abs/2505.03335), Choi et al. 2026 (https://openreview.net/forum?id=lTbBFAoPSA)), but they are not the focus of this post.

Compared to early agent frameworks (https://lilianweng.github.io/posts/2023-06-23-agent/) — “agent = LLM + memory + tools + planning + action” — harness engineering additionally includes workflow design (e.g., loop engineering), evaluation, permission control, and persistent state management. It is no longer just a prompt template, but is closer to runtime and software system design: how the model observes, acts, remembers, checks itself, and improves.

The design should intentionally be kept simple and general to support generalization, and likely reference existing software engineering practices to benefit from pretraining knowledge. There is also a strong analogy between operating systems and harness. Similar to an OS, the harness should encapsulate complex logic while keeping the interface simple. Meanwhile, configurations, tool interfaces, and other protocols may gradually become standardized across the industry.

Pattern 1: Workflow Automation

Defining a workflow in which the model can run, test, and iterate is a key design for automation. Karpathy’s autoresearch repository (https://github.com/karpathy/autoresearch) is a clear example of how such a workflow can be structured. A common workflow follows a goal-oriented loop: plan, execute, observe/test, improve, execute again, until the goal is achieved. This process may proactively ask the user for clarification on task specifications or execution preferences.

Simplified Codex Agent Loop: The agent calls tools, and tool responses influence the next generation of the model. (Image credit: OpenAI Codex Agent article)

Simplified Codex Agent loop: The agent calls tools, and tool responses influence the next generation of the model. (Image credit: OpenAI Codex Agent article (https://openai.com/index/unrolling-the-codex-agent-loop/))

This workflow diagram also emphasizes: the model analyzes its own trajectories and failure cases, then iterates continuously through the “Agent runtime” rather than relying on a static prompt template.

Pattern 2: File System as Persistent Memory

In long-running agent systems, a recurring pattern is to control rich state and artifacts in a simple way. The harness should not cram the entire workflow and all logs into the context; instead, it should store persistent state in files. In long-running agent rollouts, artifacts such as experiment logs, code diffs, paper summaries, error traces, and past rollout trajectories often grow far beyond the training-time context window length.

Learning how to read, write, and edit the file system (typically via bash commands) is a fundamental skill for LLMs. Therefore, managing persistent memory in the simple form of files naturally benefits from improvements in core model capabilities.

Pattern 3: Sub-Agents and Background Tasks

The harness can launch multiple sub-agents for parallel execution and monitor background tasks. This is particularly useful when the main agent needs to explore multiple hypotheses, run experiments concurrently, or delegate isolated subtasks without polluting the main context. Thus, the parent agent requires a small process manager: start tasks, check logs, cancel failed runs, and merge results back into the main agent thread.

A key design choice is to make parallelism explicit and inspectable. If sub-agent outputs exist only in ephemeral chat context, they quickly become outdated and hidden. If they are stored as files, logs, and state records, the model can resume after interruptions and reason based on its own execution history.

Case Study: Coding Agent Harness

The core interface of mainstream coding agents has stabilized among Claude Code, Codex, OpenCode, and Cursor-style agents. They typically use a loop similar to the one below:

Figure: After obtaining a set of tools, the coding agent can develop and debug problems in a given repository, similar to how a human developer works with an IDE. (Not a complete list; for demonstration only. See this article (https://github.com/yasasbanukaofficial/claude-code) for more details.)

Harness Layer vs. Core Intelligence?

It’s hard to predict how much future RSI will depend on harness engineering, but the near-term practical path of RSI is unlikely to start with the model directly rewriting its own weights. My prediction for the near-term practical path is:

1. Harness engineering will evolve toward a meta-methodology, i.e., improving the “machine that obtains better answers,” not just the answers themselves. The harness system itself will become the optimization target, with fewer heuristic rules and more general mechanisms.
2. A mature harness will in turn support automated research for the model self-improvement loop; smarter models will prevent over-engineering of the harness and keep the system sustainable.

Ultimately, many harness improvements may be internalized into core model behavior, but the interface with external context and tools should remain. We have already seen a weaker version of this pattern in prompt engineering (https://lilianweng.github.io/posts/2023-03-15-prompt-engineering/): as instruction tuning and model reasoning capabilities improve, handcrafted prompt tricks become less central, but the need to specify goals, constraints, context, and evaluation does not disappear.

Harness Optimization

The object being optimized in the harness system has evolved roughly as: instruction prompts (https://lilianweng.github.io/posts/2023-03-15-prompt-engineering/) → structured context → workflow → harness code → optimizer code. As models become smarter and more powerful, we will move toward more complex goals and more general methods.

Context Engineering

As agent task cycles lengthen significantly, simply appending all tool responses and model outputs to the context quickly becomes unwieldy. Context management is a mechanism for constructing a more structured and concise context for the LLM and managing persistent state. Without a doubt, long-context research will continue to advance, but for now, long-context intelligence and context engineering sometimes interweave.

Agentic Context Engineering (ACE) (Zhang et al. 2025 (https://arxiv.org/abs/2510.04618)) treats context as an evolving playbook, not a growing prompt. It has three components to maintain a bullet-pointed context playbook; each entry has an identifier and description.

1. Generator: Generates task trajectories and references bullet points.
2. Reflector: Extracts insights from successful and failed trajectories.
3. Curator: Updates the structured context incrementally, entry by entry.

Agentic Context Engineering (ACE) framework. (Image credit: Zhang et al. 2025)

Agentic Context Engineering (ACE) framework. (Image credit: Zhang et al. 2025 (https://arxiv.org/abs/2510.04618))

To avoid context collapse and brevity bias during iterative rewriting, a key design choice of ACE is that the curator does not rewrite the entire prompt blob. Instead, it outputs a set of structured, bullet-pointed entries in the form (identifier, description); these bullets are merged into the structured context log via deterministic logic. Context entries are periodically refined and deduplicated.

ACE learns insights from rollouts, moving toward self-managed memory; but its update rules and overall workflow are still hand-crafted. To move toward a more self-improving loop, Meta Context Engineering (MCE) (Ye et al. 2026 (https://arxiv.org/abs/2601.21557)) separates the mechanism (how to manage context) from the artifact content (what is in the context), performing skill evolution at the meta-optimization layer and context optimization at the base layer.

An MCE skill \(s \in \mathcal{S}\) defines a context function \(c_s=(\rho_s,F_s)\) and maps input \(x\) to context \(c = F_s(x;\rho_s)\), where:

• \(\rho_s = \{\rho_1,\dots,\rho_m\}\) are static components (prompts, knowledge bases, codebases).
• \(F_s = \{F_1,\dots,F_k\}\) are dynamic operators (search, selection, filtering, formatting).

The dual-layer optimization goal is: given a skill \(s\), find the best context \(c_s^*\) on training data; meanwhile, the outer loop finds the optimal skill that yields the best performance on the validation set:

\[\text{Inner: } c_s^*=\arg\max_{c_s} J_\text{train}(c_s;s) \quad \text{Outer: } s^*=\arg\max_{s\in\mathcal{S}} J_\text{val}(c_s^*)\]

The skill database tracks historical skills, context functions, and evaluation metrics \(\mathcal{H}{k-1} = \{(s_i,c_i,J_i^\text{train}, J_i^\text{val})\}_{i=1}^{k-1}\). A meta-layer agent performs Agentic crossover (https://en.wikipedia.org/wiki/Crossover(evolutionary_algorithm)) based on prior skills to create a new skill for task \(\tau\): \(s_k=\text{crossover}(\tau,\mathcal{H}_{k-1})\).

Then a base-layer context engineer executes skill \(s_k\), and under the current skill guidance, learns the context function from rollout feedback \(\mathcal{R}k\): \(c_k=\text{engineer}(\tau,s_k;c{k-1}^*,\mathcal{R}_k)\).

Meta Context Engineering (MCE) framework: meta-layer skill evolution searches context management mechanisms, while base-layer optimizes task context. (Image credit: Ye et al. 2026)

Meta Context Engineering (MCE) framework: meta-layer skill evolution searches context management mechanisms, while base-layer optimizes task context. (Image credit: Ye et al. 2026 (https://arxiv.org/abs/2601.21557))

MCE does not enforce heuristic rules on how to construct context, like ACE does. It uses free-form skills to store the most important knowledge for the task, and lets skills and skill-conditioned contexts evolve iteratively together. In implementation, the context function \(c\) is instantiated as a set of files in a dedicated directory, including static components (skill.md) and dynamic components (context and data rollouts). Both meta-layer and base-layer optimizations are performed in an agentic coding environment and use a standard set of tools:

\[\mathcal{T}=\{\texttt{Read},\texttt{Write},\texttt{Edit},\texttt{Bash},\texttt{Glob},\texttt{Grep},\texttt{TodoWrite}\}\]

Meta-Harness (Lee et al. 2026 (https://arxiv.org/abs/2603.28052)) pushes one layer further: the object being optimized is the code that decides and optimizes “what information should be stored, retrieved, and presented to the model.” The “Meta-” in its name means it is a harness for optimizing harnesses.

Meta-Harness outer loop optimization algorithm. (Image credit: Lee et al. 2026)

Meta-Harness outer loop optimization algorithm. (Image credit: Lee et al. 2026 (https://arxiv.org/abs/2603.28052))

The proposer for creating new harnesses is itself a coding agent, and the final output is a set of harness candidates on the Pareto frontier.

• The entire execution history is accessible via the file system, so the coding agent reads history using commands like grep or cat rather than cramming everything into a single prompt context.
• The proposed harness is a dictionary in the file system containing its own source code, scores, rollout trajectories, and state updates.
• The meta-harness loop iteratively creates new harnesses and retains only qualifying ones.

Meta-Harness performance on (left) few-shot iterative text classification tasks and (right) TerminalBench-2. Note that the TerminalBench-2 experiment initializes the search from two very strong harnesses: Terminus-KIRA and Terminus-2. (Image credit: Lee et al. 2026)

Meta-Harness performance on (left) few-shot iterative text classification tasks and (right) TerminalBench-2. Note that the TerminalBench-2 experiment initializes the search from two very strong harnesses: Terminus-KIRA and Terminus-2. (Image credit: Lee et al. 2026 (https://arxiv.org/abs/2603.28052))

The key lesson is clear: once the harness design becomes an executable search space, strong coding agents can exploit the same design space that human engineers use.

Workflow Design

Workflow design in harness engineering can be hand-crafted by domain experts. Taking automated research as an example, multiple frameworks have been proposed and tested. The AI Scientist system (Lu et al. 2026 (https://www.nature.com/articles/s41586-026-10265-5)) builds a pipeline for generating research ideas, writing code, running experiments, analyzing results, writing papers, and performing peer review. Meng et al. (2026) (https://arxiv.org/abs/2605.26340) in ScientistOne treat verifiability as a core design constraint: every claim (citation, number, method, conclusion) must be traceable to evidence and audited by a Chain-of-Evidence check.

AI Scientist pipeline for idea generation, experimentation, paper writing, and review. (Image credit: Lu et al. 2026)

AI Scientist pipeline for idea generation, experimentation, paper writing, and review. (Image credit: Lu et al. 2026 (https://www.nature.com/articles/s41586-026-10265-5))

Autodata Agent (Kulikov et al. 2026 (https://arxiv.org/abs/2606.25996)) is designed as a data scientist for generating training and evaluation data. The main agent manages a challenger, a weak solver, a strong solver, and a verifier/judge. Its goal is to synthesize data of “just right” difficulty — where the strong solver succeeds and the weak solver fails.

In Autodata, the challenger prompt is iteratively updated based on feedback from the solvers and verifier. The limitation here is that synthetic tasks are used to fine-tune the weak solver, not the strong solver; if the loop cannot iteratively improve the strong model, it is more like indirect distillation on the generated prompt distribution, with less RSI flavor.

Autodata’s agentic workflow design for generating synthetic training and evaluation data around challenger, solver, and verifier roles. (Image credit: Kulikov et al. 2026)

Autodata’s agentic workflow design for generating synthetic training and evaluation data around challenger, solver, and verifier roles. (Image credit: Kulikov et al. 2026 (https://arxiv.org/abs/2606.25996))

The workflow design space is huge. Therefore, it’s natural to treat workflow design as a search problem, and it should be possible to find good solutions algorithmically, not just by hand-crafting. Along this direction, Automated Design of Agentic Systems (ADAS) (Hu et al. 2025 (https://arxiv.org/abs/2408.08435)) formulates agent design as an optimization problem, i.e., “meta-agent search”: a meta-agent proposes new agentic workflow designs.

1. Initialize an archive of agentic workflows with simple agents like CoT and self-refine.
2. Ask a meta-agent to write a new agent in code inspired by existing solutions in the archive.
   • The meta-agent first generates a high-level description of the new workflow, then implements it in code.
   • The draft program then undergoes two rounds of self-refine steps performed by the meta-agent (i.e., ask the model to give feedback, then ask the same model to improve the previous output based on feedback; Madaan et al. 2023 (https://arxiv.org/abs/2303.17651)) to check novelty.
3. Evaluate each new candidate and add successful ones to the archive.
4. Repeat steps 2-3 until the maximum number of iterations is reached.

Automated Design of Agentic Systems (ADAS) diagram. (Image credit: Hu et al. 2025)

Automated Design of Agentic Systems (ADAS) diagram. (Image credit: Hu et al. 2025 (https://arxiv.org/abs/2408.08435))

AFlow (Zhang et al. 2025 (https://arxiv.org/abs/2410.10762)) represents the agentic workflow as a graph, where nodes represent calls to the LLM and edges implement logical operations in code. Workflow optimization relies on MCTS (https://en.wikipedia.org/wiki/Monte_Carlo_tree_search) (Monte Carlo Tree Search):

1. Initialize a starting workflow \(W_0\) in the tree with a template.
2. Select a workflow node using a soft mixture of score and uniform exploration.
3. Ask the LLM to generate a modified workflow based on its evaluation performance, thereby expanding the node.
4. Execute and evaluate the new workflow.
5. If the new workflow shows improvement within \(N\) rounds of budget, add it to the tree.
6. Repeat steps 2-5, and stop when the top-\(k\) average score plateaus or the budget is exhausted.

AFlow optimization process over the workflow candidate tree. (Image credit: Zhang et al. 2025)

AFlow optimization process over the workflow candidate tree. (Image credit: Zhang et al. 2025 (https://arxiv.org/abs/2410.10762))

Experiments of AFlow on QA, code, and math tasks show a decent improvement over hand-crafted workflows and ADAS.

AFlow experimental comparison against hand-crafted methods and ADAS. (Image credit: Zhang et al. 2025)

AFlow experimental comparison against hand-crafted methods and ADAS. (Image credit: Zhang et al. 2025 (https://arxiv.org/abs/2410.10762))

Self-Improving Harness

Both context engineering and workflow design are only parts of the harness. We need to search the entire design space and jointly optimize context management logic, workflow, permissions, and many other harness components. As seen in works like Meta-Harness, ADAS, and AFlow, ✨code✨ is the universal language for defining programs and systems. Simply put, harness is code that specifies how prompts, tool calls, sub-agents, control flow, memory, and workflow logic work together. If an LLM can optimize the code that executes an agent, it can access a much larger design space than hand-written prompts.

Self-Taught Optimizer (STOP) (Zelikman et al. 2023 (https://arxiv.org/abs/2310.02304)) is one of the early examples of recursive scaffolding improvement. At time \(t=0\), a seed improver \(I_0\) receives an initial solution \(s\), a utility function \(u\), and a black-box language model \(M\), and returns an improved solution \(s’\), i.e., \(s’ = I(u, s; M)\). STOP’s goal is not to directly improve \(s\), but to improve the improver \(I\) itself.

First, we define meta-utility as the average utility of an improver function \(I\) over a set of downstream tasks \(\mathcal{D}\):

\[\hat{u}(I) \triangleq \frac{1}{|\mathcal{D}|}\mathbb{E}_{(u,s)\sim \mathcal{D}}[u(I(u,s; M))]\]

Because improving the improver function is itself an optimization problem, we can recursively update \(I_t\) based on the performance of \(I_{t-1}\) (measured by meta-utility) via self-improvement:

\[I_t=I_{t-1}(\hat{u},I_{t-1};M)\]

Self-Taught Optimizer (STOP) algorithm. (Image credit: Zelikman et al. 2023)

Self-Taught Optimizer (STOP) algorithm. (Image credit: Zelikman et al. 2023 (https://arxiv.org/abs/2310.02304))

In the experiments of Zelikman et al. (2023), the improved improver discovered various strategies, such as genetic algorithms, decompose-and-improve locally, multi-armed prompt bandits, simulated annealing, temperature changes, and beam/tree search. This is like representing the harness workflow as an optimizable object.

Examples of self-improvement strategies discovered by STOP. (Image credit: Zelikman et al. 2023)

Examples of self-improvement strategies discovered by STOP. (Image credit: Zelikman et al. 2023 (https://arxiv.org/abs/2310.02304))

One cautionary result from their findings: STOP improved downstream average performance across iterations when using GPT-4, but performance degraded on weaker models like GPT-3.5 and Mixtral. The recursive structure alone is not enough. The base model must be capable enough to improve the mechanism. This suggests that harness improvements can make model deployment better, but intelligence remains core.

A more recent work, Self-Harness (Zhang et al. 2026 (https://arxiv.org/abs/2606.09498)), relies on an LLM agent to improve its own harness through a “propose-evaluate-accept” loop.

Self-Harness uses a loop of weakness mining, bounded harness proposal, and verification to update the harness. (Image credit: Zhang et al. 2026)

Self-Harness uses a loop of weakness mining, bounded harness proposal, and verification to update the harness. (Image credit: Zhang et al. 2026 (https://arxiv.org/abs/2606.09498))

The Self-Harness loop consists of three phases:

1. Weakness mining: Clustering failures into failure patterns supported by verifiers.
   • The current harness \(h_t\) is used to evaluate on tasks, and execution traces are collected for analysis.
   • Note: Two runs that share the same superficial error log (e.g., timeout or missing artifact) may have different causal mechanisms. Therefore, we need informative failure records, including terminal verifier-level reasons, causal states of related agent behavior, and abstract agent mechanisms exposed by traces, to reveal root causes.
2. Harness proposal: Based on the mined failure patterns, propose bounded harness edits.
   • The same model under \(h_t\) is called as the proposer.
   • The model receives a bounded proposal context: (1) the editable surface of the current harness, (2) failure patterns supported by verifiers in the evaluation system, (3) records of passing behavior that should be preserved, and (4) a summary of previously attempted edits.
   • Harness edits should prioritize recurring, tractable error patterns (e.g., not because the task itself is too hard) and should be fixable with narrow modifications.
   • Harness edit candidates should be distinct and diverse.
3. Proposal verification: Verify and merge qualifying edits to create a new harness \(h_{t+1}\).
   • Candidate edits are evaluated via regression tests on held-in \(D_\text{in}\) (to test if the weakness is resolved) and held-out \(D_\text{out}\) (to check for unintended issues).
   • Only candidates that show no regression on both held-in and held-out data are accepted.
   • Accepted candidates are merged to update the harness to \(h_{t+1}\); rejected candidates are recorded but do not affect the active harness.

When running MiniMax M2.5, Qwen3.5-35B-A3B, and GLM-5 on Terminal-Bench-2, Self-Harness was shown to learn model-specific harness instructions tailored to the weaknesses of different base models and improve the held-out pass rate.

Works like Self-Harness do make me worry: if a program is allowed to edit the operating system, the abstraction boundary is broken. The editable surface needs to be carefully designed, and permission control and security layers must sit outside this loop. All challenges around reward hacking (https://lilianweng.github.io/posts/2024-11-28-reward-hacking/) still exist.

Evolutionary Search

Evolutionary search is an optimization method inspired by natural selection (see my earlier post on evolutionary algorithms (https://lilianweng.github.io/posts/2019-09-05-evolution-strategies/)). It evolves a population of solutions by mutating them and retaining only those with high “fitness.” Evolutionary search is useful when (1) the search space is very large or oddly shaped, and (2) it is difficult to optimize directly with gradients, but evaluating solutions is easy. Harness search seems well-suited for this approach.

In past research, evolutionary search has been used for prompt engineering. Promptbreeder (Fernando et al. 2023 (https://arxiv.org/abs/2309.16797)) optimizes task-specific prompts through a rich set of mutation operations; interestingly, the mutation prompts (i.e., instructions telling the LLM to mutate the task prompt) are themselves evolved and improved. GEPA (Agrawal et al. 2025 (https://arxiv.org/abs/2507.19457)) combines reflective (https://lilianweng.github.io/posts/2023-06-23-agent/#self-reflection) prompt methods with evolutionary search, using natural language reflections on trial-and-error trajectories to propose prompt updates.

Novikov et al. (2025) (https://arxiv.org/abs/2506.13131) proposed AlphaEvolve, an evolutionary search system for coding agents. It maintains a pool of candidate programs and prompts a frozen LLM to generate diffs for improvement. As the system repeatedly evaluates sub-programs and retains winners, it discovers better solutions over time.

How AlphaEvolve works. (Image credit: Novikov et al. 2025)

How AlphaEvolve works. (Image credit: Novikov et al. 2025 (https://arxiv.org/abs/2506.13131))

Several details in the AlphaEvolve design are important:

• The prompt includes parent program, results, instructions, and sometimes meta-information.
• The coding agent has access to the full repository, but the code region for improvement is explicitly marked with # EVOLVE-BLOCK-START and # EVOLVE-BLOCK-END.
• Meta-prompts co-evolve with instructions and context, similar to how we evolve solution programs.

Ablation studies show the value of the evolutionary flow, context in the prompt, meta-prompts, full-file evolution, and using a stronger LLM.

Ablation studies demonstrating the value of multiple design choices in AlphaEvolve. (Image credit: Novikov et al. 2025)

Ablation studies demonstrating the value of multiple design choices in AlphaEvolve. (Image credit: Novikov et al. 2025 (https://arxiv.org/abs/2506.13131))

Recent variants, such as ThetaEvolve (Wang et al. 2025 (https://arxiv.org/abs/2511.23473)), combine evolutionary search with RL and in-context learning. On the other hand, ShinkaEvolve (Lange et al. 2025 (https://arxiv.org/abs/2509.19349)) introduces three new components to improve LLM sampling efficiency:

• By designing parent sampling to balance performance rank and number of offspring, achieving higher sampling efficiency in exploration.
• Code novelty rejection sampling: discarding candidates too similar to existing population based on embedding cosine similarity.
• Identifying good patterns in successful solutions within a meta-scratchpad to guide future mutations.

Unlike the above methods focusing on solution improvement, the Darwin Gödel Machine (DGM) (Zhang et al. 2025 (https://arxiv.org/abs/2505.22954)) explicitly targets the evolution of an editable harness-code repository, using an LLM-based coding agent. Specifically, the agent is allowed to modify its own harness. Later work on Hyperagents (Zhang et al. 2026 (https://arxiv.org/abs/2603.19461)) introduces a meta-agent that controls how to modify existing task agents to create new ones.

1. Start with one coding agent in the pool.
2. In each iteration, select a parent with probability proportional to performance and inversely proportional to offspring count, modify it, and fork to create a new agent.
3. The selected parent agent inspects its own benchmark evaluation logs, then proposes improvements to its own harness codebase, generating a new version of the coding agent. Code editing is done through two basic tools: (1) bash (params: ``) and (2) editor (params: view/create/edit <file>).
4. The new coding agent is evaluated, and only those with sufficiently high performance are added to the pool.
5. Repeat steps 2-4 until certain stopping conditions are met.

DGM is harness evolution under a fixed model. In experiments with Claude 3.5 Sonnet as the base LLM and a simple initial harness configuration, agents discovered by DGM matched or even exceeded hand-crafted agents on SWE-bench Verified (20% to 50%) and Polyglot (14.2% to 30.7%).

Such methods are effective when candidate solutions can be automatically evaluated and candidate fitness is easy to quantify, e.g., matrix multiplication, GPU kernel optimization, algorithm competitions, data center scheduling. They struggle in domains with slow evaluation, ambiguity, or heavy reliance on heuristics. The computational efficiency and effectiveness of evolution are also concerns.

Joint Optimization with Model Weights

Harness evolution changes the non-parametric parts around the model, while the model weights remain fixed. But what if we optimize both together?