AI Self-Evolution Starts Outside the Model: Lilian Weng on Harness Engineering
- Lilian Weng, former head of OpenAI's safety systems, published an article proposing "harness engineering": the runtime system wrapped around AI models responsible for tool invocation, context management, memory, and evaluation. It is a critical, yet often overlooked, component for AI Recursive Self-Improvement (RSI).
- She categorizes the objects being optimized within the harness into an advancement ladder: prompts, structured context, workflows, the harness code itself, and then optimizer code; the higher up, the larger the searchable design space.
- The article reviews over 20 studies from 2023 to 2026, including ACE, MCE, Meta-Harness, STOP, Self-Harness, AlphaEvolve, and DGM, demonstrating that AI can now propose changes to its own "shell," run tests, and retain stronger versions.
- Empirical evidence shows self-evolution is effective: DGM evolved a programming agent from 20% to 50% on SWE-bench Verified; however, STOP's experiments also indicate this mechanism only works if the underlying model is strong enough, with weaker models showing degradation.
- The article concludes by listing 7 current bottlenecks on this path: weak and ambiguous evaluation metrics, reward hacking, diversity collapse, etc., emphasizing that humans must remain in supervisory roles at critical junctures, rather than being removed from the loop.
Why the "stuff" outside the model suddenly matters
Lilian Weng, former head of OpenAI's safety systems, published a lengthy article on her personal blog, Lil'Log, proposing the concept of "harness engineering" and systematically connecting it to the research direction of AI Recursive Self-Improvement (RSI).
Her core argument is simple: the system layer between the model and the real world is as important as the model's raw intelligence itself. People tend to focus on how smart a model is, often underestimating the outer shell that wraps around it, orchestrating everything.
Why it's worth reading: The idea of RSI can be traced back to I.J. Good's "ultraintelligent machine" (a machine capable of creating machines smarter than itself) in 1965, and Yudkowsky coined the term "recursive self-improvement" in 2008. Modern versions could involve models directly rewriting their own weights, or models improving training pipelines and deployment systems—a more indirect yet more realistic path. Weng points out that Anthropic and OpenAI have both observed a significant acceleration in research pace at leading labs.
Weng's assessment is that, in the near term, RSI is unlikely to start with models directly altering their own weights. It's more probable that it will first manifest at the "deployment system" layer, and the most critical component within deployment systems is the harness—the system behind successful programming agent products like Claude Code and Codex. This article focuses specifically on research surrounding harness engineering and how it progressively leads to self-improvement.
What exactly is a harness?
A harness is the entire system wrapped around a base model, responsible for orchestrating the entire execution process, determining how the model thinks and plans, how it calls tools to act, how it perceives and manages context, where it stores outputs, and how it verifies the correctness of results.
Early discussions of agents used the formula "agent = model + memory + tools + planning + action." Harness engineering adds several more layers on top of this: workflow design (e.g., how to design the loop), evaluation, access control, and persistent state management. It's already very close to runtime and software system design, addressing how the model observes, acts, remembers, self-checks, and improves—the entire process.
The relationship between a harness and a model is much like that between an operating system and a CPU: the model is the CPU that provides raw computing power, and the harness is the operating system running around it, handling "dirty work" like scheduling, access control, and file storage. Like an operating system, a good harness hides complex logic internally, while maintaining a simple external interface. Weng also mentions that as the industry evolves, protocols for configuration and tool interfaces will gradually become standardized.
Letting the Model Plan, Remember, and Multitask on its Own
Weng first presents three concrete, actionable harness design patterns. They all address the same question: What foundational pieces are needed for a system that can work autonomously for extended periods?
Paradigm One: Give the model an iterative workflow
The key is to first define a process within which the model can "act, test, and revise." A common approach is a goal-oriented loop: first plan, then execute, then observe or test the results, then improve, and execute again, repeating the cycle until the goal is achieved. During this process, it can also proactively ask the user for clarification. Karpathy's autoresearch repository is a clean example of this type of workflow. This loop particularly emphasizes one point: the model should analyze its past trajectories and failure cases, and then iterate based on these, rather than strictly adhering to a fixed prompt template.
Paradigm Two: Use the file system as the model's long-term memory
For agents working for extended periods, experiment logs, code diffs, paper abstracts, error records, and past execution trajectories will quickly grow longer than the context window the model saw during training. Therefore, the harness should not force the entire process and all logs into the context; instead, it should write these persistent states into files and read them back when needed. Reading, writing, and modifying files (typically via bash commands) are fundamental skills for AI models. Managing long-term memory in this simple file-based manner naturally improves as the model's capabilities enhance.
Paradigm Three: Dispatch sub-agents to work in parallel, while maintaining control
A harness can spawn multiple sub-agents to execute in parallel, and then monitor these background tasks. This is useful when the main agent needs to test several hypotheses simultaneously, run experiments in parallel, or offload independent sub-tasks without polluting the main context. In this scenario, the main agent needs a small process manager: capable of launching tasks, viewing logs, canceling failed runs, and merging results back into the main thread.
The most critical design here is to make parallelism inspectable and traceable. If the output of sub-agents only exists in ephemeral conversational context, they will quickly become outdated and submerged; only by storing them as files, logs, and state records can the model recover after interruption and review its execution history.
Combining these three pieces forms the current state of mainstream programming agents. Weng points out that the core interfaces of products like Claude Code, Codex, OpenCode, and Cursor have converged, all relying on a similar set of tools:
