Harness²: How Google Is Rethinking AI Agents to Solve More Complex Problems

Nagesh Singh Chauhan

15 hours ago

18 min read

What if the secret to building better AI agents isn't a bigger model, but a better system around the model?

Introduction

Artificial intelligence is moving beyond chatbots that answer questions. Today's AI agents can search the internet, write code, analyze data, use tools, and execute multi-step tasks. But there is still a fundamental problem: an AI agent that performs well on one task may fail when the task changes, the environment becomes unfamiliar, or the problem requires several rounds of reasoning and tool use.

One promising direction is to improve not just the AI model, but also the system that guides it, evaluates its work, and learns from previous attempts.

This is where Harness² (Harness Squared) comes into the picture.

The central idea is fascinating:

Instead of relying exclusively on a more powerful model, can we make the system surrounding a model progressively better at solving different problems?

To understand why this matters, we first need to understand what an AI harness is, why conventional AI agents struggle, and how recursive harness improvement changes the way we build intelligent systems.

What Is an AI Harness?

Imagine you hire an exceptionally intelligent employee. This employee can write reports, analyze spreadsheets, research competitors, and write code. However, you give them no clear instructions, no access to the right tools, no standard operating procedures, and no way to learn from previous projects. Will they perform well?

Probably not.

Now imagine you provide the same employee with clear instructions, access to the required software, a checklist for completing tasks, examples of successful work, and a process for reviewing results. Their performance could improve significantly, even though their intelligence has not changed.

An AI harness works in a similar way.

A large language model (LLM) provides the underlying intelligence. The harness provides the instructions, tools, workflow, memory, and operational structure that enable the model to function as an AI agent. A typical harness can include a system prompt that defines the agent's role, tools that allow it to interact with external systems, memory that provides relevant context, and orchestration logic that determines which steps to execute and when.

For example, consider an AI data analyst.

A basic LLM can explain SQL queries and suggest analytical approaches. But an AI data analyst needs much more to do actual work. It needs access to a database, permission to execute SQL, an understanding of the data schema, a way to interpret the results, and a mechanism to generate a report. The model supplies the reasoning capability. The harness makes that capability useful in a real environment.

The Harness² research paper builds on this distinction: an agent's performance depends not only on the underlying model but also on the system surrounding it.

What does an AI harness contain?

Harness² exposes eight editable components that control how an agent operates.

Component	What it does	Example
System prompt	Defines the agent's role and instructions	"You are an expert financial analyst."
Guardrails	Establishes rules and restrictions	Never execute an unapproved financial transaction.
Memory	Stores relevant information and previous experience	Remember the company's financial reporting conventions.
Tool guidance	Explains how and when to use tools	Use SQL for database analysis.
Skills	Provides reusable procedures for particular tasks	Follow the standard monthly reporting process.
Scripts	Automates repeatable operations	Run a script to validate data quality.
Subagents	Delegates work to specialized agents	Ask another agent to investigate anomalies.
Plugins	Extends or modifies the agent's runtime behavior	Add middleware for logging or request handling.

These components are described in the official Harness² repository.

The important observation is that an agent's behavior can change substantially when these components change, even if the underlying language model remains exactly the same. That leads to the next question.

Why Do We Need Harness² ?

Most AI agents are built using a carefully designed combination of prompts, tools, memory, and workflows. Developers test the system, identify weaknesses, and improve it. Once it performs well enough, they deploy it. This approach works, but it has a limitation: the harness is usually designed before the agent encounters the full variety of real-world tasks.

Consider an AI agent designed to analyze business data. During development, it is tested on questions such as:

What was our revenue last month?
Which products generated the most sales?
Why did revenue decline in a particular region?

The agent performs well on these questions. After deployment, a business user asks a more complicated question:

"Identify the regions where revenue has declined despite increasing marketing expenditure. Investigate the possible reasons, compare the results with the previous quarter, and prepare a report with recommendations."

