Google Research Open-Sources Harness²: Freeze the Model, Let the Harness Evolve

On October 6, Google Research quietly pushed a repository to GitHub: harness2. No launch event, no blog fanfare. Two weeks later it had collected 14,000 stars, with the founder personally launching it on Hacker News. Its thesis is a single sentence — and it's worth every agent builder's pause: freeze the model weights, and let the "harness" evolve on its own.

For the past year, agent capability gains have been almost entirely bet on "bigger models": swap in a stronger base, watch the scores climb. Google Research is betting on a second curve instead — keep the model fixed, optimize the system around it. The README opens with the definition: "A harness is the system around a model that enables it to act as an agent: prompts, tools, memory, skills, orchestration, and more. Harnessing is the process of optimizing that system."

This article covers three things: what Harness²'s two-level recursion actually does, which of its 8 editable components are homework a vibe coder can copy today, and how to read its benchmark numbers calmly — because every one of them comes from the team's own testing, flagged with asterisks throughout.

Two levels of recursion: evolve within the task, and across tasks

Harness²'s core mechanism is recursive agent harnessing, in two levels. The first is task-level recursion: for the current task, it refines the execution harness through a contrastive Propose–Probe–Compose step. Propose a batch of harness edits (say, rewriting the system prompt or adding a guardrail), probe their effects by actually running them on the same task, then compose a refined harness from the behavioral contrasts between executions. The key detail: the whole loop runs without ground-truth feedback.

That deserves unpacking. Traditional approaches (DSPy-style prompt optimizers, for instance) mostly rely on labeled training sets: run a batch of samples, check right vs. wrong, tune the prompt. But real-world agent tasks have no ground truth — "refactor this module," "research three competitors' pricing" are fuzzy by nature. Harness² sidesteps ground truth entirely, generating its optimization signal from behavioral contrasts: same task, different harnesses, compare what happened. It's a setup built for the open world — the README says it's designed for "agents encounter tasks unseen during harness design."

The second level is harnessing-level recursion: after each task, the system persists the adopted harness and evidence-supported lessons into a durable improvement harness that guides refinement of the next task. So Harness² doesn't just self-correct inside one task — it accumulates meta-experience about "how to build agents" across tasks. Within-task evolution wins the current game; across-task evolution compounds the winnings.

The two levels connect in one sentence: model weights stay frozen throughout; everything around the model changes. The subtext is sharp — for a year the default diagnosis has been "agent failed = model not strong enough." Harness² asks a different question: maybe your harness is just crude.

The 8 editable components: a copy-ready checklist for vibe coders

For working developers, the most practical part of Harness² isn't the recursion algorithm — it's the first clean decomposition of an "agent harness" into 8 editable, versionable components: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins.

The README even assigns runtime roles: system prompt, guardrails, memory, and skills construct context; tool guidance and scripts define the tool interface; subagents handle delegation; plugins control middleware. That role table is itself an agent-architecture checklist — next time your agent underperforms, don't just swap models; walk the 8 items: is context construction broken (prompt/memory/skills), is the tool interface vague (tool guidance/scripts), or did the delegation chain snap (subagents)?

The engineering maturity is what makes it copyable. Harness² ships with OpenCode and Codex executors out of the box, three professional benchmarks (JobBench for professional work, LAB for legal work, WorkBuddy-Bench for office/web/code), and parallel/sequential recursion modes. The budget flag --k controls task-level recursion depth: --k 1 is one Propose–Probe–Compose round; parallel mode fans out candidate harnesses then composes (broader search), sequential mode carries evidence forward round by round (deeper refinement).

And the lowest barrier of all: the local demo needs no model credentials at all. Per the README, harness2-demo runs deterministic editors with real Python execution — two commands and both recursion loops are live. You can understand the workflow end to end without spending a cent on API calls before deciding whether to bring production models. For anyone learning agent engineering, that's friendlier than any documentation.

Reading the numbers: +11.5 points, but all team self-tested*

The official experiment results (every number below is self-reported by the Google Research team in the README and paper*, not independently verified): across three professional benchmarks and four model–harness configurations, a single Harness² step lifted GLM-5 and Gemini 3.5 Flash above their base harnesses — up to +11.5 points* on WorkBuddy-Bench, +4.5 points* on JobBench, and +11.8 percentage points* on LAB's partial pass rate. Raising the task-level recursion budget (--k) pushes further.

