Understanding Harness²: How AI agents can improve themselves without retraining their models

1. The main idea

Harness² is a framework that allows an AI agent to improve the system around its language model, learn from those improvements, and apply that experience to future tasks.

Imagine using the same AI model for two programming tasks. On one task, it struggles to use tools correctly. On another, it keeps researching instead of producing code. Instead of replacing the model or manually rewriting its instructions, Harness² experiments with changes to its prompts, tools, memory, and workflows. It runs the task again, observes what changes, and preserves useful lessons for the future.

The researchers investigate two important questions. Can an agent improve its own working environment without knowing the correct answer in advance? And can it learn how to make better improvements over time?

The AI doesn't just improve how it performs tasks. It improves how it improves itself.

2. Background I need first

Four concepts unlock most of this paper.

Concept 1: A model is not the same thing as an agent

A large language model takes context and generates a response. By itself, it doesn't necessarily have access to your filesystem, shell, browser, or GitHub.

An AI agent is a system that combines a model with mechanisms for taking actions, examining their results, and deciding what to do next.

For a web engineering analogy: the model resembles a powerful decision engine. The harness resembles the application layer, integrations, configuration, and execution infrastructure around that engine.

The analogy isn't exact, because the model is probabilistic and can make decisions about its own tool use. But it highlights an important point: changing the surrounding architecture can change the system's performance without changing its underlying model.

Concept 2: What exactly is a harness?

A harness is the configurable system that controls how an agent works. Harness² exposes eight editable components, grouped below by their main purposes. These are executable or loadable runtime components, not just different sections of a single prompt.

If a coding agent repeatedly attempts to call a nonexistent tool, you might improve its tool guidance rather than its system prompt. If it keeps forgetting an architecture decision, you might improve its memory. If it struggles with multi-stage delivery, you might introduce a skill explaining the workflow.

The paper treats these components as files that an improvement agent can modify and test.

Concept 3: What does recursive self-improvement mean?

Recursive self-improvement means a system makes changes to itself, and those changes influence how later improvements happen.

Ordinary improvement: an AI agent executes a task, receives feedback, and tries the task again.

Recursive improvement: an AI agent learns that a particular workflow was ineffective, changes its own workflow, and later uses what it learned to design better workflows for different tasks.

The key distinction is persistent improvement of the improvement mechanism, not simply repeated attempts. Harness² changes the agent's harness, not the neural network's trained parameters.

Concept 4: What if you don't know the correct answer?

This is one of the central research challenges. In ordinary software testing, you often have a clear acceptance criterion:

expect(calculateTotal([100, 50])).toBe(150);

That's a ground-truth verifier: something reliable that tells you whether the answer is correct. But imagine asking an agent to produce an architecture proposal, investigate a production incident, or write a legal analysis. There might be no single correct output that an automated checker can verify.

So how can you tell whether changing the agent's harness helped? Harness² uses contrastive evidence: compare what the agent actually did before and after a change. Did it start executing real tests instead of merely describing them? Did it create the requested files? Did it stop repeating unsuccessful tool calls?

These are useful observations, but they are not proofs of correctness. The paper explicitly acknowledges that distinction.

3. Walk me through the paper

Step 1: Understand the two levels of improvement

The framework separates the system into two harnesses.

The execution harness is the configuration used by the agent to accomplish the current task. The improvement harness is the configuration used by the system that investigates, tests, and improves execution harnesses.

The execution harness can be customized for a particular task. But the next task starts again from a common base harness. Instead of blindly reusing the previous task's specialized setup, the improvement system retrieves relevant lessons and components.

That matters because a technique that helps debug a failing data pipeline might be harmful when an agent is designing a user interface. The system must learn which changes are reusable and under what conditions.

Step 2: Propose — identify weaknesses and possible fixes

The framework first runs the current agent with its existing harness. This produces a reference execution, including the trajectory of actions, tool calls, and observations, and the deliverable: the final files, document, code, or other output.

