Google Research Open-Sources Harness²: AI Agents That Improve Their Own Prompts, Skills, and Memory

Key Takeaways

• Harness² is an open-source framework for recursively improving AI agent harnesses. Developed by researchers from Google Cloud AI Research and Northwestern University, it optimizes the systems surrounding language models rather than retraining the models themselves.
• Agents can experiment with eight configurable components, including system prompts, guardrails, memory, skills, tool guidance, scripts, subagents, and plugins.
• Its central innovation is a two-level improvement process. Task-level recursion discovers better configurations for an individual task, while harnessing-level recursion preserves useful configurations and lessons for future tasks.
• The reported benchmark gains are substantial. A single improvement step increased GLM-5's WorkBuddy-Bench average from 64.2 to 75.7 points under OpenCode, an 11.5-point improvement. The researchers also reported gains of up to 4.5 points on JobBench and 11.8 percentage points on LAB's partial pass rate.
• Harness² does not require ground-truth answers during optimization. It compares agent execution traces and deliverables under different configurations, although external benchmarks still use grading systems to evaluate final performance.
• The framework is available on GitHub under Apache 2.0, with support for OpenCode and Codex executors. Third-party benchmark components have separate licenses.
• The biggest limitations are inference costs, imperfect candidate selection, security exposure, and uncertain generalization. The research demonstrates promising results, not guaranteed autonomous improvement in every production workflow.

Google Research's Harness² introduces an important change in how AI agents can be developed: instead of requiring engineers to manually optimize every prompt, tool instruction, or skill, an agent can experiment with alternative configurations and use execution evidence to determine which changes appear useful.

The accompanying paper, Harness²: Recursive Agent Harnessing for an Open World, was submitted on October 9, 2026. The implementation is publicly available in the google-research/harness2 GitHub repository, alongside an interactive research demonstration.

The development represents a shift from optimizing individual AI responses toward optimizing the infrastructure responsible for producing those responses.

What Is Harness²?

Harness² is a framework for recursive agent harnessing, a process in which AI agents systematically improve their own execution configurations and learn from the improvement process.

An AI agent is more than a language model. Its practical capabilities also depend on the surrounding runtime, including instructions, context construction, available tools, memory, task orchestration, and verification procedures.

This surrounding system is called an agent harness.

A simplified representation is:

AI Agent = Language Model + Agent Harness

Agent Harness =
  System Prompts
  + Guardrails
  + Memory
  + Skills
  + Tool Guidance
  + Scripts
  + Subagents
  + Plugins

Two agents using the same underlying model can perform differently because their harnesses make different information, tools, and procedures available at the right time.

For example, a coding agent may repeatedly fail to verify its modifications. Improving its model is one possible solution, but changing the execution harness to require test execution and file verification may address the problem more directly.

Harness² explores this second approach. The underlying model weights remain fixed while the execution harness evolves.

The framework is particularly relevant to open-world tasks, where agents encounter new requirements that were not available when their initial configurations were designed.

It is important to distinguish Harness² from an officially supported Google product. The repository explicitly identifies the project as research software without official Google product support.

How Harness² Works: Propose, Probe, and Compose

The central mechanism is called Propose–Probe–Compose, a contrastive optimization procedure that uses observed behavior rather than known correct answers to guide harness modifications.

Step 1: Establish a Reference Execution

A task is first executed using the existing harness.

The system records the agent's behavior, including its tool interactions, execution trajectory, intermediate actions, and final deliverable.

For example, an agent preparing a spreadsheet might create formulas successfully but fail to reopen the workbook and verify whether those formulas calculate correctly.

The reference execution reveals this behavior. It does not independently establish whether every part of the final answer is correct.

Step 2: Propose Alternative Harnesses

Harness² generates two different kinds of candidate improvements.

• Invariant improvements address general agent weaknesses, such as planning, context management, tool selection, verification, and delegation.
• Domain-specific improvements address requirements particular to the current task, such as spreadsheet validation, software testing, legal document analysis, or browser automation.