How to read those numbers calmly? Three cautions. First, +11.5 is eye-catching, but composite "office/web/code" benchmarks like WorkBuddy-Bench have high baseline variance — how much of a single-step gain is methodology vs. "the base harness was never tuned well" awaits third-party replication. Second, the tested models are GLM-5 and Gemini 3.5 Flash — notably not flagship-tier models, which actually makes the finding more interesting: if mid-tier models can catch or beat "bare" stronger models through harness optimization, the ROI of agent engineering may beat "waiting for the next model." Third, the README's own Web access section is admirably honest: executor network access is unrestricted by default, Codex even runs with its sandbox disabled, and public benchmark rubrics may be findable online — so you must configure network restrictions before evaluating, lest the harness "see the answers." A team warning in its own README against benchmark cheating in its own repo adds credibility, but it's no substitute for independent replication.

Why vibe coders should take this seriously

One judgment first: the 2026 agent race is splitting a second track off the "model arms race" — the "harness arms race." Harness² didn't invent "optimize the harness," but it's the first open-source implementation to make recursion, automation, and reproducibility work out of the box — from Google Research, under Apache-2.0, free to use.

Three direct takeaways for vibe coders. First, stop blaming every agent failure on the model. Much of what people call "the model got dumber" decomposes into a vague system prompt, tool descriptions missing parameter examples, no guardrail catching hallucinated calls — exactly the surface Harness²'s 8 components cover. Swapping models means waiting months for vendor releases; tuning the harness is something you can do today.

Second, "optimization without ground truth" is an underrated breakthrough. A vibe coder's daily tasks — "build me a landing page," "fix this pile of errors" — almost never have ground truth. Harness²'s contrastive optimization (same task, multiple harness versions, compare behavioral differences) offers an actionable pattern: even without the framework, you can hand-roll "run three prompt versions on the same task and diff the outputs." That's far more scientific than vibes-based prompt tuning.

Third, the improvement harness's "cross-task compounding" deserves its own thought. Most people's agents are disposable: the prompt you tuned this time starts from zero on the next task. Harness² persists validated harness edits as reusable improvement assets — personal experience, engineered. For indie developers, maintaining your own "harness evolution notes" (which edits worked on which tasks, with evidence) may be a more durable investment than chasing new models.

This also connects with our earlier viewpoint piece, "Agent = Model + Scaffolding": that was the thesis, Harness² is the tool — the thesis compiled into runnable code. Read together, they form a complete chain: understand the formula, then get the machine that optimizes it.

Getting started: run the free demo first

If you're convinced, the suggested path: run the local demo first (uv pip install -e '.[render]', then harness2-demo --output runs/demo --k 2) — zero model credentials, watch a full Propose–Probe–Compose loop; then take one of your own small real tasks, run --k 1 --mode parallel, and diff the harness before and after; only then consider production models (which need Node.js 20+, the Google Cloud CLI, plus Pandoc/Poppler for LAB and Docker for WorkBuddy-Bench — the README's dependency list is thorough).

On the model side it goes through Vertex AI (gcloud auth application-default login with a .env file) — developers in regions without easy GCP access may hit network and auth walls on the model-backed path, but that doesn't block the demo. Remember the design philosophy: let the harness evolve in the cheap environment first; bring the expensive model only once the evolution makes sense.

Sobriety checklist: three "buts" you must know

First, all benchmarks are team self-tested* — no third-party replication exists yet. +11.5 points is beautiful; how much of it transfers to your tasks is unknown. Second, the README's footer carries a one-line disclaimer: "This is not an officially supported Google product." It's a Google Research project, not an officially supported product line — discount the long-term maintenance accordingly. Third, guard your own security boundaries: executors ship with unrestricted network access and Codex's sandbox off by default; read the network-restrictions section of the docs before running unfamiliar tasks, lest your agent "evolve" your API keys out the door.

Even with all three buts counted, Harness² remains the most instructive open-source homework in agent engineering this year: it turned "optimize the harness" from folk wisdom into 8 components, two recursion levels, and one CLI. Models will keep getting stronger — but the ability to squeeze another round of life out of an old model with a better harness will only get more valuable.

Transparency note: facts in this article are sourced first-hand from the Google Research repository README (read in full on 2026-10-20) and paper arXiv:2610.14224; all benchmark gains are team self-reported*, asterisked in the text, and not independently verified; the repository was created 2026-10-06 with press coverage starting 10-14, inside the publication window; the repo states it is not an officially supported Google product.