The improvement process then proposes two types of modifications. Invariant modifications address general problems that appear in many domains: poor planning, context management, incorrect tool use, or failure to delegate. Domain-specific modifications address problems tied to the task environment, for example how to inspect a Kubernetes deployment, handle a particular data format, or follow legal document requirements.

The researchers separate these because a general agent deficiency and missing domain expertise often require different solutions.

Step 3: Probe — test candidate harnesses against the same task

Each proposed harness runs the same task, using matched model and environment configurations. Consider an agent that keeps talking about running tests without actually invoking the test runner. The improvement system could compare:

The table doesn't establish which output is ultimately correct. It establishes what changed in the agent's behavior. That is the contrastive part of the method.

Step 4: Compose — assemble a better harness

The composer reviews the original execution, candidate changes, file differences, and probe results. It can keep the original harness, adopt one candidate, merge compatible improvements, or revise conflicting changes. The resulting harness then executes the task again.

This is more sophisticated than simply selecting whichever candidate gives the most impressive-looking answer. The composer is meant to connect its decisions to observed evidence. Because that evidence is imperfect, it can still choose badly.

Step 5: Repeat the process — in parallel or sequentially

Harness² supports two approaches to spending extra improvement effort.

Parallel recursion explores multiple alternatives from a common starting point. Sequential recursion improves one version, then uses it to produce the next.

A parameter called k controls the exploration budget. In parallel mode, k determines how many candidates of each scope are probed and how many compositions are produced. In sequential mode, it determines the number of successive improvement steps. Parallel mode explores more widely. Sequential mode explores more deeply. Neither approach inherently guarantees a better result.

Step 6: Reflect — learn how to improve future tasks

This is the second, particularly important part of the paper. After selecting the deliverable, an experience reflector examines the improvement history. It tries to identify what initially went wrong, which changes altered the behavior, what evidence supported those changes, and under what conditions the changes might be useful again.

The system saves an adopted executable harness alongside an EXPERIENCE.md file explaining the supporting evidence and lessons. When another task arrives, the improvement system can consult this library.

The system preserves knowledge about the improvement process, not only a final prompt or successful output.

Step 7: Evaluate whether it actually works

The authors tested Harness² on three benchmarks with four combinations of underlying model and execution environment.

These are the authors' reported maximum improvements across the evaluated configurations, not guaranteed gains for every task. The LAB measure is a proportion of grading criteria passed, rather than a whole-task success rate.

A particularly interesting result is that a weaker model with an improved harness sometimes outperformed a stronger model with its original harness. For example, on WorkBuddy-Bench using OpenCode:

This does not mean GLM-5 is generally stronger than Gemini. It means that, in this specific evaluation, improvements to the runtime were enough to overcome the original performance gap.

The researchers also performed ablation studies: experiments that remove one component of a system to see how much it contributes. On the reported WorkBuddy-Bench setting:

That matters because it suggests the improvements aren't coming solely from rerunning the task more times. The library, proposal strategy, and composition process each contribute to performance.

Step 8: Understand the limitations

The authors are explicit about some shortcomings.

First, additional executions cost more tokens and computation. A complex task may need several full agent runs, editor sessions, and composition steps before producing its final result.

Second, behavioral contrast does not prove correctness. If multiple executions share the same faulty assumption, the improvement system may preserve it.

Third, the paper documents failures where the selector chose a worse deliverable, including an example in which it selected an output scoring 55 over one scoring 95 in retrospective evaluation.

Finally, the released framework does not restrict executor network access by default, and its Codex integration disables the sandbox. The repository warns that public benchmark answers and grading criteria could be accessed during execution. Real-world deployments therefore need independent isolation and network controls.

Harness² demonstrates a promising optimization strategy, but it is not a proven autonomous engineering system that can safely improve itself indefinitely. Its gains are bounded by the quality of its observations, its evaluation budget, and its environment.

4. Important terms explained

5. A concrete example

