Google Harness²: Self-Improving Agents, Explained

Harness² is a research release from Google that automates something engineers have been doing by hand: tuning the instructions, tools, memory and helper agents around a model until it performs well on a particular kind of work. Instead of a human rewriting the system prompt after each failure, Harness² lets the agent propose edits, test them against each other, and keep the ones that demonstrably help.

The key claims, as reported by Techstrong.ai and the Product Hunt page, are these.

• It leaves the model alone. Only the harness changes. Model weights are fixed, so there is no retraining and no fine-tuning bill.
• It needs no answer key. It works on open-ended tasks without labels, test cases or verifiers, learning from contrasts between runs.
• It exposes eight editable components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins.
• It reports consistent gains. One refinement step improved all four tested setups on all three benchmarks, with the largest being 11.5 points on WorkBuddy-Bench.
• It is open source. Apache 2.0, on GitHub, version 0.1.0, labelled an unofficial Google product and a research release rather than a product.

The caveats matter as much as the claims. The numbers are from the authors, not from independent replication. Each refinement step adds runs and cost. And the default configuration gives executors unrestricted network access, with Codex running without its sandbox, which is a security decision the user must take. As one analyst put it, a harness edit carries the same production risk as a model upgrade if these results hold.

For readers following our coverage of agent tooling, Harness² sits next to the open-source harness projects we have reviewed, such as DeepSeek Harness and its v0.2 desktop app, and the research-automation work in Weco AIDE².

A model on its own is a function from text to text. An agent is a model plus everything around it: the system prompt that sets its role, the tools it can call, the memory it can consult, the guardrails that constrain it, the subagents it can delegate to, and the scripts and plugins that extend it. That surrounding structure is the harness.

Practitioners learned some time ago that the harness often matters as much as the model. The same model can look brilliant or useless depending on how its prompt is written, which tools it is given and how its context is managed. This is why coding agents such as Codex and OpenCode, which Google used as executors in its experiments, are distinct products even when they call similar underlying models. It is also why we see so much open-source activity around harnesses, from DeepSeek's harness to the agent operating environments covered in Hermes Agent Explained.

The trouble is that harness engineering is manual, task-specific and fragile. A prompt tuned for legal drafting does not transfer to spreadsheet work. A memory scheme that suits a coding agent may clutter a research agent. Teams spend weeks iterating, and the knowledge lives in someone's head or a scrappy prompt file. Harness² proposes to automate that loop, and the 'squared' in the name refers to improving the thing that improves the agent: harnessing the agent, then harnessing its self-improvement, in the words of the Product Hunt tagline.

The framework is built around two recursions, which the Product Hunt page describes as dual recursion and Techstrong.ai describes in more detail.

The task-level loop: Propose, Probe, Compose. The agent first runs a task using its base harness. An editor model then proposes two candidate edits: one aimed at general agent failures and one aimed at domain knowledge. Both candidates are run on the same task, which gives a controlled comparison. A composer then keeps only the edits supported by observed behaviour and discards the rest. This is the part that does not need ground truth: the signal is the contrast between runs, not a score from an external grader.

The accumulation loop. After each task, a reflector saves the adopted harness together with a lessons-learned file. These artefacts shape future proposals, but, importantly, each new task still starts from the base harness. That design choice limits how far accumulated edits can drift, and it makes the saved files an inspectable record of what changed and why.

Budget modes. Parallel mode explores several candidate harnesses at once; sequential mode chains refinement steps. That is a standard trade of cost against wall-clock time.

The illustration at the top of this page, produced by Techstrong.ai, shows the folder structure of the eight editable components alongside a Run, Propose, Probe, Compose, Improve cycle. It is a useful visual summary, but it is an illustration rather than a screenshot or a chart.

What makes this different from simply asking a model to rewrite its own prompt is the controlled comparison. Without testing the two candidates on the same task, self-edits are just opinions. With it, the agent has evidence.

Google evaluated Harness² on three benchmarks, using two executor models under two agent harnesses, with Claude Opus 4.8 as the default editor model, according to Techstrong.ai.

Two secondary findings are worth noting. After one step, GLM-5 outscored the base Gemini 3.5 Flash setup on WorkBuddy-Bench, which suggests harness quality can outweigh a model-tier difference on some tasks. And three of the four setups completed tasks in fewer steps on that benchmark, so the gains were not bought purely with extra effort at run time.

On the 11.5 versus 11.8 figures. Different sources quote different maxima. The Product Hunt page cites up to 11.5 points on professional benchmarks including WorkBuddy-Bench, while Techstrong.ai reports 11.5 points for the WorkBuddy-Bench maximum and gains of up to 11.8 percentage points on the LAB legal benchmark. These are different metrics, and we quote each with its attribution.

How much weight to give them. The results are first-party. The paper also compares Harness² with other harness-optimisation methods, including Stanford's Meta-Harness, and Techstrong.ai notes that the Harness² team ran those comparisons, not the original authors. That does not make the numbers wrong, but it is the standard reason to wait for independent replication.

Most enterprises cannot change a frontier model. They can change what surrounds it. Mitch Ashley of The Futurum Group, quoted by Techstrong.ai, called the harness the part most enterprises control. If a framework can reliably improve that layer, it shifts where the leverage sits.

Cheaper than fine-tuning. Fine-tuning needs data, compute and often access that vendors do not give. Harness edits are text and configuration. If the reported gains hold, they are a cheaper route to task-specific performance, though each refinement step carries its own API cost, and Google's README recommends starting with a small task set.

Model-agnostic in principle. The tests used two different executor models and two different agent harnesses. The Product Hunt discussion raised open questions on whether other vendors' models will be supported and whether accumulated experience transfers between unrelated tasks. The reported setup uses Vertex AI for model-backed runs, so portability should not be assumed.

A step on the self-improvement spectrum. This is a mild form of the dynamic that worries some researchers: a system that improves its own operating conditions. Harness² does not change weights and each task starts from a base harness, so it sits well short of the autonomous loops discussed in our piece on OpenAI's 'An Alien Mind'. It is nevertheless part of the same trajectory, and an arXiv paper cited in coverage on auditing harness tampering warns that apparent gains in self-improving agents can reflect overfitting or evaluation artefacts. That is a general concern in the field, not a finding about Harness².

A framework that edits its own guardrails deserves more scrutiny than one that edits its own greeting. The coverage raises several concrete points.

• Unrestricted network access by default. Techstrong.ai reports that executor network access is unrestricted by default and that Codex runs with its sandbox disabled. Teams must apply their own network restrictions.
• Guardrails are editable. The guardrails component is one of the eight editable files. A system that can loosen its own constraints in pursuit of a better score needs a review gate. This is precisely the scenario in which approval workflows matter.
• Change review. Ashley's point is that if the results survive replication, a harness edit is as consequential as a model upgrade and needs equivalent change control. The saved files become an audit trail only if a named owner reviews them, and he advises watching whether approval gates for harness edits arrive before production use.
• Cost. Automated refinement multiplies runs, and therefore API spend. Without budgets, an optimisation loop can quietly become a large invoice.

For context on how real agent systems fail when constraints slip, see our coverage of OpenAI's long-horizon sandbox escapes and Anthropic's multiagent safety research. Neither concerns Harness², but both illustrate why guardrail integrity is not a side issue.

The reported requirements are modest but specific. You need Linux, Python 3.12 and the uv package manager. Model-backed runs go through Vertex AI, which means a Google Cloud setup and billing. A local demo runs without model credentials, which is the sensible first step for anyone just evaluating the idea.

The README's advice is to start with a small set of tasks. That is good advice for two reasons: cost, as above, and interpretability. With a small set you can read the saved harness and lessons-learned files and judge whether the edits make sense, which is the best defence against overfitting to quirks of a benchmark.

A sensible evaluation plan for a team would be: pick one repeatable task type; record a baseline score with your current harness; run a single refinement step in a sandbox with network restrictions; read every edit the system adopted; and only then decide whether to run more steps. Treat the adopted harness like a pull request, not like a configuration value.

For teams already using an open-source agent harness, the comparison with DeepSeek Harness is instructive: those projects give you a harness to start with; Harness² aims to give you a way to evolve one.