For the spreadsheet example, an invariant candidate might require the agent to verify generated artifacts before completion.

A domain-specific candidate might introduce a spreadsheet skill that checks formula references, missing cells, and unexpected calculation errors.

These candidates are actual modifications to executable harness components rather than merely alternative final answers.

Step 3: Probe Candidates on the Same Task

Each modified harness executes the original task under matched model and environment configurations.

The framework compares the resulting execution trajectories and deliverables with the reference run.

This produces a behavioral contrast: did the candidate address the suspected weakness, introduce another problem, or leave the behavior largely unchanged?

Crucially, a behavioral improvement is not proof of correctness. Multiple candidates can share the same mistaken assumption, and stochastic model behavior can make an ineffective modification appear successful.

Step 4: Compose a Refined Harness

The composition stage examines the candidate modifications, their execution evidence, and their differences from the starting configuration.

It can retain useful edits, combine compatible changes, revise conflicting modifications, select one candidate, or preserve the original harness.

The resulting harness is executed again to produce the task's final deliverable.

A simplified workflow looks like this:

New Task
   |
   v
Run Base Harness
   |
   v
Inspect Execution Evidence
   |
   +--> Propose General Improvement
   |         |
   |         v
   |       Probe A
   |
   +--> Propose Domain Improvement
             |
             v
           Probe B
   |         |
   +---------+
   |
   v
Compare Behavioral Differences
   |
   v
Compose Refined Harness
   |
   v
Execute Final Harness
   |
   v
Reflect and Preserve Lessons

This design is more sophisticated than asking an agent to retry a task repeatedly. Harness² changes the configuration responsible for the agent's behavior and records evidence about why individual changes may help.

The Two Levels of Recursive Self-Improvement

Harness² gets its name from combining two connected forms of recursion.

1. Task-Level Recursion: Improve the Current Execution

Task-level recursion focuses on a single task.

The framework offers two approaches:

Parallel recursion explores multiple candidate harnesses simultaneously. With a budget of k, it probes k general candidates and k domain-specific candidates, then produces k compositions using the combined evidence.

Sequential recursion applies successive Propose–Probe–Compose steps. Each iteration starts from the refined harness produced by the previous step and can inspect accumulated execution evidence.

Parallel recursion explores a wider set of potential improvements. Sequential recursion investigates a chain of progressively modified configurations.

The --k parameter controls the exploration budget. A larger value increases available evidence and possible improvements, but also introduces additional model calls and execution costs.

Importantly, parallel recursion in the released implementation performs one population update. It should not be confused with unrestricted evolutionary search across indefinitely many generations.

2. Harnessing-Level Recursion: Improve Future Improvement

The second recursion level is what makes Harness² particularly distinctive.

After completing a task, the framework reviews the reference execution, candidate modifications, probe results, composition decisions, and adopted harness.

It then updates a persistent improvement library containing reusable harness components and evidence-supported experience.

Each library entry can include an executable harness and an EXPERIENCE.md document describing the relevant situation, observed weakness, attempted changes, and supporting evidence.

When another task arrives, Harness² can consult this accumulated experience to propose more informed modifications.

There is an important architectural detail: each new task begins with the common base execution harness, not automatically with the previous task's modified harness.

Earlier configurations are selectively reused or adapted through the improvement process. This reduces the risk of blindly carrying specialized instructions into unrelated tasks.

The model weights and core improvement algorithm remain fixed. The persistent learning occurs through the evolving library of configurations and lessons.

The Eight Harness Components Agents Can Optimize

Harness² exposes eight editable components, organized around the different layers of an agent runtime.

These components affect different parts of the execution process.

System prompts, guardrails, memory, and tool guidance can influence every model call. Skills are loaded when invoked, allowing specialized instructions to remain outside the context until needed.