Let's apply these ideas to something familiar: an AI development agent working on an online store built with Next.js, a headless CMS, and a CDN. This is my illustrative example, not a particular experiment reported by the authors.

The task

After updating a product price in the CMS, the store still displays the old price. Investigate and fix the issue.

Your existing AI agent can access a repository, execute shell commands, inspect API responses, and read build logs. On its first attempt, the agent reads frontend components, guesses that React caching is responsible, and changes a component without checking the underlying data pipeline.

The problem isn't necessarily the model's intelligence. It could be that the agent lacks a reliable investigation process.

How Harness² could investigate

1. Run the original harness. The agent edits the React component but fails to examine the CMS API response or the store's build and caching behavior. This becomes the reference execution.
2. Propose a general improvement: a guardrail requiring evidence of the failure before modifying application code. Inspect logs, reproduce the bug, and record a testable hypothesis.
3. Propose a domain-specific improvement: a skill describing the path from the CMS through the API to the Next.js build and the CDN cache, including how to inspect content timestamps and cache invalidation.
4. Probe both candidates. Execute the same task with each modified harness. Observe whether the agent checks the relevant system boundaries and whether it creates a defensible fix.
5. Compose a refined harness. If the evidence supports both changes, combine the general investigation guardrail with the domain-specific troubleshooting skill, then execute the task again.
6. Reflect and save experience. Record which procedures helped diagnose the issue, what evidence supported them, and when similar procedures could be useful again.

Suppose the improved agent discovers that the CMS content is current, but the CDN kept serving the cached page and the build never picked up the change. The important result isn't simply that it fixed one bug. It has potentially learned an improvement strategy:

For stale-content issues in multi-stage publishing systems, inspect each boundary and verify where the expected change disappears before modifying presentation code.

This procedure might apply to future systems involving Next.js caching, CDN invalidation, static site generation, or event-driven pipelines. But the system should reuse the investigation strategy, not blindly copy the fix for this one store setup.

How this differs from simply giving an AI better instructions

A conventional approach might be to write:

Always inspect backend data before changing frontend code.

Harness² instead tries to establish whether that instruction changes behavior in the desired way, and whether the resulting lesson is worth preserving. There is a subtle but important difference between telling an agent what should work and testing what actually changes its behavior.

That is the central engineering lesson I would take from this research.

6. What I should remember

Agent capability isn't determined by the model alone. Prompts, tools, memory, delegation, and execution infrastructure can materially affect performance. Before switching to a more powerful model, consider whether the harness is the real bottleneck.

Compare behaviors, not just final answers. Observing tool calls, failed steps, missing artifacts, and workflow changes can reveal why an improvement helped, even when you don't have an automated correctness test.

Improving the improvement process is the real innovation. Harness² doesn't merely update an individual agent configuration. It retains evidence about how useful changes were discovered, helping future improvement attempts.

Reusable lessons need context. Store the circumstances, observed failure, attempted changes, and supporting evidence, not just a prompt that worked once. This is especially useful for agents that work across multiple repositories and technology stacks.

Self-improvement still requires external safeguards. More iterations don't guarantee correctness. Test against independent acceptance criteria, control costs, isolate executable changes, and keep human approval for consequential actions.

Optional: go deeper

If you want to explore the actual framework rather than only the research, the repository provides a local demonstration that doesn't require model credentials:

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

Run this from a checkout of the repository on Linux. The demo uses deterministic improvement logic and real Python executions, making it a useful introduction before paying for model-backed experiments. The distinction to keep in mind is that this demo exercises the architecture. It doesn't independently reproduce the paper's reported AI benchmark gains.

For a more technical second reading, I would focus on sections 2.2 and 2.3 of the paper and the experiment guide. Together they explain the mechanism, evidence handling, and practical reproducibility concerns.

Can we build software agents that accumulate engineering knowledge not merely by remembering previous tasks, but by learning which development processes consistently produce better results? Harness² is one concrete attempt to answer that question.

Sources

• Harness² — GitHub repository
• Harness² — research paper
• Experiment guide