Skip to content

Harness Engineering for Self-Improvement

Source: Harness Engineering for Self-Improvement \ Date Published: 2026-07-04 \ Author: Lilian Weng (OpenAI) \ Read time: ~25 min


TL;DR

A harness is the software system surrounding a base LLM — orchestrating how it thinks, plans, calls tools, manages context, stores artifacts, and evaluates results. Lilian Weng argues that harness engineering, distinct from core model intelligence, is the most practical near-term path to recursive self-improvement (RSI). She surveys the rapidly expanding taxonomy: context engineering (ACE → MCE → Meta-Harness), workflow optimization (AI Scientist, ADAS, AFlow), self-improving harnesses (STOP, Self-Harness), evolutionary program search (AlphaEvolve, Darwin Gödel Machine), and joint weight-harness optimization (SIA). The post closes with seven open challenges — weak evaluators, memory lifecycle, negative results, diversity collapse, reward hacking, long-term success, and the role of humans.

The Case for Harness Engineering

The concept of recursive self-improvement dates to I. J. Good (1965) and was popularised by Yudkowsky (2008): an AI uses its own intelligence to improve the cognitive machinery that produces that intelligence. Modern AI labs show dramatically accelerated research loops (Anthropic, OpenAI).

Weng's key insight: the layer between a raw model and its real-world deployment — the harness — may be as important as the model's raw intelligence. The success of coding agents like Claude Code and Codex demonstrates this empirically. A harness is defined as the system that:

  • Orchestrates how the model thinks and plans
  • Controls tool calling and action execution
  • Manages perception and context
  • Stores artifacts and persistent state
  • Evaluates results and iterates

Harness Design Patterns

Three core architectural patterns emerge across successful harness implementations:

1. Workflow Automation

A goal-oriented loop: plan → execute → observe/test → improve → repeat until done. Karpathy's autoresearch repo exemplifies this. The model analyzes its own trajectories and failure cases through an "agent runtime" rather than a static prompt template.

2. File System as Persistent Memory

Long-horizon agentic rollouts produce artifacts (experiment logs, code diffs, error traces, past trajectories) that far exceed any context window. Rather than stuffing everything into context, harnesses should keep durable state in files. LLMs naturally know how to read/write the file system via bash — so this skill compounds with core model improvements.

3. Sub-agents and Backend Jobs

Spawning parallel sub-agents for concurrent exploration, and monitoring backend jobs, keeps the main agent's context clean. The key design choice: make parallelism explicit and inspectable by storing outputs as files, logs, and status records — not transient chat context.

Case Study: Coding Agent Harness

The tool interface across Claude Code, Codex, OpenCode, and Cursor has stabilised into a common pattern: file system ops (glob, grep, read, write, edit, patch), shell execution, git tools, MCP/skills for external context, web search, artifact rendering, backend process management (cron), and agent delegation (spawn, resume, wait, interrupt).

Harness vs Core Intelligence

Weng predicts the near-term RSI path is not a model rewriting its own weights, but rather:

Model → harness improves deployment → better data → better successor model

Eventually, harness improvements may be internalised into core model behaviour, just as manual prompt tricks faded with better instruction tuning — but the need to specify goals, constraints, context, and evaluation will not disappear.

Harness Optimization

The progression of what gets optimised: prompts → structured context → workflow → harness code → optimizer code.

Context Engineering

System What it optimises How
ACE (Zhang et al. 2025) Context as evolving playbook Curator outputs structured itemised bullets (id, description); deterministic merge avoids context collapse
MCE (Ye et al. 2026) Skill + context jointly Bi-level: meta-agent evolves skills via crossover over prior history; base agent executes skill to engineer context from rollout feedback
Meta-Harness (Lee et al. 2026) Harness code itself Meta-level harness proposes & evaluates candidate harnesses on Pareto frontier; the proposer is itself a coding agent

The key lesson: once harness design becomes an executable search space, a strong coding agent can exploit the same design space human engineers use.

Workflow Design

System Design Key Insight
AI Scientist (Lu et al. 2026) Pipeline: propose → code → run → analyse → write → review Full automation of research paper loop
ScientistOne (Meng et al. 2026) Verifiability-first Every claim traces to evidence via Chain-of-Evidence audits
Autodata (Kulikov et al. 2026) Challenger → weak solver → strong solver → verifier Synthesises "just right" difficulty data; limitation: doesn't improve the strong model
ADAS (Hu et al. 2025) Meta-agent search for agent designs Agent design as optimisation problem
AFlow (Zhang et al. 2025) MCTS over workflow graphs Nodes = LLM invocations; edges = code logic. Outperforms ADAS and manual designs on QA, code, math