The agent might struggle because the task requires multiple analytical steps, careful context management, several database queries, and a structured final deliverable. A developer could manually improve the system prompt, add a specialized skill, or modify the workflow. But this creates a recurring engineering problem: every new failure potentially requires another round of manual investigation and development.

There is another difficulty.

A system that performs well on one task may not perform well on another. A prompt optimized for financial analysis might be inappropriate for legal research. A workflow that works for a short report may fail when an agent needs to inspect several documents and use external tools.

Harness² addresses this problem by exploring how the harness itself can improve as the agent encounters new tasks.

Instead of assuming that developers can anticipate every situation, the framework attempts to refine the execution harness for the current task and retain useful lessons for future tasks.

The researchers call this Recursive agent harnessing.

The Core Idea: Improve the Agent Without Retraining the Model

To understand what makes Harness² interesting, we need to distinguish between two types of improvement.

The first is model improvement. This involves changing the underlying model through techniques such as fine-tuning or other training procedures.

The second is harness improvement. This involves changing the instructions, tools, memory, skills, or execution logic surrounding the model.

Harness² focuses on the second approach.

Imagine that you have a language model called Model A. It has fixed weights, meaning its learned parameters do not change during the Harness² refinement process. Initially, Model A operates with Harness A, which contains its system prompt, available tools, memory configuration, and other components. The agent receives a task and produces a result. The system then explores alternative harness configurations, runs them on the same task, and compares how their behavior changes.

If the experiments provide evidence that a modification addresses a weakness, the system can incorporate that change into a refined harness. The resulting agent still uses Model A, but it now operates with a potentially better configuration.

In simplified form:

Initial agent = Fixed model + Initial harness

Improved agent = Same fixed model + Refined harness

The distinction is important because retraining a large model can be expensive and operationally complicated. Improving the harness provides another route to better task performance without changing the model weights.

However, this does not mean that harness improvement is free. It can require additional model calls, tool executions, computing resources, and evaluation time. Nor does it mean that a better harness will automatically improve every task. The research question is whether systematic harness refinement can produce reliable improvements across unfamiliar tasks.

Harness² proposes a mechanism to explore that question.

How Harness² Works: Two Levels of Recursion

The most important part of Harness² is its use of two connected improvement processes. The first improves the harness for the task currently being performed. The second improves the process that creates better harnesses, using lessons from previous tasks.

These two processes work together.

Level 1: Task-level recursion

Suppose an AI agent is asked to prepare a market research report. Its initial harness may not provide sufficiently good instructions for gathering evidence, comparing sources, or organizing the final report.

Harness² attempts to identify opportunities for improvement by following three steps: Propose, Probe, and Compose.

Step 1: Propose — Generate possible improvements

The system first runs the agent using its current harness to establish a reference execution.

It then proposes alternative harness configurations.

For example, it might consider two changes:

A general improvement: Instruct the agent to plan complex tasks before executing them.
Specific to the current task: Instruct the research agent to distinguish verified facts from assumptions and record the source of important claims.

These represent two different kinds of improvement.

General improvements address weaknesses that might appear across many tasks. Task-specific improvements address the requirements of the current problem. Importantly, a proposed change is a hypothesis, not a proven improvement.

A more detailed prompt may help the agent. It may also distract the agent, increase unnecessary steps, or make the workflow less efficient.

The next step is designed to investigate what actually happens.

Step 2: Probe — Test the proposed improvements

The system executes the candidate harnesses on the same task and compares their behavior with the reference execution. Suppose the original agent produces a market research report with unsupported claims. One candidate harness adds instructions for source verification. Another adds a detailed planning procedure.

The system can compare the resulting execution traces and deliverables.

Does the source-verification instruction cause the agent to gather more evidence? Does the planning procedure change how it uses tools? Does either modification introduce new problems?

These comparisons provide evidence about the effects of the changes.

Here is a crucial detail: Harness² does not require a ground-truth answer to perform this comparison.

For many real-world tasks, there is no simple answer key.

A market research report cannot always be evaluated by checking whether its final answer matches one predetermined string. A legal analysis, business strategy, or financial investigation may require several forms of judgment.

Harness² instead compares how the different harnesses behave under matched execution conditions.

This is useful, but it is not the same as proving that the final answer is correct. Two executions can differ while both are wrong, and they can share the same underlying model bias.

Step 3: Compose — Build a better harness

After examining the results, the system decides which changes to incorporate into a successor harness. It may adopt a successful change, combine compatible improvements, revise conflicting changes, or retain the original configuration if the evidence does not justify a modification.

For example, suppose the experiments suggest that source-verification instructions improve the report, while the additional planning procedure does not produce a useful behavioral change. The system may retain the source-verification instructions without adopting the unnecessary complexity.

It then executes the refined harness to produce the task's deliverable. The objective is not to make the harness more complicated. It is to make it more effective based on evidence from actual executions.

The complete cycle is:

Propose → Probe → Compose → Execute

The process can be repeated, allowing successive refinements to build on previous results.

Level 2: Harnessing-level recursion

Task-level improvement solves only half the problem. Imagine that the agent has successfully learned how to improve its research workflow. Tomorrow, it receives a financial analysis task. The day after that, it must prepare a legal report.

Should the system start its improvement process from scratch every time?

Harness² introduces a second level of recursion to reduce that need.

After completing a task, the system updates a persistent improvement library with adopted harness configurations and evidence-supported lessons from the refinement process. This library can inform future proposals and decisions.

For example, it might retain lessons such as:

Breaking a complex task into explicit stages helped the agent complete its work.
Adding a particular tool-use instruction changed the agent's execution in a useful way.
A specific type of prompt modification repeatedly introduced unnecessary steps.
A successful procedure may be reusable in similar tasks, provided its assumptions still hold.

When another task arrives, the improvement process can draw on relevant previous experience instead of starting entirely from scratch.

There is an important distinction here. The system does not simply copy the previous task's complete execution harness into the next task. A configuration designed for one task may be unsuitable for another. Instead, Harness² aims to retain reusable components and lessons about how and why particular changes worked.

This makes the second recursion especially interesting: the system learns not only how to perform tasks better, but also how to improve the mechanism that helps it perform those tasks.

Understanding Harness² Through a Real-World Example

Let's consider a problem that many businesses face: automating financial analysis.

Imagine a company has deployed an AI financial analyst with access to a database containing revenue, expenses, invoices, and payments. The agent can query the database, calculate metrics, and generate reports.

However, the initial harness is relatively basic. A finance manager asks:

"Analyze our accounts receivable, identify customers whose overdue payments have increased, investigate the reasons, and recommend actions to improve collections."

The task requires the agent to retrieve relevant data, calculate overdue balances, compare trends, identify unusual patterns, and prepare recommendations. Let's see how a Harness²-style improvement process might work.

Initial execution: The agent retrieves overdue invoices and calculates the total outstanding balance. However, it fails to distinguish between recently overdue invoices and long-standing payment problems. Its report provides limited insight.
Propose: The improvement process considers adding instructions to analyze invoice aging, compare customer payment patterns over time, and investigate unusual changes.
Probe: It tests alternative harnesses on the same task. One configuration produces a more detailed aging analysis. Another identifies historical payment patterns. The system compares the resulting executions to understand the effects of each change.
Compose: The system incorporates changes supported by the observed behavior. It then runs the refined agent to produce a new deliverable.
Learn for future tasks: The improvement library retains useful lessons about financial analysis workflows. When a later task involves overdue payments, the system can use these lessons to propose a more appropriate initial harness.

This example illustrates the concept rather than reproducing an experiment from the paper. The actual effectiveness of the proposed financial workflow would need to be evaluated using appropriate financial data, correctness checks, and business outcomes. The distinction matters because an agent can produce a more detailed report without necessarily producing a more accurate one.

For financial applications, a production implementation should validate calculations, enforce data-access permissions, and require appropriate approval before taking consequential actions.

Parallel vs. Sequential Recursion

Harness² supports two approaches to task-level refinement. Both use the Propose–Probe–Compose process, but they explore improvements differently.

Parallel recursion: Explore multiple possibilities

