Google just open-sourced self-improving agents. The harness beat the model.

Last Updated: October 19, 2026

On October 18, 2026, Akshay Pachaar posted that Google had open-sourced "Harness²: turn any harness into a self-improving system." The tweet passed 350,000 views in about a day. Underneath the hype sits something verifiable: a paper from Google Cloud AI Research (arXiv:2610.14224, published October 9, 2026), a code release under Apache 2.0, and the cleanest evidence yet for an idea practitioners have been repeating all year: the harness is the moat, not the model.

According to the Harness² paper, GLM-5 running a harness it improved for one task scored 75.7 on WorkBuddy-Bench under OpenCode, while base Gemini 3.5 Flash with its untouched harness scored 72.4. The same held under Codex (75.3 vs 74.5). A weaker model with a self-improved harness beat a stronger model with a default one, in both tested executors, across legal, office and professional-work benchmarks. That single result reframes how much of agent quality is model and how much is scaffolding.

What is Harness², exactly?

Harness² is a plug-and-play framework for recursive agent harnessing. It is released at github.com/google-research/harness2, and per the Google repository it already counts about 6,600 GitHub stars two weeks after the repo was created on October 6, 2026. The definition from the project's own site: a harness enables a model to act as an agent, and harnessing is the process of optimizing that system.

The framework keeps model weights frozen and exposes eight editable components, each mounted as a file in the runtime: system prompt, guardrails, memory, tool guidance, scripts, subagents, skills, and a middleware plugin. Model weights never change. Everything around the model can.

The two-level recursion is the actual invention. Task-level recursion refines the execution harness for the current task. Harnessing-level recursion updates the improvement harness, the mechanism that decides how future harnesses get refined. In the paper's words: "the execution harness is the system being improved, and the improvement harness is the mechanism that improves it."

How does Harness² work without ground-truth answers?

Open-world tasks arrive unseen, with no solution key and no unit tests. Most self-improvement methods quietly assume a grader exists. Harness² replaces verification with a contrastive loop called Propose-Probe-Compose.

Here is the loop as Google runs it:

• Propose. The agent first runs the task once with the current harness. The trajectory shows how the harness behaves, not whether the answer is right. Two candidate harnesses are then drafted: an invariant candidate targeting generic agent deficiencies (planning, tool use, context management, delegation) and a domain-specific candidate targeting the knowledge and procedures of the current domain, say legal redlines or financial reconciliations.
• Probe. Each candidate runs on the same task with matched model and environment. Comparing trajectories and deliverables against the reference produces a behavioral contrast: did the edit mitigate the targeted deficiency, change nothing, or introduce regressions?
• Compose. The composer reads all the evidence and selectively merges supported changes, revises conflicting ones, adopts one candidate, or keeps the current harness. Every decision must trace to a concrete observation, not a presumed score. The composed harness then runs and produces the actual deliverable.

Scaling the budget k either goes wide or deep: parallel recursion probes k invariant and k domain candidates at once and composes k successors, while sequential recursion chains k Refine-Probe-Compose steps, each inheriting the accumulated evidence. For k above 1, an agentic selector picks the winning deliverable while blinded to which harness produced it.

After each task, a reflector reviews the entire improvement record and writes the adopted harness plus an EXPERIENCE.md file (applicable situation, lessons, supporting evidence) into an improvement library. Lessons are only retained when backed by execution contrasts. The next task still starts from the stock harness, but its refinement starts from everything the last tasks learned.

The library is not decorative. In Google's ablation, removing it cost 3.1 points on WorkBuddy-Bench and 1.8 on JobBench. A library accumulated on JobBench even improved refinement on WorkBuddy-Bench by up to 2.9 points, evidence the lessons transfer across domains. Removing editor scoping (two generic editors instead of invariant plus domain) cost 2.9 and 3.7 points, and dropping composition entirely cost 1.6 and 1.9. All three ingredients matter.

The receipts: Google's benchmark numbers

The paper evaluates GLM-5 and Gemini 3.5 Flash under two stock executors (OpenCode and Codex) on three professional benchmarks: WorkBuddy-Bench (office, web and code deliverables), JobBench (end-to-end professional job tasks), and LAB, Harvey's legal agent benchmark. Four model-harness configurations per benchmark, three runs each with shuffled task order.

According to the Harness² paper (Tables 1 and 2), a single contrastive step improved every configuration on every benchmark:

• WorkBuddy-Bench: up to +11.5 points (GLM-5 under OpenCode went from 64.2 to 75.7 average).
• JobBench: up to +4.5 points (Gemini 3.5 Flash under OpenCode, 31.5 to 36.0).
• LAB partial pass rate: up to +11.8 percentage points.
• Tool-error rates fell on all three benchmarks, for example 14.4% to 9.1% on JobBench, a 36.8% relative reduction.

Increasing the budget k=5 adds more: 2.9 to 3.9 further points on WorkBuddy-Bench, up to 4.2 on JobBench, and up to 6.7 percentage points on LAB. Parallel recursion pushed WB-code from 76.5 to 80.8 and WB-office from 79.5 to 83.4 as k grew from 1 to 5, a monotonic climb while baseline methods fluctuated. The compute-performance curve shows both tested configurations on the empirical Pareto frontier, so the extra tokens buy real score.

