Google Research Harness²: what can developers learn from it?
Learn how Harness² refines AI agent environments, what its benchmarks show, and which ideas developers can test safely.
Harness² tests changes to an agent’s environment during a task and retains lessons for later tasks. Any benefit needs confirmation on real work, including cost and safety.
When a coding agent fails, switching models can look like the obvious fix. Yet its outcome also depends on the instructions it receives, the tools it can call, its memory, its validation scripts, and how those pieces are organized during a task.
That surrounding system, the agent harness, is what drew my attention to Harness². The code is published in the google-research repository under Apache 2.0, alongside the preprint Harness²: Recursive Agent Harnessing for an Open World, submitted on October 9, 2026. The README says explicitly that this is not an officially supported Google product.
The proposal turns a broad question — “how do we improve the agent?” — into a process of editing, running, and comparing. The reported results are promising, but they need to be separated from what developers can reasonably adopt in their own workflows.
What does the framework change?
A harness is the structure that lets a model act: instructions, tool interfaces, memory, rules, and orchestration. Harness² exposes eight editable components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins.
These components act at different points. Instructions can shape planning; a script can check a deliverable; a skill can load a specific procedure; a plugin can affect the tool loop. Changing them can change the agent's behavior while leaving the model weights fixed.
This is an execution harness. It differs from the evaluation harness used to repeat tests of prompts, models, and workflows. One carries out the task; the other helps measure it. I have also covered planning, tools, and context in coding agents. Harness² adds a way to experiment with changes to that environment during a task and learn from the process.
Level one: propose, probe, compose
At the core of the method is Propose–Probe–Compose. The paper describes this sequence:
- Run the task with the current harness and record the trajectory and deliverable.
- Propose candidate edits. One targets general failures, such as planning or tool use; another targets the task's domain.
- Run the candidates on the same task under matched conditions. Compare their trajectories and deliverables with the reference execution.
- Compose a successor harness from changes supported by those contrasts, or keep the previous version when the evidence is weak.
The contrast shows how behavior changed. It does not automatically prove that the final answer is correct. Runs can vary, and different candidates can share the same mistaken assumption.
The framework can also spend a larger exploration budget. Parallel recursion tests several candidates and compositions; sequential recursion carries one round's harness and evidence into the next. More attempts can reveal more, while adding model calls and latency.
Level two: retain lessons across tasks
The second level explains the squared name. After a task, the system stores the adopted harness and lessons supported by execution evidence in an improvement library. A later task can use that experience when proposing new changes.
The next task starts from the base harness. It does not automatically inherit every setting created for the previous problem. Components and lessons are reused selectively for the new situation. This avoids treating a local fix as a permanent rule without evidence that it transfers.
There is a useful practice here even if you never install the project: record not only “this instruction worked,” but which failure it addressed, on which task, and with what evidence.
What did the experiments show?
The authors tested the method on WorkBuddy-Bench, JobBench, and LAB. Gemini 3.5 Flash and GLM-5 served as executor models under OpenCode and Codex; the default harness editor in the experiments was Claude Opus 4.8. This was not a test of one model acting alone.
According to the paper, one improvement step beat the base harness in the evaluated configurations, with gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB's partial pass rate. These are maximum gains in particular settings, not an expected improvement for every agent.
WorkBuddy-Bench includes code tasks alongside web and office work, making it relevant to developers. It still cannot stand in for evaluations on a team's own repositories, languages, tools, and quality criteria. The paper also reports regressions: a selector picked a weaker result, and incorrect assumptions spread across candidates. An improved harness remains a hypothesis supported by executions, not a guarantee.
A small experiment for a coding agent
Consider a fictional task: fix a form whose error state disappears after another submit attempt. The agent finds the component, edits the code, runs tests, and reports back. On its first run, however, it describes test commands in the final answer without actually running them.
One hypothesis is that tool guidance is too weak. Before adding memory, subagents, and plugins, I would test a small change: tell the agent to run the available check, report the command used, and distinguish a test it ran from one it merely suggests.
I would compare the original and edited harnesses on the same task in an isolated environment. I would keep the harness diff, trajectories, produced files, and test results. Then I would repeat the comparison on a few similar and different tasks. I would ask:
- Were the tests actually run, and did they pass?
- Does the change fix the requested behavior without a regression?
- Did the agent use its tools correctly?
- What extra time and cost did refinement require?
- Did the guidance help on other tasks, or make the agent too rigid?
This is an evaluation plan, not an experiment I have run with Harness². A team could apply the same principle with its existing coding agent without reproducing the full framework.
When is the extra work justified?
The approach looks most useful when tasks recur, trajectories are observable, and outcomes can be checked. Small changes to tool guidance, instructions, or scripts can then be evaluated before becoming a default. For a one-off, low-cost task, repeated agent runs may cost more than a direct human review.
The paper's limitations acknowledge extra inference cost and the weakness of judging without known correct answers. The README also says that executor network access is unrestricted and the Codex integration disables its sandbox. Isolation, non-sensitive data, permissions, and network restrictions therefore belong in the experiment design. The repository offers a deterministic local demo without model credentials; model-backed benchmark runs may incur API charges.
My main takeaway from reading the work is methodological: before adding more instructions to “improve the agent,” locate the failure, choose a matching component, and compare the effect through observable runs. If a change does not hold up on new tasks, it may belong only to the original situation.