Scripts provide deterministic operations that would otherwise require repeated model reasoning. Subagents introduce additional execution contexts, while plugins can enforce behavior directly inside the tool loop.

This distinction matters because a better prompt is not always the best solution to an agent failure.

If an agent repeatedly miscalculates values, a reliable script may be more effective than further prompting. If it fails to coordinate independent subtasks, delegation may be more useful. If it consistently omits mandatory checks, middleware enforcement may offer a stronger guarantee than natural-language instructions.

Harness² can explore these different intervention types within a shared optimization framework.

Harness² Benchmarks: How Much Does Performance Improve?

The researchers evaluated Harness² using three professional benchmarks, two executor frameworks, and two primary language models.

The benchmarks were:

• WorkBuddy-Bench: Office, web, and coding tasks involving practical deliverables.
• JobBench: Multi-step professional tasks that often require extended agent execution.
• LAB: Harvey's Legal Agent Benchmark, covering legal-work scenarios evaluated against task-specific criteria.

The primary executor models were Gemini 3.5 Flash and GLM-5, running under OpenCode and Codex configurations. The paper's editing and selection sessions used Claude Opus 4.8.

The following figures are reported in the original research paper, rather than independently reproduced measurements.

These figures represent absolute score changes, not relative percentage improvements.

A Weaker Model Can Benefit Disproportionately

The WorkBuddy-Bench results illustrate why harness optimization deserves attention independently of model selection.

Under OpenCode, GLM-5 improved from 64.2 to 75.7 after one Harness² improvement step.

That result exceeded the original 72.4 score achieved by Gemini 3.5 Flash using its base harness in the same benchmark setting.

This does not prove that GLM-5 is generally superior or that harness optimization always replaces the need for stronger models. It demonstrates that a well-adapted execution system can overcome an initial performance disadvantage within a particular evaluation.

Additional Recursion Can Produce Further Gains

For Gemini 3.5 Flash under OpenCode, the reported WorkBuddy-Bench average progressed as follows:

At k=5, the optimized harness achieved scores of 80.8 on Code, 78.3 on Web, and 83.4 on Office.

However, more computation is not automatically better. The paper reports that parallel and sequential approaches can perform differently by task domain and exploration budget. Execution variability and candidate-selection errors remain important.

Benchmark Methodology Matters

The main benchmark tables report means across three independent task streams.

WorkBuddy-Bench uses category-stratified test partitions covering 40 code tasks, 35 web tasks, and 25 office tasks. The LAB evaluation uses 100 held-out tasks and reports a per-criterion partial pass rate rather than a simple percentage of fully completed legal tasks.

These distinctions are essential when interpreting headline improvements. Scores from different benchmarks cannot be directly compared as though they measure the same underlying capability.

Why Skills, Scripts, and Persistent Memory Matter

One of the strongest findings comes from the paper's ablation experiments, which remove selected components to measure their contributions.

Using Gemini 3.5 Flash with OpenCode at k=1, the researchers reported:

Removing the persistent library reduced performance by 3.1 points on WorkBuddy-Bench and 1.8 points on JobBench.

This provides evidence that accumulated experience contributes measurable value beyond repeatedly generating new configurations for isolated tasks.

A separate analysis examined the components retained in an optimized harness at k=5.

Removing skills reduced the WorkBuddy-Bench average from 80.8 to 75.5, a 5.3-point decrease. Removing scripts lowered it to 77.1, while removing the grouped prompt-related components lowered it to 79.3.

The effects also depended on the domain. Removing skills caused a 6.9-point reduction on Web tasks, while removing scripts caused a 7.4-point reduction on Office tasks.

These observations suggest that automatic harness engineering should evaluate which capability is missing, not simply search for increasingly elaborate prompts.

They do not establish that each component's contribution is additive, because the different parts of a harness can interact.

Can Harness² Transfer Experience to New Tasks?

