Google's Harness²: Agents That Rewrite Their Own Harness to Get Better

In October 2026, Google Cloud AI Research and Northwestern University open-sourced Harness² (pronounced "Harness-squared"), a framework that makes agents better without touching the model. The pitch, from the team's own one-liner: "Your agent may get better without a better model." The repo, created on October 6, has already pulled ~16,500 GitHub stars; the paper, arXiv:2610.14224, was posted October 9. The idea is simple to state and significant to absorb: the thing that determines an agent's performance is not the model underneath it, but the harness — the system of prompts, tools, memory, skills, and orchestration wrapped around it — and that harness can be recursively improved by the agent itself, on tasks it has never seen, with no retraining and no ground-truth labels.

This is the cleanest public statement yet of a shift that's been moving through the agent ecosystem all year: the competitive frontier has moved from model quality to harness quality. Most of the 2026 coverage of coding agents has concluded the same thing — the differentiator is no longer which model you call, but the runtime you build around it. Harness² formalizes and automates exactly that: instead of a human hand-tuning the harness for a known task, the system designs a better harness for each new task it encounters, and then learns from the act of designing it. The result, in one step, lifts GLM-5 by 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB's partial pass rate, with frozen weights. Let's break down how it works, what it can and can't do, and why it matters.

What a Harness Is — and What Harnessing Means

The whole framework rests on a vocabulary shift worth internalizing. An LLM by itself is a model: it takes tokens in and produces tokens out. An agent is a model plus everything that lets it act — the execution layer that lets it call tools, inspect files, run code, and keep going across a task. Harness² names the surroundings the harness and the act of optimizing it harnessing:

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.

Harness² exposes eight editable components around the model, grouped by their runtime role:

The important part is that these are the things a team actually has to hand-engineer today. Every serious agent product you've used this year — the coding assistants, the personal agents, the workflow tools — is a bet about what goes in those eight slots. Harness²'s claim is that most of that hand-tuning is, in principle, automatable, and that it can be done online, per task, against tasks that weren't part of the design set. That's the "open world" in the title.

The Two Problems That Make This Hard

Recursive self-improvement — an agent that makes itself better — is an old idea. The hard part is doing it in the real world, and the paper identifies exactly two obstacles. Harness² is structured to solve both.

• No ground-truth verifier. In an open world, the tasks an agent meets are novel at test time. In a lab you have a test suite with known answers; in the open world you do not. A naive improvement loop can't just "check the answer," because there is no answer to check against. This is the same reason self-improving agents have historically been limited to domains with cheap verifiers (code that compiles, math that's right).
• Task-specificity / no generalization. Even when an agent does improve, the improvement tends to be welded to the specific task it was tuned on. It doesn't carry the lesson to the next, different task. So each task starts from scratch, and the whole "improvement" evaporates when the task changes.

How It Works: Two Levels of Recursion

Harness² connects two nested loops of self-improvement. The model weights never change in either. The recursion is entirely in the harness — the code, prompts, and configuration around the model.

Level 1 — Task-level recursion: Propose–Probe–Compose

