Google Harness2: An Open-Source Framework That Rewrites the Agent Around a Frozen Model

Update — October 21, 2026: New vision-first entry: OpenVLHarness from UCLA NLP adds visual tools and persistent multimodal memory to any tool-calling model.

Google Research has open-sourced a different answer to "my agent is not good enough": leave the model alone and rewrite everything around it. Google Harness2 is an Apache-2.0 framework that recursively edits an agent's harness (system prompt, tools, memory, skills and scripts) for each new task while the model weights stay frozen. The authors report 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. The paper is Harness^2: Recursive Agent Harnessing for an Open World, and the code lives in the google-research/harness2 repository.

This post explains how the method works, what the headline numbers actually measure, what it costs to run, and why the README's own warnings matter more than the benchmark table.

Harness2 at a glance

What is an agent harness, and why edit it?

A lightweight scaffold frame holding a model, the agent harness Google Harness2 edits

A harness is the working system around a model: the instructions it gets, the tools it can call, what it remembers, which reusable skills it has, and how its steps are orchestrated. The same model can look much stronger or weaker depending on that scaffolding, which is why agent harness engineering became its own discipline this year, and why harness comparisons go viral in tier lists.

Most harnesses are written once by a human and then reused. Harness2 asks what happens when a task falls outside what the human designer anticipated, the "open world" in the paper's title. Instead of retraining anything, it lets an editor model modify the harness for that specific task, then keeps the lessons for later.

That is a close cousin of the self-improving loops we covered in Weco's AIDE2 and the recursive self-improvement ladder, with one important difference: here the thing that changes is configuration and code around the model, never the model itself.

How Propose, Probe, Compose works

A green dot circling a loop of steps, the recursive loop behind agent harnessing

According to the repository and paper, Harness2 has two connected recursion loops.

Task-level recursion improves the harness for the task in front of it, using a contrastive Propose, Probe, Compose loop that needs no ground-truth verifier:

1. Reference. Run the initial harness once to see how it behaves.
2. Propose. The system suggests a general improvement (better tool use, say) and a task-specific one (a more suitable checking procedure).
3. Probe. Both candidates are executed on the same task with the same executor model and environment.
4. Compose. A revised harness is assembled from the behavioral differences the probes revealed, then executed.

The lack of a verifier is the point. Real professional tasks rarely come with an automatic grader, so the loop learns by contrasting behavior rather than checking against a known answer. The flip side is that contrast is not correctness: two runs can share the same misunderstanding and agree with each other.

Harnessing-level recursion is the memory. A persistent improvement harness keeps adopted harnesses and evidence-supported lessons, including an experience file, to guide future proposals. Each new task still starts from the common base harness, so the system does not silently accumulate every edit ever made. If reflection finds too little evidence, it can add nothing.

The eight editable parts

The repository lists eight components the editor can change: the system prompt, guardrails, memory, tool guidance, subagents, skills, scripts and plugins. Scale is controlled by the --k recursion budget, and --mode parallel explores wider while --mode sequential refines deeper.

One design consequence is worth stating plainly. A guardrails file is one of the things the editor may rewrite, so a written rule in the harness is not a security boundary. Keep real authority (credentials, network access, file permissions) outside the editable harness.

What do the +11.5, +4.5 and +11.8 numbers mean?

Blocks of different heights beside a ruler, benchmark gains reported for WorkBuddy-Bench

The README and abstract report that a single improvement step lifts GLM-5 and Gemini 3.5 Flash above their base harnesses across three benchmarks and four model-harness configurations, with further gains as the task-level budget grows. The maxima are:

A third-party review of the paper by the consultancy Wavect reads the tables more closely. It reports the WorkBuddy-Bench maximum as GLM-5 under OpenCode moving from 64.2 to 75.7, and a smaller 72.4 to 77.5 for Gemini 3.5 Flash. It also notes that the JobBench maximum comes from a different configuration, and that the main experiment used a separate editor model (Claude Opus 4.8, per Wavect) to rewrite the harness, so the executor was not editing itself. We have not re-run these experiments, so treat the per-row figures as Wavect's reading of the paper, and check the paper's tables before quoting them.

The practical reading is narrow but useful. The result shows that changing how an existing model works can raise scores on professional-style tasks. It does not tell you your production acceptance rate, your cost per task, or how much human review remains. Do not add maxima from different rows into an imaginary best case.

What does it cost to run?

The code is free. The runs are not. For parallel recursion the design involves k reference executions, k general probes, k task-specific probes and k composed-harness executions, which works out to roughly four executor rollouts at k=1 and twenty at k=5. That count is derived from the algorithm as described, not a measured invoice. Editor calls, reflection and judging add more.

The paper counts tokens spent before delivery, execution plus improvement, and argues the quality-per-compute trade-off is favorable among the configurations it compares. A benchmark token count is still not a business case. If you evaluate Harness2, compare cost per independently accepted deliverable for a fixed harness versus Harness2, counting executor, editor, grading, infrastructure and human review once each.

This is the same economics question raised in our write-up of the AI verification tax: a system that spends more compute to produce better output only pays off if the checking and rework you avoid is worth more than the extra spend.

How to try it safely

Requirements per the README: Linux, Python 3.12 and uv. Model-backed runs also need Node.js 20 or newer and the Google Cloud CLI, and individual benchmarks add tools (LAB needs Pandoc and Poppler, WorkBuddy-Bench needs Docker).

Start with the credential-free deterministic demo:

harness2-demo --output runs/demo --k 2

Then, if you want a model-backed run, the documented LAB flow is harness2-setup lab, harness2-check, then harness2 --bench lab --k 1 --mode parallel, followed by harness2-judge and harness2-report. A --dry-run flag previews task selection without model calls. Judging and reporting must use the same benchmark, executor, subset, --k, --mode and seed as the refinement run. Results land in runs/, and rerunning resumes, so use a fresh HARNESS2_RUNS_DIR when you change models or task selection.

The warnings you should not skip

• Executor network access is unrestricted.
• Codex runs with its sandbox disabled.
• Public benchmark rubrics may be reachable online, so restrict the network before evaluating if you care about leakage.
• The README states it is not an officially supported Google product.

For any run that touches real data, use an isolated VM or container with throwaway credentials. The same logic applies to every coding agent that executes generated code; our guides to OpenCode versus Claude Code token overhead and running open models in OpenCode cover the executor side. If you want to block risky actions rather than hope the harness behaves, AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions.

Why this matters for builders

Three takeaways stand out.

Harness quality is now a measurable lever. Gains of several points on professional benchmarks without touching weights are a strong argument that prompt, tool and skill design deserves the same rigor as model choice. LangChain's leaner Deep Agents harness and jcode's memory-focused harness point the same direction from the product side.

Cheap models may close more of the gap. A frozen smaller executor with a task-tuned harness is an attractive trade if editor spend is amortized across many similar tasks, though the paper does not claim this for your workload.

Self-editing configuration needs outside guardrails. Anything an agent can rewrite, it can rewrite wrongly. Permissions, secrets and network policy belong in infrastructure the editor cannot touch.

Claimed versus verified

Details reflect the repository and paper as of October 21, 2026; version numbers, flags and results may change.

Related reading

• Top 10 open and closed agent harnesses
• Agent harness tier list and the viral reaction
• Weco AIDE2 and the recursive self-improvement ladder
• LangChain Deep Agents 0.7 and the leaner harness
• jcode: swarm, memory and agent harness performance
• The AI verification tax
• Claude Code vs OpenCode token overhead