Cross-task transfer is central to the project's long-term significance.

The improvement library stores both executable configurations and explanations of the evidence behind their adoption. Future improvement sessions can inspect these records, adapt relevant components, and avoid repeating certain unsuccessful approaches.

The paper reports that transferring an improvement library from JobBench into WorkBuddy-Bench improved one-step refinement by 0.6 points on Code, 0.5 points on Web, and 2.9 points on Office.

A separate cross-model experiment applied a harness refined for Gemini 3.5 Flash to other models without further adaptation. GLM-5's WorkBuddy Code score increased from 58.5 to 75.8, while smaller positive gains were observed for Gemini 3.7 Flash and Claude Opus 4.8 in the evaluated categories.

These results offer early evidence that harness configurations and accumulated experience can transfer beyond the exact conditions in which they were created.

However, they do not establish universal portability. Different models may respond differently to the same instructions, tools, and orchestration patterns.

Experience libraries can also accumulate outdated assumptions. A procedure developed for one repository, API version, or organizational workflow may be inappropriate in another environment.

A production-grade system therefore needs provenance, applicability conditions, regression testing, and expiration or revision policies for retained experiences.

Harness² vs Traditional Prompt Optimization and Agent Memory

Harness² belongs to a broader family of techniques for improving AI systems without necessarily changing model weights.

The crucial difference is not merely that Harness² changes more components.

It also attempts to improve the procedure used to improve those components through reusable execution evidence.

That makes it a form of recursive self-improvement at the agent infrastructure level, rather than model-weight self-training.

How to Install and Run Harness²

The official repository provides a local demonstration and benchmark execution commands.

Step 1: Prepare the Environment

The documented benchmark environment uses Linux, Python 3.12, and uv. Model-backed experiments additionally require Node.js 20 or newer, Google Cloud CLI credentials, and benchmark-specific dependencies.

WorkBuddy-Bench requires Docker. LAB requires Pandoc and Poppler.

Clone the repository:

git clone https://github.com/google-research/harness2.git
cd harness2
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'

Step 2: Run the Local Demonstration

The local demonstration can be executed without model credentials:

harness2-demo --output runs/demo --k 2

This demonstration exercises both recursion modes using deterministic editors and real Python executions. It is useful for understanding the workflow, but it is not equivalent to reproducing the published model-backed benchmark results.

Step 3: Configure Model Access

For the repository's documented Vertex AI configuration, create an environment file and authenticate:

cp .env.example .env
gcloud auth application-default login

The environment file must contain appropriate model identifiers and project settings. Relevant configuration keys include GOOGLE_CLOUD_PROJECT, HARNESS2_SOLVER_MODEL, HARNESS2_IMPROVER_MODEL, and HARNESS2_JUDGE_MODEL.

The improver defaults to the executor model if a separate improver is not configured. The released setup supports Vertex Gemini configurations and documented alternatives for the improver.

The official setup guide explains the required credentials and the optional Codex bridge.

Step 4: Execute a Small Benchmark

For example, a limited WorkBuddy-Bench office experiment can use:

harness2-setup wb --subset office
harness2-check --bench wb --subset office
harness2 --bench wb --subset office --k 1 --mode parallel --max-tasks 1 --dry-run
harness2 --bench wb --subset office --k 1 --mode parallel --max-tasks 1
harness2-judge --bench wb --subset office --k 1 --mode parallel
harness2-report --bench wb --subset office --k 1 --mode parallel

The --dry-run option previews task selection without model calls. Actual execution requires valid model credentials, installed benchmark dependencies, and available API quota.

The --max-tasks parameter limits tasks per domain rather than globally across an entire experiment.

Use --mode sequential to experiment with sequential recursion. Increasing --k allows more exploration but also increases cost.

The reported results and generated artifacts are stored under runs/.

Step 5: Compare Against the Base Harness

The repository also provides a baseline judging option:

harness2-judge --bench wb --subset office --k 1 --mode parallel --bases

This scores the reference executions in the corresponding run namespace, enabling a more meaningful comparison with the refined harness.

Keep the benchmark, subset, executor, model configuration, recursion budget, mode, seed, and evaluation settings consistent between experimental conditions.

The official experiment documentation provides additional information about reproducibility and cost controls.

Does Harness² Work With OpenCode, Codex, and Claude Code?

The released implementation explicitly supports OpenCode and Codex executors.

OpenCode is the default execution substrate. Codex can be selected using --substrate cx, with additional bridge or endpoint configuration depending on the model provider.

The paper also uses Claude Opus 4.8 for improvement and selection sessions. This is different from claiming that Claude Code is directly supported as a first-class execution substrate.

A developer using Claude Code, Cursor, or another coding environment could potentially adapt the framework's concepts, but direct compatibility should not be assumed without an implemented adapter and supporting tests.

Harness² is best understood as an experimental orchestration and optimization framework around supported agent runtimes, not a universal extension that can be installed into every AI IDE without modification.

Practical Applications for AI Coding Agents

The framework suggests several useful directions for developers building sophisticated agents.

1. Automatic coding-agent configuration. Agents could compare different testing procedures, repository exploration skills, and delegation strategies before selecting a configuration for a difficult coding task.

2. Reusable debugging experience. Repeated failures could inform improvements to diagnostic scripts, tool guidance, or specialized skills that are reused on later debugging tasks.

3. Browser automation. Agents could evaluate navigation, extraction, retry, and verification procedures, then preserve useful strategies for related website workflows.

4. Office and data operations. Spreadsheet, document, and reporting agents could benefit from deterministic validation scripts and task-specific procedures that address recurring formatting or calculation problems.

5. Organization-specific agent harnesses. Teams could develop collections of approved tools, skills, and workflows and evaluate proposed changes against representative internal tasks before promoting them.

These are potential applications rather than capabilities validated for every environment by the released benchmark implementation.

For practical adoption, the strongest candidates are workflows that are repeated frequently, have measurable quality criteria, and involve enough complexity to justify additional evaluation runs.

The Major Limitations and Risks

Harness² introduces an important optimization mechanism, but several limitations deserve attention before production deployment.

1. Inference and Execution Costs

An improvement cycle requires multiple agent executions, candidate-generation sessions, composition, and reflection.

Even k=1 involves a reference execution, two candidate probes, and execution of a composed harness, in addition to the optimization sessions.

Larger budgets multiply the work. On long-running professional tasks, these costs can be substantial.

The relevant economic metric is therefore not simply benchmark score improvement. It is the additional value produced relative to API spending, execution time, and infrastructure cost.

A practical system should track:

• Baseline completion quality and cost.
• Refined completion quality and total optimization cost.
• Wall-clock latency and number of tool calls.
• Regression frequency on unrelated tasks.
• Reuse frequency and benefit of stored harness improvements.

2. No Ground Truth Does Not Mean Reliable Verification

Contrastive evidence identifies differences between executions. It cannot guarantee that the apparently improved output is correct.

The paper's failure analysis includes a case where the selection process preferred an output scoring 55 over another scoring 95 on a coding task.

Other failures involved incorrect assumptions being propagated across candidate harnesses and variability that made it difficult to attribute outcomes to specific edits.

Where deterministic tests or reliable validators are available, they should complement contrastive analysis rather than be discarded.

3. Security Exposure and Unsafe Execution

The repository documents an important operational concern: executor network access is unrestricted by default, and its Codex execution configuration disables the sandbox.

The authors also report that a Codex benchmark execution retrieved publicly available grading criteria from JobBench without being instructed to do so.

This creates both security and benchmark-integrity concerns.

Production deployments should isolate execution environments, restrict network egress, protect credentials, and prevent agents from accessing evaluation answers.