Imagine that you want to improve an agent that writes software. You suspect that the agent could benefit from better planning, more effective tool use, and clearer testing instructions.

Parallel recursion allows the system to explore multiple candidate harnesses and their effects, then compose refinements using the collected evidence.

This is useful when you want to investigate several potential improvements without requiring each experiment to depend on the previous one. Think of it as asking several engineers to investigate different solutions to the same problem and then combining the useful findings.

Sequential recursion: Refine one step at a time

Sequential recursion follows a different strategy. The system performs an improvement step, executes the resulting harness, and carries the refined harness and accumulated evidence into the next step. The next iteration therefore starts from the previous iteration's results.

For example, the first iteration may improve planning. The second may refine tool use based on the updated workflow. A later iteration may address an execution weakness that remains.

This approach allows successive refinements to build on one another. The trade-off is straightforward: parallel recursion explores alternatives more broadly, while sequential recursion develops a chain of successive revisions.

Neither strategy is universally better. Their relative performance depends on the task, available computation, quality of the proposed changes, and the amount of exploration allowed. The paper evaluates both approaches and reports additional gains from increasing the task-level recursion budget. GitHub

What Results Did the Researchers Report?

The researchers evaluated Harness² on three professional benchmarks across four model–harness configurations.

The benchmarks cover different kinds of work:

WorkBuddy-Bench: Office work, web-based tasks, and coding.
JobBench: Professional work tasks.
LAB: Harvey's Legal Agent Benchmark, which evaluates legal work.

The reported experiments used GLM-5 and Gemini 3.5 Flash in different executor–harness configurations. According to the paper and the official repository, a single Harness² improvement step produced the following maximum gains over the corresponding base harnesses:

Benchmark	Reported maximum improvement
WorkBuddy-Bench	11.5 points
JobBench	4.5 points
LAB	11.8 percentage points in partial pass rate

The researchers also report additional improvements from parallel recursion and further gains as the task-level recursion budget increases. These results are promising, but they require careful interpretation.

First, the numbers are maximum reported gains, not guarantees that every task or configuration will improve by those amounts.

Second, the metrics differ across benchmarks. The LAB result is specifically expressed in percentage points for partial pass rate, while the other gains are reported as benchmark score points. They should not be treated as directly comparable measurements.

Third, the results do not establish that harness refinement will outperform model fine-tuning or other agent architectures in every setting.

The more important takeaway is that the experiments provide evidence that changing the agent's surrounding system can improve task performance without changing the underlying model weights.

That is a meaningful result because it suggests that model selection is only one part of building effective AI agents. How a model is instructed, equipped, and orchestrated can also make a measurable difference.

How Is Harness² Different From Traditional AI Agents?

Traditional agent development typically relies on engineers designing prompts, connecting tools, defining workflows, and evaluating the system against representative tasks. When the agent fails, developers investigate the failure and modify the system.

Harness² attempts to automate part of that improvement process.

The following table summarizes the distinction.

Dimension	Traditional agent development	Harness² approach
Initial design	Developers configure prompts, tools, and workflows	Starts with an execution harness that can be refined
Improvement	Often relies on manual debugging and iteration	Uses automated propose–probe–compose cycles
Evaluation	Often uses predefined tests or task-specific feedback	Also compares execution behavior when ground-truth answers are unavailable
Learning across tasks	Depends on the memory and improvement mechanisms developers implement	Maintains a library of adopted harnesses and evidence-supported lessons
Model weights	May remain fixed or be updated through training	Remain fixed during harness refinement
Main objective	Build an agent that performs its assigned tasks well	Improve task execution and the process of improving future harnesses

The comparison is about the approaches' typical design goals, not a claim that all conventional agents lack memory, automated evaluation, or self-improvement.

Many existing agent frameworks already support iterative execution, tool use, and reflection. Harness²'s distinctive contribution is its combination of task-level harness refinement with a persistent mechanism for improving future harness refinement.

Is Harness² the Same as Self-Improving AI?

Not exactly. The distinction is important.