For a single current task, the agent runs the execution harness to get a baseline behavior. Then a harness editor proposes edits — split into invariant edits (general, "always do this better") and domain edits (specific to this task's field). Those candidate edits are probed: each is executed on the same task, and the system observes how the behavior changes. Finally, a harness composer looks at the behavioral contrasts between executions — what got better or worse when each edit was in place — and composes a single refined harness from the best combination. The key word is contrastive: the agent doesn't need to know the correct answer; it only needs to see how different harness edits changed its own behavior on the same input. That contrast is the signal that replaces the missing ground-truth verifier.

You scale this two ways, and the framework ships both:

• Parallel recursion — explore wide: probe k general and k domain-specific candidate harnesses, then compose k candidates from the shared evidence. Breadth of search.
• Sequential recursion — refine deep: carry the refined harness and its accumulated evidence through k successive Propose–Probe–Compose steps. Depth of refinement.

Level 2 — Harnessing-level recursion: the improvement harness

After each task, a second loop runs. An experience reflector reflects on what the task-level step did and updates a persistent improvement harness — a library of adopted harnesses plus evidence-supported lessons from the task. That improvement harness then guides how the agent refines its harness on the next, different task. This is the loop that solves the generalization problem: the agent doesn't just get better at task N; it gets better at being the thing that makes itself better. The improvement mechanism itself becomes a source of learning, which is the "squared" in Harness² — you harness the agent, and then you harness its self-improvement.

The Results

The paper evaluates Harness² across three professional benchmarks — JobBench (professional work), LAB (legal work), and WorkBuddy-Bench (office, web, and code tasks) — and four model–harness configurations. The headline: a single Harness² step (i.e., one Propose–Probe–Compose pass, k=1) improves the models over their base harnesses, with further gains as the task-level recursion budget grows.

Two things about these numbers matter more than the numbers themselves. First, the models are not frontier — the paper uses GLM-5 and Gemini 3.5 Flash, i.e., strong mid-tier models. The gains are being bought entirely by harness quality, not model quality, which is the whole point of the exercise. Second, the effect scales with the recursion budget: more Propose–Probe–Compose steps (higher k, or more parallel candidates) buy more points, so this is a compute tradeoff you can dial, not a one-shot trick. A single step already beats the base harness; the curve keeps climbing.

How it compares to other harness methods

The honest framing comes from the comparison tables that have circulated with the release. Harness² sits in a field of "harness" methods, and its differentiator is the combination of features, not any single one:

The columns that separate Harness² are the last two practical ones: it doesn't need a held-out training set (so it can work on a fresh task with no prior examples of it), and it carries lessons across tasks through the improvement harness. That's the open-world combination, and it's why this is getting attention rather than being filed under yet another harness paper.

The Practical Reality: What It Is (and Isn't) Today

Strip the research framing and be clear about what you actually get if you clone the repo today, because the gap between the paper and the install matters.

• It's a research framework, not a product. The README's final disclaimer is explicit: "This is not an officially supported Google product," and it's not in the Google vulnerability rewards program. It's a lab tool for people who want to study or run recursive harnessing, not a turnkey service you point at your business.
• The install is real but bounded. It needs Linux, Python 3.12, and uv. There is a credential-free local demo (harness2-demo) that runs both recursion modes with deterministic editors and real Python executions — good for understanding the loop without spending a dime. But the model-backed benchmarks need Node.js 20+, the Google Cloud CLI, Vertex AI credentials, and per-benchmark dependencies (LAB wants Pandoc/Poppler; WorkBuddy wants Docker). Model runs incur API costs, and the team explicitly tells you to start with a small task selection.
• The executors are OpenCode and Codex. Rather than implementing an agent runtime, Harness² drives existing coding-agent executors — OpenCode by default, Codex via --substrate cx. So the harness is being optimized around real, production-grade agent loops, which is part of why the results transfer.
• The web-access caveat is a live one. The executors' network access is unrestricted by default (Codex runs with its sandbox disabled), and the team warns that public benchmark rubrics may be findable online. Before evaluating, you're supposed to configure network restrictions so the agent can't find the benchmark answers or grading criteria. That's a real methodological hazard for any agent evaluation, and the authors flag it rather than hide it — a point in the repo's favor.
• It's young. Two named contributors, created mid-October, and the results are the authors' own (independent replication is still thin). The code-health signals on the repo are "good" but it's a fast-moving, two-week-old codebase.

Why This Matters: The Harness Is the New Frontier

Set the single framework aside and Harness² is a marker on a trend that the rest of the 2026 agent ecosystem has been converging on from the opposite direction. The industry has spent the last year discovering, empirically, that the competitive differentiator in agents is not the model. The evidence is everywhere: "memory is the new moat" analyses, harness-engineering guides that describe a production harness as five layers (tool orchestration, verification loops, context and memory, guardrails, observability), empirical studies of dozens of public agent systems finding the same recurring architectural dimensions, and vendor docs (Anthropic's agent-harness-design patterns, Claude Code's dynamic workflows) that treat harness design as a first-class discipline. The model is increasingly a commodity input; the harness is the product.

Harness²'s contribution is to point a recursive loop at exactly that layer and ask the question the industry has been asking by hand: can the system design a better harness for a task it hasn't seen, and get better at doing so over time? The answer, in the paper's terms, is yes — with measurable gains, on frozen mid-tier models, without labels. If that holds up under independent replication, the strategic implications are significant:

• Model choice becomes less decisive. A strong harness on a mid-tier model can beat a weaker harness on a frontier model. That shifts leverage toward the team that engineers the runtime, not the team with the API key to the best model. It's the same dynamic behind the "vibe-coded" agent toolkits and the memory-layer startups — the value is migrating out of the model and into the system around it.
• Self-improvement moves from lab to deployment. The traditional framing of recursive self-improvement was about a system that eventually rewrites its own weights — a far-off, safety-laden horizon. Harness² demonstrates a nearer, safer, more useful form: improvement that stays outside the weights, in inspectable, versionable, revertible configuration. The agent gets better, but every change is a diff in a prompt file or a tool definition, not an opaque update to billions of parameters. That's a meaningfully different risk profile, and it's why this is deployable today rather than hypothetical.
• The "harnessing-level" loop is the real idea. The deeper claim isn't "agents can tune their harness for a task." It's that the improvement process itself can be a learning object — a persistent library of evidence-supported lessons that makes the agent better at adapting to the next task. If that meta-loop compounds, you have an agent whose marginal cost of handling a new domain drops over its lifetime without a single weight update. That is the actual research bet, and it's the part worth watching for replication.

Bottom Line

Harness² is the most concrete public statement yet of where agent engineering is actually heading: the model is the engine, but the harness is the vehicle, and the vehicle can be improved by the car itself. The framework is clean, the results are real (11+ point gains on professional work with frozen weights, in a single step, scaling with more recursion), and the two-loop design — tune the harness for this task, then tune the harnessing for the next — is a genuinely new shape for self-improvement that keeps every change inspectable and reversible because nothing ever touches the weights. It is not a product, the results are the authors' own, and the community's critiques (own the harness, not just the loop; is this different from what we already do by hand?) are fair. But the direction it points is the one the rest of the industry has been circling: as models commoditize, the system around them becomes the product, and the question that matters is no longer "which model is smartest" but "can this agent get better at its own job, on tasks it's never seen, without anyone retraining anything." Harness² says yes, and shows the loop. That's enough to matter — and enough to keep watching.

References

• Google Research — Harness² GitHub repository (code, README, eight-component model) [GitHub]
• Xu, Chen, CuiZhu, Dalvi Mishra, Ming, Yu, Han, Lee, Pfister — "Harness²: Recursive Agent Harnessing for an Open World," arXiv:2610.14224 [arXiv]
• Harness² project website [harness2.github.io]
• MarkTechPost — "Google Open-Sources Harness2, a Recursive Agent Harnessing Framework" (incl. comparison table) [MarkTechPost]
• Philipp Schmid — Recursive Self-Improvement (harness vs. weight updates) [philschmid.de]
• Hacker News — "Harness2 by Google Research" discussion [Hacker News]
• Upsolve — Self-Improving Agents: How AI Gets Better Without Retraining [Upsolve]
• AgentConn — Memory Is the New Moat in Coding Agents [AgentConn]
• Faros — Harness Engineering: A Guide to AI Coding Agents (five-layer harness) [Faros]
• ai-boost — awesome-harness-engineering (empirical study of 70 public agent systems) [GitHub]
• Related — HELIX: Recursive Self-Improvement through Multi-Agent Self-Supervision, arXiv:2610.12176 [arXiv]

Capabilities, the two-loop mechanism, benchmark results, and install details verified against the Harness² repository README and arXiv:2610.14224 (submitted Oct 9, 2026); comparative framing from trade coverage as of October 21, 2026. Benchmark numbers are the authors' reported results; independent replication is still limited. The repository is young (~two weeks old at publication) and a research tool, not a supported product.