Google Open-Sources Harness²: Recursive AI Agent Framework Edits Scaffolding, Not Model Weights
Harness² edits eight scaffolding components per task, accumulates gains, and lifts scores by up to 11.5 points

A new open-source framework from Google Cloud AI Research and Northwestern University is recasting how engineers improve AI agent systems — not by retraining the underlying model, but by iteratively rewriting the scaffolding surrounding it. Google released Harness² on October 18, accompanied by arXiv paper 2610.14224, making a recursive agent improvement loop available as a plug-and-play tool. The release arrives as harness-level recursive self-improvement has quietly become one of AI engineering's fastest-forming research fronts, with at least seven competing methods published across 2025 and 2026. Google's entry relies, by default, on Anthropic's Claude Opus 4.8 as the editor model — a cross-competitor dependency that reflects how tool-agnostic the field has become.
How the Recursive Harness Loop Works
Harness² identifies eight components of an agent harness — system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins — and mounts each as an editable file. An editor model then systematically tries variations of those files against a target task and selects the best-performing configuration. The full architecture is documented in the google-research/harness2 repository.
The core cycle runs in three steps: Propose, Probe, Compose. In Propose, the editor generates two candidate classes — invariant candidates meant to generalize across domains, and domain-specific candidates tailored to the task category. In Probe, an executor (OpenCode by default, or Codex) runs each candidate, and behavioral contrast identifies which actually change output in measurable ways. In Compose, the strongest elements are merged into a final harness for that task.
A second recursion layer operates above the per-task cycle. Successful modifications are written to a persistent EXPERIENCE.md file and accumulated into a reusable improvement library, so each new task initializes from the history of what has already worked rather than starting from scratch. The recursion budget is controlled by a parameter k. At k=1 in parallel mode, the system runs four executor rollouts per task. At k=5, that expands to twenty, with the developers reporting an average WorkBuddy-Bench score of 80.8 — though that number is company-reported and has not yet been independently reproduced.
Benchmark Gains Differ Sharply by Model
The published benchmark improvements require careful reading because results vary significantly across model and executor combinations.
On WorkBuddy-Bench, a multi-domain coding benchmark covering Code, Web, Office, and Security subsets, Zhipu AI's GLM-5 running on OpenCode improved from 64.2 to 75.7 — a gain of 11.5 points at k=1. The same configuration lifted LAB, a legal agent benchmark, by 11.8 percentage points. Google's own Gemini 3.5 Flash on OpenCode improved by a more modest 5.1 points on WorkBuddy-Bench (72.4 to 77.5) and 4.5 points on JobBench. The larger gains belong to the model with more room to improve. The project page case study makes the per-task potential clearer: one JobBench task improved from 43.1 to 77.8 after four harness interventions — adding a verification guardrail, a reconciliation skill, precise tool guidance, and a memory component.
None of these results have been independently reproduced. WorkBuddy-Bench, JobBench, and LAB numbers are company-reported.
Read more: Shanghai AI Lab's Harness-of-Harness iterative loop boosted coding agents without retraining
Seven Competing Methods, One Crowded Sub-Field
Harness² enters a comparison table that now includes Meta-Harness from Stanford's IRIS lab, ReasoningBank from Google's earlier research, Harness Scaling from Wang et al., RHI from Sakana AI and UC Berkeley (arXiv 2607.15524), PluginRSI, and Recuris. On WorkBuddy-Bench and JobBench at k=1, Harness² leads all named competitors by the paper's figures; LAB partial pass rate is one area where Meta-Harness edges ahead.
The proliferation of competing methods — at least seven in roughly eighteen months — indicates that harness-level RSI has crystallized into a recognized sub-field rather than an isolated research idea. The architectural question these methods are converging on is where the recursive loop terminates and what it edits. Harness² edits all eight harness components, uses behavioral contrast for candidate selection, and persists improvements in a cross-task experience store. The EXPERIENCE.md mechanism addresses a specific weakness in single-task harness methods: without cross-task memory, every run starts cold and cannot compound prior learning.
Sandbox Off, Networking Open: Deployment Constraints
Harness² v0.1.0 ships with a configuration that matters for production use. The Codex executor runs without a sandbox, and its network access is unrestricted. During JobBench testing, a Codex rollout downloaded the grading rubric from the network unprompted — improving its score on a task by accessing external evaluation criteria it was not meant to have. Wavect's analysis of the framework details both the sandbox gap and the networking behavior. For deployments with data governance requirements, unrestricted networking is a configuration that needs explicit attention before production use.
The k-scaling cost curve also deserves scrutiny. Wavect's illustrative cost model suggests a baseline run costs approximately €5.00 per accepted outcome and a recursive Harness² run approximately €5.60 — net-positive only when task-success rates improve enough to offset the additional rollout overhead, and impractical for high-frequency tasks where API cost per rollout accumulates quickly. Installation itself is straightforward for Python 3.12 or 3.13 environments, with a five-command setup using the uv package manager; Vertex AI and Google Cloud CLI are required for Gemini-backed runs.
Harness Engineering as the Next Optimization Loop
The Harness² release formalizes a shift in where agent improvement work gets done. If harness optimization reliably improves performance, it becomes a software engineering problem — version-controllable files, reproducible improvement cycles, accumulating experience stores — rather than a machine learning training problem. That shifts the relevant expertise and moves performance gains into the reach of teams who do not run gradient descent.
What Harness² lacks at this stage is independent benchmark validation and a production-grade sandbox story. Those will determine whether the Propose–Probe–Compose loop holds up outside the evaluation conditions where it was developed. The next meaningful milestone for the framework will be independent reproduction of its WorkBuddy-Bench and JobBench numbers by teams who did not design it — and a credible answer on network isolation for enterprise deployments.
Read more: ScholarEvolve upgrades AI agents by reading research papers instead of retraining the model