Harness² is not the only attempt to automate harness design, and it would be a mistake to read it as a lone breakthrough. A search of the literature turns up a cluster of recent arXiv papers on the same theme, including work titled HarnessX (a composable, adaptive and evolvable agent harness foundry), Recursive Harness Self-Improvement, Hierarchical Self-Improvement for task-specific evolvable harnesses, HarnessBank (semantic gene-bank search with gated verification for harness self-evolution), Self-Harness (harnesses that improve themselves) and a paper on auditing harness tampering in self-improving agents. We have not reviewed those papers in depth and cite them only to show the breadth of activity, not to compare results.

The shared premise is that the harness is a search space. The differences lie in how candidates are generated, how they are evaluated and how successful ones are stored. Harness² makes three choices that stand out from the reporting. It evaluates by contrasting two proposals on the same task rather than by scoring against a verifier, which is what lets it work on open-ended tasks. It keeps each new task starting from the base harness rather than compounding edits indefinitely, which limits drift. And it stores adopted harnesses and lessons in plain files, which makes the process inspectable.

The comparison with Stanford's Meta-Harness, which Techstrong.ai says the Harness² team ran itself, is the one to watch. Independent head-to-head benchmarks of these methods on shared tasks would tell the community far more than any single paper's tables. Until those exist, a sensible expectation is that harness optimisation works, the size of the gain depends heavily on task and baseline, and the most durable contribution may be the engineering pattern rather than any particular score.

It is worth sketching how a team might use the idea, clearly as our own speculation rather than anything in Google's release.

A legal operations team running a document-review agent could use a small set of past matters to let the system propose domain-knowledge edits, such as how to treat particular clause types, while a lawyer reviews every adopted edit. The reported gains on the Harvey LAB legal benchmark suggest that is where the method has shown the clearest improvement, though the benchmark is not the same as a firm's real work.

An engineering team using Codex or OpenCode could apply the same loop to repository conventions: test commands, linting rules and architectural notes that the agent repeatedly gets wrong. This is close to what developers already do manually in project instruction files, so the automation is incremental rather than radical.

A platform team could run the loop offline against a fixed evaluation set and promote adopted harnesses through the same review process used for code. That would turn harness changes into reviewable artefacts, which is exactly what the governance commentary argues for.

In each case the value comes from the combination of automation and review. Automation finds candidates cheaply; humans decide which to keep. That division of labour is also the safest, and it is the one the saved lessons-learned files are designed to support.

No independent replication. All reported results come from the authors. Until others reproduce them on different tasks and models, treat the gains as promising rather than proven.

Benchmark choice. The three benchmarks cover office, professional and legal work. They do not obviously represent every kind of agent task, and the Product Hunt thread asked whether accumulated experience transfers between unrelated tasks, which remains open.

Dependence on the editor model. The default editor is Claude Opus 4.8, so a strong external model proposes the edits. How much of the gain depends on editor quality, and what happens with a weaker editor, are questions the coverage does not answer.

Avoiding regressions. Commenters asked how the system avoids changes that make performance worse, and whether human input is needed to judge improvement. The composer's rule of keeping only edits backed by observed behaviour is the stated answer, but the failure rate of that rule is not reported in the sources we reviewed.

Research release. Version 0.1.0, labelled unofficial. Expect rough edges, API changes and little support.

Agent engineers and platform teams should read the repository and the paper, because the Propose-Probe-Compose pattern is worth borrowing even if you never run the code. A controlled comparison of two candidate edits on the same task is a simple idea with wide applicability.

Enterprise AI leads should note the governance angle. Whether or not you adopt Harness², you will need a policy for who can change an agent's harness in production, how changes are reviewed and how they are rolled back.

Everyone else can treat it as a signal. The frontier is moving from which model to which model plus harness, and from hand-tuned to automatically evolved scaffolding. Our wider coverage of agent tooling, including Hermes Agent, tracks how fast that is happening.

Harness² takes a reasonable idea, let the agent improve the scaffolding around itself using comparisons between its own runs, and releases it as open source with encouraging first-party numbers. The reported gains are large enough to be worth attention, up to 11.5 points on WorkBuddy-Bench and up to 11.8 percentage points on the legal LAB benchmark, and the finding that a smaller model with an improved harness can overtake a larger setup is the most interesting claim.

The right posture is interested scepticism. The results are first-party, the default security posture is permissive, and the governance questions are real. Try the local demo, read the adopted edits and wait for independent replication before betting a production workflow on it.

We will update this article when independent tests appear.