Against the alternatives

The production-harness comparison frames just how much upside stock agents leave behind. On WorkBuddy-Bench, no fixed harness led everywhere: Claude Code was best on Code and Office, Codex on Web. Harness² starting from OpenCode beat the strongest fixed alternative in each domain by 4.6 (Code), 5.8 (Web) and 4.9 (Office) points. Refinement costs extra test-time compute, but it beat everything standing still.

Where it stumbles ( Haley the fine print)

Harness² is not magic, and the paper says so plainly:

• Selection can fail. In the failure analysis, the selector once chose an output scoring 55 over one scoring 95 on WB-code, and narrow coverage dropped a LAB result from 54 to 26.
• Bad premises spread. A wrong assumption (a literal-key requirement, an unchecked cache) propagated across candidates and cost 2 to 11 points.
• Costs are real. Extra executions and editor sessions add inference spend. Parallel sessions cut latency, not cost, and the paper graphs the trade-off rather than claiming a free lunch.
• Execution evidence is noisy. Without ground truth, behavioral contrasts remain sensitive to run-to-run variability and shared model bias. Lessons can fail to transfer.

One other transparency note: the repository carries Google Code of Conduct-style disclaimers, including that Harness² "is not an officially supported Google product." It is a Google Cloud AI Research team release under Apache 2.0, not a Vertex AI service.

Why this matters if you are building agents

Per the paper, the improvements did not require a smarter editor. The same model played executor and editor in tests covering five models from GLM-5 to Claude Opus 5, and every model improved on every benchmark. Claude Opus 5 gained 3.3, 5.5 and 3.0 points on WorkBuddy-Bench, JobBench and LAB; GLM-5 gained 13.7 points on LAB. The reflexes live in the harness, not in hidden model scale.

That is the shift worth internalizing. The default agent stack treats the harness as a setup cost: write the system prompt, register the tools, ship. Harness² treats it as an asset that compounds: every task makes the next task's harness smarter. Google's numbers argue the compounding is worth real points, enough that harness quality moves which model you actually need.

For consultancies building production agents, three implications follow directly from the paper's numbers:

• Benchmark the stack, not the model. The same model scored differently across configs; differences up to 11.5 points came from the harness, all while weights stayed frozen.
• Fix failure modes procedurally. Google's case study is instructive: a baseline JobBench run scored 43.1 because data was never reconciled across files and outputs were never reopened for verification. Two targeted harness edits (a procedural guardrail and a reconciliation skill) lifted the re-run to 77.8.
• Plan for spend. Self-improvement buys score with test-time tokens. The Pareto frontier shows the cost curve mostly pays for itself, but recursion budgets should scale with task value, not curiosity.

At Flowtivity this mirrors what we see deploying agents for Australian SMBs: the gap between a demo and production rarely lives in the model. It lives in the harness: the guardrails, the verification steps, the read-only treatments of client data, the reconciliation rules. Google's contribution is showing that this layer can improve itself safely, with no answer key, using nothing but contrasts between how the agent actually behaved.

How to try Harness² this week

The repo sells a plug-and-play path, and the quick start is honest about dependencies.

• Install (Linux, Python 3.12, uv): uv pip install -e '.[render]', then run the credential-free demo: harness2-demo --output runs/demo --k 2. The demo exercises both recursion modes with deterministic editors and no model credentials.
• For model-backed runs you configure executors in .env: OpenCode is the default, Codex is available via --substrate cx.
• Scale the loop: harness2 --bench jb --k 1 --mode parallel runs one contrastive step on one JobBench task; bump --k, or switch to --mode sequential to chain steps.

Fair warning from the maintainers: model-backed benchmark runs burn API spend, so Google suggests starting with a small task selection. LAB needs Pandoc and Poppler; WorkBuddy needs Docker.

The honest caveat for enthusiasts: the tested executors are OpenCode and Codex, under GLM-5 and Gemini 3.5 Flash. Your mileage with other agents or models is unreported, and results are mean of three runs with standard deviations, not one lucky seed. The license is Apache 2.0, so for agencies and consultancies the code is safe to build on.

Frequently Asked Questions

What is a harness in an AI agent?
It's everything wrapped around the model: system prompt, tools, memory, skills, guardrails, subagents and orchestration. Harness² treats those as eight editable files and optimizes them automatically.

Does Harness² change model weights?
No. Model weights stay frozen; all changes happen in the harness files around the model.

Which models and executors does Harness² support?
The paper tests GLM-5 and Gemini 3.5 Flash under OpenCode and Codex. Claude Opus 4.8 was the default editor for the improvement steps, and the same-model executor-editor test spanning five models (from GLM-5 to Claude Opus 5) worked without a stronger editor.

What is Propose-Probe-Compose?
The contrastive loop at the core: propose candidate harness edits, probe them by executing on the same task under matched conditions, and compose the changes whose behavioral contrasts justify keeping them.

Is Harness² an official Google product?
No. Per its README it is "not an officially supported Google product." It is an open-source release (Apache 2.0) from a Google Cloud AI Research team.