Self-improving AI is a broad idea that describes systems that use their own experience, evaluations, or outputs to improve their future capabilities or behavior. Harness² explores one specific form of this idea: recursive improvement of the software and configuration surrounding a fixed language model.

The model does not rewrite its own learned parameters during the process described in the paper. Instead, the system modifies the harness that controls how the model performs tasks and improves the process used to make those modifications.

This is different from an AI system that retrains its underlying model, changes its neural network architecture, or automatically develops a fundamentally new learning algorithm.

It is also different from a simple reflection loop.

A conventional reflection loop might ask an agent to review its answer and try again. Harness² goes further by making the harness itself an object of experimentation and by retaining lessons from the improvement process for future tasks.

That said, the framework does not eliminate the need for reliable evaluation. It uses behavioral comparisons to guide refinement when ground-truth feedback is unavailable, but these comparisons cannot guarantee that the resulting work is factually correct or safe.

Harness² is therefore best understood as a framework for recursive agent-system improvement, rather than proof that an AI has achieved unrestricted or autonomous self-improvement.

What Are the Limitations of Harness² ?

The approach is promising, but several challenges remain.

1. Better behavior does not necessarily mean a correct answer

This is perhaps the most important limitation. Suppose an agent generates a financial report. A refined harness causes it to run more queries, produce additional charts, and explain its reasoning more clearly. The report may look more professional, but it could still contain incorrect calculations.

Harness² compares execution behavior to guide changes. Those comparisons do not independently establish that the final deliverable is correct. For high-stakes tasks, external verification remains important.

2. More refinement can mean higher costs

Every additional experiment can require more model calls, tool executions, and computing resources. Parallel recursion may be particularly expensive because it explores multiple candidate harnesses. Sequential recursion can also accumulate costs as it performs successive refinement steps.

Consequently, the best harness is not necessarily the one that performs the most experiments. In production, the goal should be to improve the quality of the result enough to justify the additional cost and latency.

3. Task-specific improvements may not generalize

An improvement that works for legal research may be inappropriate for software development. Likewise, a change that helps with one financial analysis may not work for a different company or data structure.

The persistent improvement library is designed to retain reusable lessons rather than blindly transfer entire harnesses. Even so, the usefulness of a lesson depends on whether its assumptions remain valid in the new context.

4. Repeated experimentation can introduce regressions

A change may solve one problem while creating another.

For example, adding strict instructions to verify every claim may improve factual discipline but cause the agent to spend too much time gathering evidence for a simple question.

Similarly, adding more subagents may improve coverage while introducing coordination overhead and inconsistent findings.

A robust implementation needs safeguards that allow it to reject harmful modifications and preserve a working baseline.

5. Security becomes more important when agents can modify their own harnesses

An agent that can modify scripts, prompts, plugins, or tool configurations introduces a different set of risks from an agent that can only generate text.

A poorly controlled modification could weaken guardrails, introduce unsafe tool behavior, or expose sensitive information. A production system should therefore use permission boundaries, isolated execution environments, change logging, version control, and explicit approval for sensitive modifications.

These are important engineering requirements for deploying self-modifying agent systems safely.

6. The research is promising, but broader validation is needed

The reported results cover three professional benchmarks and four model–harness configurations. They do not establish how well Harness² will perform across every industry, model family, task type, or production environment.

It remains important to evaluate the framework on new tasks, measure its computational costs, and determine whether improvements persist over longer periods. The key lesson is not that harness refinement solves every agent problem. It is that automated improvement of the agent's surrounding system is a promising direction that deserves further investigation.

How Could Businesses Use Harness²?

The practical opportunity is to move from AI agents that follow fixed workflows toward agents whose operating procedures can be refined through controlled experimentation.

Consider a few examples.

AI data analyst: An agent that investigates business questions could refine its approach to query planning, data validation, anomaly detection, and report generation. Lessons from previous analyses could help it approach similar tasks more effectively.

AI software engineer: A coding agent could experiment with changes to its planning instructions, testing procedures, debugging workflow, and tool-use guidance. Useful improvements could be retained for subsequent development tasks.