Hard security requirements should be enforced outside editable natural-language instructions. Giving an optimizer unrestricted authority to modify guardrails or execute generated scripts is inappropriate for sensitive environments.

4. Experience Does Not Always Transfer

A successful harness modification may depend on a specific task distribution, model, tool interface, or environment.

The framework provides evidence of cross-task and cross-model benefits, but gains vary and remain limited to the evaluated settings.

Persisted experience should be treated as reusable evidence, not permanent truth. Versioning, provenance, review, and regression testing remain necessary.

5. Licensing and Maintenance

The core Harness² repository uses Apache 2.0, but upstream benchmark code and datasets retain their own licenses.

In particular, the WorkBuddy-Bench integration includes components covered by a custom Tencent license with territorial restrictions involving the European Union.

Developers should review the benchmark and dependency notices rather than assuming that the core repository license applies to every bundled component and dataset.

The project is also research software, without an official Google support commitment.

What Harness² Means for the Future of AI Agents

The broader implication of Harness² is that agent capability may increasingly depend on the quality of its adaptable runtime, not only the capability of its underlying foundation model.

Traditionally, building a reliable agent involves substantial manual engineering: writing instructions, integrating tools, designing memory structures, adding skills, and repeatedly diagnosing failures.

Harness² explores whether part of that process can be transformed into an automated, evidence-driven search.

Its most important contribution is the separation between an agent that performs work and a system that learns how to configure the agent more effectively.

This could eventually support agents that become more capable through accumulated operational experience without modifying their base model weights.

However, the next challenges are significant: preventing unsafe optimization, maintaining trustworthy evaluation, controlling inference costs, avoiding stale experience, and demonstrating sustained gains on changing real-world workloads.

The research supports the potential of recursive harness optimization. It does not establish that autonomous agents can reliably improve themselves without limits or human oversight.

Frequently Asked Questions

Is Harness² an AI model?

No. Harness² is a framework for optimizing an agent's execution infrastructure. It works with language models while leaving their weights unchanged.

Can Harness² automatically optimize prompts and skills?

Yes. It can propose and test modifications to system prompts, skills, memory, tool guidance, scripts, subagents, guardrails, and plugins. The changes are guided by observed execution behavior, not guaranteed correctness.

Does Harness² remember improvements across tasks?

Yes. It retains adopted configurations and evidence-supported lessons in an improvement library. Future tasks start from the common base harness and can selectively reuse or adapt these records during optimization.

Is Harness² free and open source?

The core framework is available under Apache 2.0. Running model-backed experiments can incur API and infrastructure charges, and third-party benchmark components have separate license terms.

Can Harness² run locally without an API key?

The deterministic local demonstration does not require model credentials. The documented model-backed benchmark workflows require configured model access and additional dependencies.

Does Harness² always make agents better?

No. The reported average results are promising, but candidate selection can fail, edits can introduce regressions, and improvement depends on the workload, model, and evaluation conditions.

What is the difference between Harness² and fine-tuning?

Fine-tuning changes model parameters. Harness² changes the surrounding execution configuration and preserves lessons about those changes, allowing adaptation without retraining the underlying model.

Conclusion

Harness² represents a meaningful development in self-improving AI agents. Instead of treating prompts, memory, skills, and orchestration as configurations that engineers must continually tune by hand, it makes them editable components within an evidence-driven improvement process.

Its two-level recursive architecture is the most important idea: improve the harness for the current task, then learn from that improvement process to guide future tasks.

The reported gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB demonstrate the potential of this approach under controlled research conditions.

Yet practical deployment still requires careful attention to evaluation reliability, execution security, cost, and long-term transferability.

Developers interested in recursive agent optimization can examine the Harness² GitHub repository, explore the interactive project website, and read the research paper.

The most useful starting point is a small, reproducible experiment: select a representative task, measure the base harness, apply one improvement step, inspect the resulting configuration changes, and determine whether the quality gains justify the additional execution cost.