Google Research open-sources Harness² for recursive agent improvement under Apache 2.0

What did Google Research release?

On 9 October 2026, Google Cloud AI Research authors posted Harness²: Recursive Agent Harnessing for an Open World on arXiv as 2610.14224. The matching code repository, google-research/harness2, was created on 6 October 2026 under the Apache License 2.0. The README describes Harness² as a plug-and-play framework for recursive agent harnessing when agents face tasks that were unseen when the harness was designed.

The paper and repo treat a harness as the system around a frozen model that lets it act as an agent: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins. Harnessing is the process of optimizing that layer. That framing sits beside other October work on agent scaffolding, including OpenCode 2.0's agent runtime changes, but Harness²'s claim is specifically recursive improvement of the harness itself.

The disclaimer on the repository is explicit: this is not an officially supported Google product and is not eligible for Google's open-source vulnerability rewards program. Third-party code under third_party/, plus benchmarks and datasets, keep their upstream licenses.

How does Harness² improve an agent without changing weights?

Harness² connects two levels of recursion while the underlying model stays fixed. Task-level recursion refines the execution harness for the current task. Harnessing-level recursion then updates a continual improvement harness with adopted harnesses and lessons that later tasks can reuse.

The core task-level step is contrastive Propose–Probe–Compose. The pipeline first runs a reference execution with the current harness. It then proposes two kinds of candidate edits: an invariant candidate aimed at recurring agentic weaknesses such as planning or tool use, and a domain-specific candidate aimed at the current domain's procedures and constraints. Each candidate is probed on the same task under matched conditions. Composition selectively merges, revises, or rejects edits based on behavioral contrasts between trajectories and deliverables, without treating those contrasts as ground-truth correctness labels.

Parallel recursion widens exploration by probing multiple candidates and composing several successors. Sequential recursion chains successive Propose–Probe–Compose steps so later edits can correct earlier ones. The README's budget flag --k controls that width or depth. After the task finishes, harnessing-level recursion writes an EXPERIENCE.md-style library entry when evidence supports transfer, rather than blindly inheriting the last tailored execution harness.

What do the reported benchmark numbers say?

The paper evaluates WorkBuddy-Bench, JobBench, and Harvey's Legal Agent Benchmark (LAB) across four model–harness configurations that pair GLM-5 or Gemini 3.5 Flash with OpenCode or Codex initial harnesses. Main tables report Harness² with a single improvement step (k=1); a + Recursion row shows parallel recursion at k=5.

According to the authors, a single step improves both models over their base harnesses in every configuration they report, 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. Parallel recursion at k=5 adds further reported gains of roughly 2.9 to 3.9 points on WorkBuddy-Bench averages, 3.0 to 4.2 on JobBench, and 2.6 to 6.7 percentage points on LAB Partial, depending on the configuration.

These figures are Google's own evaluation results, not independent third-party audits. The paper also reports ablations: removing the improvement library, scoped editors, or composition each lowers WorkBuddy-Bench and JobBench scores in the Gemini 3.5 Flash and OpenCode setting they isolate. A leave-one-out library re-run and a JobBench-to-WorkBuddy transfer experiment are presented as evidence that harnessing-level recursion can help later tasks, including without additional probing when a richer library is already available.

How do you run it, and what does it cost?

The repository targets Linux, Python 3.12, and the uv package manager. A local demo command runs both recursion modes with deterministic editors and real Python executions and, per the README, needs no model credentials. Model-backed benchmarks need Node.js 20+, the Google Cloud CLI, and benchmark-specific dependencies such as Pandoc, Poppler, or Docker. The project documents OpenCode and Codex executors and three installable benchmarks: JobBench, LAB, and WorkBuddy-Bench.

Model-backed runs incur API costs. The README warns operators to start with a small task selection, notes that judging and reporting must match the same benchmark, executor, subset, --k, mode, and seed as the refinement run, and documents --dry-run to preview task selection. A separate experiments note flags unrestricted executor network access and disabled Codex sandboxing unless operators configure network restrictions before evaluation, because public benchmark rubrics may be reachable online.

In short: the demo path is free of model bills; the published professional-benchmark path is not. Teams comparing Harness² with other October harness work should budget for editor and executor tokens as well as wall-clock concurrency when raising k.

Why does recursive harnessing matter for builders?

October 2026 already had several harness-shaped stories: Chainguard's Mythos vulnerability harness, LongHarness-style scaffolding papers, and production MCP servers that expose tools to assistants. Harness² is different because the object of improvement is the harness itself, and because the authors argue open-world tasks often lack the ground-truth verifiers that offline harness search assumes. That is closer to how coding and office agents actually meet novel tickets than a static config chosen on a training split.

For product teams, the practical hook is transfer: keep a strong base model, edit file-level components, and accumulate a library of reusable harness pieces plus EXPERIENCE notes. The paper's same-model executor-and-editor experiments claim gains even when the editor is not stronger than the executor, which—if it holds outside Google's setup—lowers the bar for shops that cannot route every revision through a frontier editor model.

The work also sharpens a vocabulary split worth keeping in editorial coverage: agent capability is not only a model-card score. It is model plus harness, and harnesses can recurse.

What are the limits and open questions?

The authors list cost and feedback quality as central limits. Recursive refinement spends extra executions and editor sessions; raising k adds inference. Behavioral contrasts are sensitive to execution noise and shared model biases, and they do not prove correctness or guarantee transfer. The paper's failure analysis shows cases where selection preferred a weaker deliverable, where a bad premise propagated across candidates, and where outcome variability obscured editing effects.

Operational caveats matter as much as research caveats. Benchmarks and third-party trees keep separate licenses. Network access during evaluation can leak rubrics unless restricted. The project is research code, not a Google Cloud SLA product. Independent replications on held-out private workloads, clearer cost–quality curves for k greater than 5, and stronger selection methods are still open.

Readers tracking adjacent scaffolding should keep Harness² distinct from vulnerability-hunting harness products and from MCP write-action stories such as Mercury's payment tools for ChatGPT and Claude. Those change what an agent can call. Harness² changes how the agent is wrapped while it calls.

What should a team try first?

Start with the credential-free local demo to learn the Propose–Probe–Compose loop and the eight editable components. Then install one benchmark with a tiny --max-tasks setting, keep k at 1 until the pipeline is reproducible, and only then widen parallel or sequential recursion. Log token spend for executor and editor separately so the recursion budget is an explicit cost dial rather than an invisible bill.

If the goal is production transfer, treat Google's library format as a design prompt: store executable component trees with evidence-backed EXPERIENCE notes, require workspace facts to be re-verified before reuse, and refuse to promote edits that lack a named trajectory moment. That discipline is stricter than dumping trajectories into a prompt cache, and it is the part of Harness² most likely to survive contact with internal evals.

• Run harness2-demo before any Vertex-backed benchmark.
• Match judge and report flags to the exact refinement command.
• Configure network restrictions before scoring public benchmarks.
• Separate executor tokens from editor tokens when comparing k values.