AI financial analyst: A finance agent could refine procedures for reconciling transactions, identifying anomalies, analyzing overdue invoices, and preparing financial summaries. Numerical validation and access controls would still be necessary.

AI tender and bid management agent: An agent that prepares tender responses could refine its approach to requirement extraction, compliance checks, document analysis, and response generation. A persistent improvement library could retain reusable lessons about common document structures and recurring procedural weaknesses.

AI customer support agent: An agent could refine how it retrieves knowledge, escalates difficult cases, and follows approved resolution procedures. Any changes would need to remain within company policies and customer data protections.

In all these cases, the important distinction is between learning a new task-specific procedure and learning a reusable method for improving procedures.

Harness² explores both.

For a business, this could eventually reduce some of the manual effort required to maintain large collections of AI agents. However, the actual savings would depend on the frequency of recurring tasks, the cost of refinement, and whether the resulting improvements are reliable enough for production use.

Can You Try Harness² Yourself?

Yes. The researchers have published an implementation in Github.

The repository provides installation instructions, a demonstration, benchmark integrations, and support for parallel and sequential recursion. It specifies Python 3.12 and Linux for its documented setup. Model-backed benchmark runs may incur API costs.

A sensible starting point is to understand the framework before attempting a full benchmark run. Begin with the repository's demonstration to explore the basic refinement workflow. Then choose a small benchmark task and examine the baseline execution, proposed changes, probe results, and final harness.

Pay particular attention to the evidence supporting each modification. This is where the underlying research idea becomes clearer: the objective is not simply to ask an AI agent to improve its answer, but to investigate how changes to the agent's operating system affect its behavior.

The repository is released under the Apache 2.0 license. However, its README explicitly states that Harness² is not an officially supported Google product. It is more precise to describe it as an open-source research framework in the Google Research repository than as an officially supported Google product.

For a production experiment, start with a low-risk task, establish a baseline, measure task quality and execution cost, and retain a reliable rollback path before allowing the system to adopt changes automatically.

What Does Harness² Mean for the Future of AI Agents?

For the past few years, much of the discussion around improving AI has focused on building larger models, increasing context windows, improving reasoning, and training models on more data. These advances remain important.

However, building a capable AI agent requires more than selecting a powerful model. The agent must also know how to use tools, organize work, manage context, follow constraints, and recover from mistakes.

Harness² highlights a different opportunity: improve the system around the model, and improve the process that makes that system better.

Imagine a future in which a company deploys hundreds of specialized AI agents. Rather than requiring engineers to manually refine every workflow after every failure, a controlled improvement framework could test changes, identify useful patterns, and share appropriate lessons across related tasks.

Such a system would not need to change its underlying model weights to become more effective at its assigned work. It would still need reliable evaluation, careful security controls, and mechanisms to prevent regressions. But it could offer a practical path toward maintaining and improving agents in environments where tasks continually change.

The most interesting part of Harness² is therefore not simply that an AI agent can modify its own prompts or tools.

It is the idea that the process of improving an AI agent can itself become something the AI system learns to do better.

That shift could influence how we design, deploy, and maintain AI systems across software engineering, analytics, finance, research, and business operations.

Whether this approach becomes a standard part of agent engineering will depend on how well it performs across broader tasks and real-world deployments. The initial research offers an encouraging direction, but the larger opportunity lies in making these systems reliable, cost-effective, and safe.

Final takeaway

Harness² introduces a useful way to think about AI development:

The model provides the intelligence.
The harness determines how that intelligence is used.
Task-level recursion improves the harness for the current task.
Harnessing-level recursion learns from those improvements to guide future tasks.

The underlying model remains fixed during this process, while the surrounding system evolves through controlled experimentation. This does not eliminate the need for better models or reliable evaluation. Instead, it expands the ways we can improve AI agents.

The next major step in AI may not come exclusively from making models larger. It may also come from building systems that learn how to use existing models more effectively.

Perhaps the future belongs not only to better AI models, but also to AI systems that continuously learn how to work better with the models they already have.