The Next Battle Isn’t Better Models; It’s Better Harnesses.
Why Google’s Harness² might be one of the most important agent papers of 2026Most discussions about AI coding agents focus on models. Should you use Claude? Codex? Gemini? A local Qwen model? A larger context window? A better reasoning model?Google Research’s new Harness² paper takes a very…
Annons
Annons
Why Google’s Harness² might be one of the most important agent papers of 2026Most discussions about AI coding agents focus on models. Should you use Claude? Codex? Gemini? A local Qwen model? A larger context window? A better reasoning model?Google Research’s new Harness² paper takes a very different position, which I think we all agree is just confirming what we intrinsically know.Maybe the model isn’t the biggest lever anymore.Today the real opportunity is improving the harness around the model.For developers using Claude Code, Codex, OpenCode, Continue, Cline, Roo, and similar tools, that idea should immediately get your attention.First, what is a harness?The model provides intelligence. The harness orchestrates how that intelligence becomes action.It is tempting to think of a coding agent as a simple pipeline: you ask a question, the model reasons, and an answer appears. In practice, the model sits inside a much larger operating system that decides what context it sees, which tools it can use, how work is delegated, and what checks must pass.That surrounding system is the harness. It includes prompts and instructions, but also skills, subagents, memory, hooks, workflows, tool integrations and guardrails. The model supplies general intelligence; the harness turns that intelligence into behaviour suited to a particular repository, team and task.If you have edited AGENTS.md or CLAUDE.md, created a custom agent, added a skill or hook, connected an MCP server or encoded a workflow, you have already been doing harness engineering. You were not changing the model — you were changing the system that determines how the model works.Harness² makes that distinction actionable. Instead of treating the harness as static configuration maintained only by humans, it treats those components as something that can be proposed, tested, compared, and systematically improved.Once the harness is visible as a system in its own right, the next question becomes unavoidable: why should its improvement remain a manual, one-off activity?That is the step Harness² takes. It moves the optimisation target away from the answer produced on one task and towards the reusable system that shapes answers across many tasks.The key insightHarness² shifts optimisation from producing one result to improving the system behind every future result.A conventional agent is judged by the result it produces now. It may revise its plan, retry a tool call, or ask a subagent for help, but the machinery surrounding the model remains largely unchanged when the task ends.Harness² moves the learning loop up one level. It starts with the current harness, generates candidate changes, exercises those alternatives on tasks and evaluates the outcomes. Promising changes are retained in an improved harness; weak or harmful changes are discarded.The crucial point is that the output is not only a better result. It is a better system for producing results. The improved prompts, skills, workflows, memory and tool guidance can be reused across subsequent tasks rather than disappearing with a single answer.That is the shift shown in the visual: from optimising what the agent says once to optimising how the agent works repeatedly.The mistake most readers will makeRecursion adds workers. Harness² improves the operating system every worker inherits.The obvious reading is that Harness² is about recursion: one agent delegates to subagents, which divide the work and return a result. That may increase throughput or specialisation, but the underlying prompts, tools, memory and guardrails remain fixed.Harness² targets a different layer. It observes outcomes, proposes changes to the harness, tests those alternatives, and retains improvements. The system is not merely adding more workers; it is improving the operating system every worker inherits.That distinction matters because recursion scales execution, while harness improvement scales learning. A subagent can help complete today’s task. A better harness can change how every future task is approached.From one-off fixes to compounding learningManual fixes resolve the incident in front of you. Harness² turns each failure into evidence that can improve the next experiment.A manual response is usually local and disposable: a prompt is edited, a hook is added or a skill is rewritten to address one visible failure. The next problem begins another round of diagnosis and guesswork.Harness² changes the economics of that work. Failures become inputs to a repeatable process that generates alternatives, tests them, compares the evidence and retains what works. The value is not only the winning change; it is the growing body of experience about which harness modifications help, which harm and under what conditions.That is where improvement begins to compound. Each experiment can make the next experiment better informed, while validated changes strengthen the harness inherited by future tasks. The model may remain unchanged, but the system around it becomes progressively more capable, reliable and organisation-specific.Architectural shift — Execution and improvement become separate layersThe execution layer completes today’s task. The improvement layer turns its outcomes into a better harness for tomorrow.The execution layer is the familiar agent runtime: it combines the model with tools, skills, memory and guardrails to complete the task in front of it. The improvement layer has a different job. It studies results and failures, proposes harness changes, tests them, and retains what survives evaluation.Evidence flows up from execution; an improved harness flows back down. Each new task can therefore begin with a system informed by earlier work rather than the same static configuration.Task completion becomes organisational learning. The agent executes, the improver learns, and the harness carries that learning forward.This separation matters because agents operate in an Open World: tools, repositories, APIs, constraints, and workflows change continually. Harness² is an attempt to automate harness improvement across those shifting environments — combinations no human could optimise fully in advance.The dangerous sideOptimise the mutable harness inside the boundary; keep approvals, permissions, sandboxing and audit outside its control.The same mutability that makes Harness² powerful also creates its central risk. Prompts, skills, hooks, scripts, subagents and workflows are not merely instructions; they can change what the agent is able to do.Those components can sit inside the improvement loop, but the security perimeter cannot. Approvals, permissions, sandboxing and audit must remain external constraints: the harness may propose changes within them, but it must not be able to weaken, bypass or remove them.The distinction is practical. Moving tests earlier can be generated, evaluated and retained as a useful improvement. Removing an approval because it slows completion may raise a benchmark score, but it must be rejected by policy before it can enter the harness.Safety cannot be another variable in the search space. Optimise capability inside the boundary; never optimise the boundary away.The harness may evolve. The security perimeter must not.The need for that boundary does not weaken the idea; it clarifies it. Harness² is valuable precisely because it makes the harness explicit enough to separate what may evolve from what must remain fixed.That leads to the paper’s deeper contribution. Once the harness becomes a first-class system — with defined components, measurable outcomes and governed limits — it can become an object of engineering rather than an invisible collection of configuration files.What Google has really documentedThe deeper contribution is not simply a new agent architecture or a set of benchmark gains. It is the recognition that the harness should be treated as a first-class system: something with identifiable components, observable behaviour, measurable outcomes and governed boundaries.Until now, prompts, skills, workflows, memory and agent instructions have often been maintained as scattered configuration. Harness² reframes them as a structured search space. Candidate changes can be generated, evaluated against evidence and either retained or rejected.That reframing introduces a new layer to the agent stack: not merely a model and an agent, but a harness and a system capable of improving that harness. In effect, the harness improver becomes a meta-harness — a governed system that reasons about the system shaping the agent.Once the harness becomes explicit, measurable and mutable, automated harness engineering becomes possible. That may prove more important than any single implementation detail in the paper.Final thoughtsSeen this way, Harness² is less a finished answer than an early demonstration of a new engineering discipline. The important question is no longer whether a particular prompt or workflow performs well, but whether the system around the agent can be represented clearly enough to evaluate, govern and improve.The analogy with metadata and metamodels is useful. Metadata made data describable; a metamodel makes the structure of that description explicit. A meta-harness plays a similar role for agents: it describes and reasons about the harness that shapes their behaviour.That creates a demanding agenda. Teams will need credible evaluations, versioned harness components, traceable evidence, rollback and security boundaries that remain outside the optimisation loop. Improvement without those disciplines would be difficult to trust.If those foundations emerge, the lasting significance of Harness² may be that it helped turn the harness from hidden configuration into a governed system that can learn.SourcesGoogle Research: google-research/harness2Harness²: Recursive Agent Harnessing for an Open WorldThis story is published under the Generative AI publication. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories. Let’s shape the future of AI together!The Next Battle Isn’t Better Models; It’s Better Harnesses. was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.