Google Harness²: Recursive Agent Harnessing

Google Harness² (google harness2) is a research framework that changes an AI agent's operating setup while it works, then saves lessons for later tasks. An October 2026 paper reports gains of up to 11.5 points on WorkBuddy-Bench from one refinement step; that's an author-reported result, not an independent reproduction.

Key Takeaways:

An agent harness is the instructions, tools, memory and execution rules around a model; the model's weights needn't change.
Harness² tests candidate changes on a task through Propose–Probe–Compose, then records selected lessons in a domain experience library.
Its best reported benchmark gains are relative to each base harness, not absolute scores or a promise for your workflow.
This is open research code, explicitly not an officially supported Google product.

What Google Harness² Is, and What an Agent Harness Means

Think of asking an assistant to prepare a client update. Its model can draft sentences, but the surrounding system decides which document it can read, whether it may update the task board, which instructions survive a long run and when it must ask you before sending anything. That surrounding system is the agent harness. Our agent harness explainer covers the broader vocabulary; this article examines Google's particular experiment in changing that layer during a task. In google harness2, those settings are editable.

The google-research/harness2 repository lists eight editable components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins. These are changes to an execution harness, not to model weights. The authors, including Ruiyao Xu, describe two linked loops: one revises the current task's setup; the other accumulates experience for future revisions. The Apache-2.0 code supports OpenCode and Codex; version 0.1.0 requires Python 3.12 or 3.13.

The arXiv record for Xu and colleagues' Harness² paper, showing the abstract and reported results.

Keep the context, not another setup checklist

Zentor keeps workspace memory available across the AI tools you use through Zentor MCP. Explore early access for work that should carry context forward.

Prepare this week's client update…Get early access →

How Propose–Probe–Compose Changes a Running Harness

The task-level loop begins with executions using a shared base harness. The improver proposes general and domain-specific edits, probes candidate harnesses on the same task, and composes a revised configuration from the differences it observes. The paper's method uses behavioral contrasts rather than a ground-truth verifier to guide this process. That distinction matters: observing a cleaner-looking output doesn't prove the answer is correct.

Consider a hypothetical research task that loses a source citation halfway through. A candidate might revise tool guidance to preserve links; a second might add a verification instruction. Probe runs offer evidence about whether either change actually alters behavior on that task. Only the adopted changes form the current refined harness. This is a hypothetical, not a reported experiment.

The experiment guide distinguishes parallel exploration of candidates from sequential refinement of the current harness. Budget k sets how much task-level exploration to do. More tries can find useful adjustments, but each added execution and editing session consumes resources.

Editorial flowchart of Propose, Probe and Compose, followed by experience-library adoption.

What the Experience Library Actually Carries Forward

Harness² has a second loop because a fix for one job may help with another. Following a task, its per-domain library keeps the adopted harness tree and an EXPERIENCE.md entry explaining why it was selected and what recurring weakness it addressed; an index points to entries. The paper appendix says executable components remain intact rather than being collapsed into a vague summary.

The next task does not blindly inherit the last task's entire execution harness. It starts from a common base, while the improvement process consults prior adopted configurations and lessons. Domain tasks run in order so later tasks can read earlier entries; the experiment guide says libraries also remain separated by benchmark, executor, mode, budget and seed. That guidance isn't new model knowledge or blanket access to prior tasks.

For a student repeating literature searches, the useful distinction is between keeping the sources and preferences for their work, and changing the agent's rules for checking citations. Zentor's user-owned workspace memory can travel to other AI through MCP; Harness²'s experience library instead stores evidence about harness edits in this research setup. They store different things.

What the Harness² Benchmark Numbers Do and Don't Prove

The authors report one-step 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, across three professional benchmarks and four model–harness configurations. The paper and repository README name GLM-5 and Gemini 3.5 Flash. These are gains over each configuration's base harness, not final scores; “up to” selects a best reported improvement, not a typical outcome. We have not independently rerun the benchmarks.

Editorial table distinguishing the authors' reported relative gains from absolute benchmark scores.

The comparison does support a narrower claim: with model weights fixed in these tests, changes to the operating setup can change measured performance. Our agent evaluation analysis also explains why a score belongs to a model–harness pairing, although its separate benchmark cannot verify google harness2 results. It doesn't isolate a universally best harness, prove transfer to your own agent, or guarantee that a plausible-looking probe is right. The paper's limitations acknowledge extra inference cost and that behavioral comparison without ground truth cannot guarantee correctness. Its reproducibility notes also warn that public benchmark rubrics may be reachable over unrestricted executor networking; controlled egress matters before treating a rerun as clean evidence.

Harness Versus Model: Why the Runtime Is a Competitive Variable

The term has spread because different teams are making the runtime a visible product decision. In its October 19 release, Notion says it rebuilt its agent harness with a computer, browser and context controls. Microsoft describes the GitHub Copilot harness in Copilot Studio as coordinating model calls, context and tools. DeepSeek Harness names the runtime itself; Harness² studies how one might revise such setups. These aren't interchangeable products, and the vendors' uses of “harness” differ.

For a one-person business, the question isn't whether a benchmark's agent won by changing prompts or plugins. It's whether your assistant remembers the approved brief, knows which tools it may touch and leaves an auditable draft rather than sending a client promise unreviewed. Zentor's self-learning skills and self-adaptive workspace are product approaches to reducing repeated setup; neither implies that Zentor runs Harness² or reproduces its published scores. Model choice remains important, but ignoring the execution layer makes comparisons misleading.

Is Harness² Production-Ready?

Treat google harness2 as an experiment you can inspect, not a managed service to hand a live inbox. The repo's disclaimer states: “This is not an officially supported Google product.” Its installation guide targets Linux, Python 3.12 and uv for a local demo; model-backed benchmark runs need additional setup and incur API costs. The README says executor network access is unrestricted and Codex runs with its sandbox disabled, and instructs users to restrict access to benchmark answers before evaluation.

That warning has a practical edge. Don't attach confidential client files or grant an unbounded write tool to research code just because the paper improved a benchmark score. Run a small, isolated test with a known task and explicit review rules first. Zentor, by contrast, is a workspace memory hub for getting context to the AI you use; it is not a hosted instance of this Google Research repository. Everyday assistance calls for a product evaluation, not this research prototype.

FAQ About Google Harness²

Is Google Harness² a new AI model?

No. It edits the harness around a model while the model's weights stay fixed in the study.

Does it require an answer key to improve a task?

No ground-truth verifier guides its online edits. It compares observed behavior across runs; that does not guarantee correctness.

Does the next task reuse the last task's harness?

It starts from the common base. The improvement process can consult adopted harness trees and EXPERIENCE.md lessons from earlier tasks in its domain.

Can I install Harness² as a supported Google service?

No. It is Apache-2.0 research code, and the repository explicitly says it is not an officially supported Google product. For practical evaluation, inspect its executor permissions and budget before running anything connected to your data.