Self-Improving Harness

STOP (Zelikman et al. 2023) is an early exemplar: a seed improver I₀ takes a solution s, utility u, and black-box LM M, returning an improved solution. The goal is to improve the improver itself. Interestingly, STOP improved performance with GPT-4 but degraded with GPT-3.5 and Mixtral — recursive structure alone is insufficient; the base model must be capable enough.

Self-Harness (Zhang et al. 2026) implements a propose-evaluate-accept loop where LLM agents improve their own harness. Applied to MiniMax M2.5, Qwen3.5-35B-A3B, and GLM-5 on Terminal-Bench-2, it learned model-specific harness instructions targeting individual model weaknesses.

Safety concern: If a program can edit the OS, abstraction boundaries are broken. The editable surface must be carefully designed, with permission control and security outside the self-improvement loop.

Evolutionary methods fit harness search because the space is large/weird-shaped and evaluation is easier than gradient-based optimisation.

Method Mechanism Scope
Promptbreeder (2023) LLM mutates task prompts; mutation prompts also evolve Prompts
GEPA (2025) Reflection + evolution Prompts
AlphaEvolve (2025) Frozen LLMs generate diffs; pool of candidate programs evolves Programs
ThetaEvolve (2025) Evolution + RL + ICL Programs
ShinkaEvolve (2025) Better sampling efficiency Programs
Darwin Gödel Machine (2025) Coding agent evolves its own harness code Harness code
Hyperagents (2026) Meta-agent controls how to modify task agents Agent architecture

DGM is particularly notable: using Claude 3.5 Sonnet with simple initial harness configs, evolved agents improved from 20% → 50% on SWE-bench Verified and 14.2% → 30.7% on Polyglot.

These methods work best when fitness is cheap and objective (matrix multiplication, GPU kernels, algorithm contests). They struggle with slow, ambiguous, or heuristic-based evaluation.

Joint Optimization with Model Weights

SIA (Hebbar et al. 2026) combines harness improvement and model parameter updates in one loop, with three components: a task agent, a meta-agent proposing harness changes, and a feedback agent analysing trajectories. Results are preliminary — the task agent was much weaker than the meta-agent — but the direction is interesting.

Seven Future Challenges

  1. Weak and fuzzy evaluators — Self-improvement loops work best with measurable, objective metrics. Research taste, novelty, and long-term scientific value are much harder to evaluate. This mirrors how RL needs well-defined reward functions.

  2. Context and memory lifecycle — As agents become more autonomous, context engineering must become a core part of intelligence, not just a software layer. Humans maintain memory across a lifetime; agents need analogous mechanisms.

  3. Negative results — The literature is biased toward successes. LLMs trained on this data may be bad at knowing when to abandon a hypothesis. A research harness should make failed attempts easy to preserve.

  4. Diversity collapse — Evolutionary and RL loops tend to exploit known high-reward patterns. Mechanisms for exploration (similar to intrinsic motivation in DRL) are needed to prevent population collapse.

  5. Reward hacking — Self-improvement optimises whatever signal it is given. Unit tests → overfitting. Judge models → reward hacking. Benchmarks → artifact exploitation. The evaluator and permission control must sit outside the evolution loop.

  6. Long-term success — Coding agents complete immediate tasks well, but standard sandbox RLVR doesn't capture maintainability, ownership boundaries, migration cost, or future debugging burden. We need optimisation over longer horizons.

  7. The role of humans — Humans should move up the stack, not be removed. Human oversight at the right abstraction level, at the right time, remains essential.

Key Takeaways

  1. Harness engineering is the near-term RSI path. Instead of models rewriting their own weights, the practical loop is: harness improves deployment → better data → better successor model.

  2. Code is the universal language of harness optimisation. Once harness design becomes executable search space, coding agents can exploit the same space human engineers do — with evolution, MCTS, and self-play.

  3. Recursive improvement requires a capable base model. STOP degraded with weaker models. Harness engineering enables better deployment, but core intelligence remains the bottleneck.

  4. Safety must be designed into the outer loop. The editable surface, permission controls, evaluator, and human oversight must all sit outside the self-improvement loop to prevent reward hacking and abstraction-boundary violations.