Google’s Harness² Optimises the Agent, Not the Model

TL;DR

Google Research released Harness² on 9 October 2026, an open-source framework for “recursive agent harnessing”: optimising the system around a model — prompts, tools, memory, skills, orchestration — while the weights stay frozen.
Recursion runs at two levels: task-level recursion refines the harness for the current task via a contrastive Propose–Probe–Compose step with no ground-truth feedback; harnessing-level recursion writes adopted harnesses and lessons into a persistent “improvement harness”.
One Harness² step beats the base harness for GLM-5 and Gemini 3.5 Flash across three benchmarks and four model–harness configurations: up to 11.5 points on WorkBuddy-Bench, 4.5 on JobBench and 11.8 percentage points on LAB’s partial pass rate.
The code is Apache 2.0. The repository warns that executor egress is unrestricted, Codex runs sandbox-disabled, and public rubrics may be reachable online.

The binding constraint moved from weights to wiring

The default way to improve an agent is to change the model: another post-training run. Harness² inverts the premise. Google Research published it on 9 October 2026 as a framework for “recursive agent harnessing” — making the system around the model the optimisation target. The paper is arXiv 2610.14224, by Xu and colleagues at Google Research. (Source : arXiv — Harness²: Recursive Agent Harnessing for an Open World)

The wager: for professional work, the return on harness changes now exceeds the return on another fine-tuning pass. That is a claim under test, not an established result. If it holds even partly, the unit of iteration stops being the checkpoint and becomes the harness. (Source : Harness² project site)

Eight components, two levels of recursion

The editable surface is explicit: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins — the parts that govern context construction, the tool interface, delegation and behaviour. (Source : Google Research — Harness² repository)

Task-level recursion refines the execution harness for the task at hand through a contrastive Propose–Probe–Compose step: propose edits, probe their effects on the same task, then compose a refined harness from the behavioural contrasts between executions. No ground-truth feedback enters that loop. (Source : arXiv — Harness²: Recursive Agent Harnessing for an Open World)

Harnessing-level recursion sits above it. Each task’s adopted harness and its evidence-backed lessons are written into a persistent “improvement harness” that guides refinement on later tasks — the first level improves one run, the second improves the improver.

Contrastive search without a rubric

Most harness-optimisation work smuggles in a reward: a test suite, a rubric, an answer key. Professional tasks rarely offer one — a legal memo ships without a reference output to diff against, which is why much self-improving-agent work leans on benchmarks with answers.

Harness² substitutes behavioural contrast for the rubric. The signal is not “did this score higher” but “how did behaviour differ between these executions, and which difference looks like the edit’s cause”. (Source : arXiv — Harness²: Recursive Agent Harnessing for an Open World)

Analysis: this is cheapest exactly where labels are absent, and it inherits the weakness of every self-referential loop — a contrast can be real and still irrelevant. Two runs can differ in verbosity or tool-call count without differing in correctness.

What the numbers show, and what they do not

The results are consistent. Across three professional benchmarks and four model–harness pairings, one Harness² step improved GLM-5 and Gemini 3.5 Flash over their base harnesses: up to 11.5 points on WorkBuddy-Bench, 4.5 on JobBench, 11.8 percentage points on LAB’s partial pass rate. A larger task-level recursion budget brings further gains. The test set is unglamorous by design: JobBench (professional work), LAB (legal; needs Pandoc and Poppler) and WorkBuddy-Bench (office, web and code; needs Docker). (Source : Data Studios — Google Research open-sources Harness²)

Parallel recursion probes k general and k domain-specific candidates, then composes k harnesses from shared evidence — wider exploration. Sequential recursion carries the refined harness and evidence through k successive steps — deeper refinement. The CLI takes --k, --mode parallel|sequential and --substrate cx (Codex instead of the default OpenCode executor). (Source : Harness² project site)

Analysis: the release reports points, not price. Every probe is a real execution, so k multiplies compute and wall-clock; the honest metric is gain per probe. Transfer is asserted structurally but never quantified: nothing published says how much a legal-task harness survives into office work.

The contamination trap is written into the README

The repository’s security note matters more than release notes usually admit. Executor network access is unrestricted, Codex runs with its sandbox disabled, and public rubrics may be accessible online; network restrictions must be configured before evaluation to stop the agent reaching answers and grading criteria. (Source : Google Research — Harness² repository)

Analysis: that is a reproducibility trap with two failure modes. The obvious one is a harness that “improves” because it fetched the rubric. The subtler one is compounding contamination: because lessons land in a persistent improvement harness, one leaked evaluation seeds guidance that travels into every later task, long after the leak leaves the logs.

What changes for builders

Skills, memory and guardrails become versioned artefacts. Eight components means eight changelog surfaces; without git and an eval, a harness change is an unreviewable diff.
Budgets become hyperparameters. --k and --mode decide whether you explore wide or refine deep, and the modes are not interchangeable at equal cost.
The demo is the on-ramp. harness2-demo runs both recursion modes on deterministic editors with real Python executions — Linux, Python 3.12, uv, no credentials; model-backed runs need Vertex AI credentials, Node.js 20+ and the gcloud CLI.
Lock the network before you evaluate, at the executor level where the sandbox lives — not inside the harness.

FAQ

Does Harness² train or fine-tune the model? No. Weights stay frozen; everything optimised lives in the harness around the model.

What does “recursive” mean here? Task-level recursion re-runs Propose–Probe–Compose on the current harness; harnessing-level recursion turns adopted harnesses and lessons into a persistent improvement harness. (Source : arXiv — Harness²: Recursive Agent Harnessing for an Open World)

How does it improve without ground-truth answers? Edits are proposed, probed on the same task, and the refined harness is composed from behavioural contrasts instead of a score.

Can I try it without model credentials? Yes — harness2-demo runs both recursion modes on deterministic editors with real Python executions.

Is it an official Google product? No. The repository says it is not officially supported and sits outside the OSS Vulnerability Rewards Program.

Google's Harness² Optimises the Agent, Not the Model