Google Open-Sourced Harness2: Agents That Rewrite Their Own Harness With No Labels

Google published Harness2 on 9 October 2026 and released the code under the Apache 2.0 licence. The paper is called Harness2: Recursive Agent Harnessing for an Open World, and the repository lives at google-research/harness2. The claim underneath it is the interesting part: an agent can get better at a task without a better model, and without a set of labelled examples telling it what better means.

Harness2 changes the code and files around a frozen model. The model weights never move. What moves is the harness, meaning the prompts, tools, memory, skills and orchestration that turn a model into an agent, and the framework edits those files between and during tasks.

This article covers what Harness2 is, what the eight editable components are, the open-world problem it was built to survive, how the two levels of recursion work, what the published results show, and the operational warning Google attaches to the repository. Every figure and quotation comes from the paper and the repository, both of which are public and linked at the end.

What Google actually released

Harness2 is a framework, not a model. The repository is explicit about the framing: a harness is the system around a model that enables it to act as an agent, and harnessing is the process of optimising that system.

Three things follow from that definition, and they explain why this release matters beyond a single research paper.

No weights are trained. Harness2 improves the scaffolding instead, which means its gains are orthogonal to model releases. A team that adopts Harness2 does not need a new checkpoint to see a change in behaviour.

It is built for tasks the harness designer never saw. The paper's title says an open world, and the authors define that setting precisely: agents encounter tasks unseen during harness design, arrive at test time, and carry no ground-truth verifier that could reliably guide an online edit.

It is research software, and the repository says so. The README carries a disclaimer that Harness2 is not an officially supported Google product and that the project is not eligible for the Google Open Source Software Vulnerability Rewards Program. Apache 2.0 applies to the framework, while third-party code, benchmarks and datasets keep their upstream licences.

The practical footprint is modest. Harness2 targets Linux with Python 3.12 and uv. A local demo runs both recursion modes with deterministic editors and real Python executions, without model credentials, which means the recursion mechanics can be inspected before anyone spends money on inference. Model-backed benchmark runs need Node.js 20 or later, the Google Cloud CLI, a Vertex AI project, and per-benchmark dependencies: Pandoc and Poppler for the legal benchmark, Docker for the office benchmark.

The eight editable components

Harness2 exposes eight components, and each one is mounted as a file in the runtime. That choice is the reason Harness2 is inspectable rather than mysterious: editing a harness means editing files, which means the diff can be read, reviewed and reverted.

Component	Role in the runtime
System prompt	Constructs context and sets the agent's operating instructions
Guardrails	Constrains what the agent may do
Memory	Holds state that the agent carries across steps
Tool guidance	Describes and shapes tool use
Subagents	Orchestrates delegated work
Skills	Packages reusable procedures
Scripts	Defines scripted actions available to the tool loop
Plugins, described as middleware	Controls behaviour inside the tool loop

The paper states that the framework adopts the file-level decomposition from earlier Agentic Harness Engineering work and extends it by one component to reach eight. Two details are worth noting for anyone who has built agents without naming the parts. First, the components map onto distinct failure modes: context construction, the tool interface, delegation, and behaviour inside the tool loop. Second, because they are files, a harness edit is a reviewable artefact rather than a prompt tweak lost in a config string.

If you have ever debugged an agent by pasting instructions into a system prompt and hoping, this table is the argument for changing the approach. Naming the components is what makes them testable one at a time.

The problem: no ground truth in an open world

Most self-improvement methods assume something the open world does not provide. The paper describes two connected challenges, and both are familiar to anyone who has tried to evaluate an agent without labels.

There is no reliable verifier. Tasks typically lack ground-truth labels or trustworthy verifiers, and existing methods lean on proxy signals, assumed correct answers, or pairwise judgements of outputs. Using imperfect execution evidence to guide a change safely is the hard part, because a harness edit that looks better on one run can be worse on the next.

Improvement does not transfer by itself. Improving the harness for the current task does not automatically improve how the next task gets refined. Edits tailored to one task often break when requirements change, and directly inheriting a highly tailored harness can add noise as the task distribution shifts. The authors' phrasing is that the improvement process itself has to become a source of learning.

That second point is where Harness2 departs from a wrapper that simply retries a task with different instructions. The paper distinguishes two objects: an execution harness that runs the current task, and a continual improvement harness that governs how execution harnesses get revised. Harness2 updates both, at different times and at different levels.

The terminology also matters for reading the research. The paper situates itself against recursive self-improvement, the broader idea of a system making persistent changes to itself that then shape future improvements. Previous work in that space changed model weights, improvement programs, or agent code. Harness2 changes the harness, and it keeps the weights frozen, which is what makes the approach compatible with a model you cannot retrain.

How the two levels of recursion work

The framework runs two connected loops, and they are worth separating carefully because the paper's results depend on both.

Task-level recursion: propose, probe, compose

For a single task, Harness2 runs a contrastive step with three stages.

Propose. The agent first executes the task with the current harness to produce a reference execution. The paper is careful about what that reveals: the reference shows how the harness behaves, not whether its deliverable is correct. The framework then proposes two candidates. The invariant candidate targets agentic deficiencies that tend to recur across domains, such as planning, tool use, context management or delegation. The domain-specific candidate targets the knowledge, procedures and constraints of the current domain. Both candidates are executable harnesses produced by editing component files.

Probe. Each candidate runs on the same task under matched model and environment configuration. Comparing its trajectory and deliverable against the reference produces a behavioural contrast, which is evidence about whether the edit addressed the targeted deficiency, changed nothing relevant, or introduced a regression. The paper states plainly that these contrasts inform composition rather than verify correctness, because execution stochasticity and shared model biases limit how reliable the evidence can be.

Compose. The framework reads the reference, the candidates, their diffs and the task-local evidence, then builds a successor harness. Composition is selective: it can merge supported changes, revise conflicting edits, adopt one candidate, or keep the current harness. Each decision is tied to a concrete observation rather than an assumed score gain, and the composed harness is executed so the step ends with a real result rather than a proposal. The decisions and their evidence are recorded in a step record.

That contrastive structure is the paper's answer to the missing verifier. Since nothing can say whether an answer is right, the framework compares executions and keeps only what behaviour supports.

Scaling the search: parallel and sequential

Task-level recursion scales in two directions, and the repository describes the tradeoff in one line: parallel recursion explores wider, sequential recursion refines deeper.

• With parallel recursion, the framework probes several general candidates and several domain-specific candidates, then composes successor harnesses from their shared evidence.
• With sequential recursion, the refined harness and the accumulated evidence carry into the next propose, probe and compose step.

The budget is a single flag. A value of one runs a single contrastive step, and larger values scale either mode. That makes the compute cost of improvement explicit at the command line, which is a refreshing change from frameworks where the improvement loop is hidden behind a configuration file.

Harnessing-level recursion: the library of lessons

After each task, the second loop runs. Harness2 keeps a persistent improvement harness and updates it with the harnesses that were adopted plus the lessons that the evidence supports. That library then guides proposals and composition on future tasks.

One design choice here is worth stating because it is counterintuitive. Each new task still starts from the base execution harness rather than inheriting the previous task's heavily tailored one. What carries forward is the library and the lessons about when and why certain edits worked. The paper presents this as the fix for the generalisation problem: carry the knowledge, not the artefact.

What the published results show

The evaluation covers three professional benchmarks and four model and harness configurations, and a single step improved every configuration on every benchmark. The headline figures, from the abstract and reproduced in the repository, are gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on the legal benchmark's partial pass rate.

The paper adds two findings that matter more than the peak number.

The budget keeps paying. Increasing the task-level recursion budget produced further gains, and parallel recursion added up to 3.9 points on WorkBuddy-Bench, 4.2 points on JobBench and 6.7 percentage points on the legal benchmark's partial pass rate. The repository summarises the same result as gains increasing with the budget rather than flattening.

The library transfers. A library accumulated with a larger recursion budget supported stronger subsequent harness edits even without additional probing, and a library built on the job benchmark improved performance on the work benchmark. That is the clearest evidence in the release for the claim that the improvement process itself is the reusable asset, and it is the finding to watch if you are deciding whether this is a research curiosity or a technique you can adopt.

The paper also studies a setting worth flagging: configurations where the same model serves as both executor and editor. Independence between the model doing the work and the model judging the edit is a safety property people assume, and it is useful that the authors measured what happens when it is absent.

The supported combinations are narrow and explicit, which helps with evaluation planning. Harness2 ships with parallel and sequential recursion, two executors, and three benchmarks: JobBench for professional work, the legal agent benchmark for legal work, and WorkBuddy-Bench for office, web and code tasks, with the last one offering office, web and code subsets.

What to do with it, and the warning Google attaches

The most useful part of the repository is not the install guide. It is one paragraph about network access, and it deserves to be quoted rather than paraphrased.

Executor network access is unrestricted, and Codex runs with its sandbox disabled. The README then adds that public benchmark rubrics may be accessible online, and instructs users to configure network restrictions before evaluation to prevent access to benchmark answers and grading criteria.

Read that against the rest of the release and the shape of the adoption problem appears. Harness2 rewrites its own harness in pursuit of better behaviour, and it runs with unrestricted network access and no ground-truth verifier, which is precisely the setting where an agent can improve its score by reaching material it should not see. The authors flag it, which is to their credit, and the warning is also a design statement about what Harness2 is not: it is not a safety mechanism. Enforcement has to come from outside, which is the same conclusion Nvidia reached with the runtime described in the OpenShell article: the boundary cannot depend on the agent respecting it.

Four practices follow for anyone testing Harness2 on their own tasks.

Treat the harness as files under review, not as configuration. Because every component is mounted as a file, an edit can be diffed and kept in version control. That turns an improvement step into a reviewable change rather than an unexplained behaviour shift.

Budget extra executions per task, then measure steps as well as scores. A contrastive step runs the reference, the candidates and the composed harness, so improvement multiplies the number of executions. Any adoption case that ignores that will look better than it is on a per-task cost basis.

Keep a lessons library deliberately. The transfer result is the interesting one, and a library only accumulates if the runs and their reflection notes are preserved rather than discarded after each experiment. The repository keeps results under a runs directory, including adopted harnesses and reflection notes, which makes that practice easier.

Reproduce with the same settings or not at all. The repository requires judging and reporting to use the same benchmark, executor, subset, recursion budget, mode and seed as the refinement run, and it warns against mixing runs when models or task selections change. That is an unusually honest reproducibility constraint for a self-improving system, and it exists because the improvement path depends on the execution evidence.

For readers comparing approaches, the framing helps. Reinforcement learning changes behaviour by training weights, which is the subject of our explanation of long-horizon RL for agents. Harness2 changes behaviour by editing the scaffolding, which is closer to the control-loop argument in the agentic meta-reasoning paper, where Meta's researchers improved how an agent directs its own work without touching the model either. Both sit under the broader architecture question we covered in the guide to production-grade agentic systems, and the platform adoption side is in our survey of agent orchestration platforms.

The honest summary for a small team: Harness2 is worth a local demo this week if you already run agents on real tasks, because the demo costs nothing but time, and the component-file model is a good idea regardless of whether the full recursion works for you.

Where the numbers stop

• The gains are the authors' own, measured on their benchmarks with their base harnesses. I did not reproduce them, and I did not find an independent replication in the material available to me.
• In this run I read the paper's abstract, introduction and method sections, plus the repository documentation. I did not read the experimental tables, the analysis section or the limitations section, so the per-configuration figures behind the headline numbers are not repeated here, and neither are the authors' own stated limitations.
• The abstract describes gains as measured across three professional benchmarks and four model and harness configurations, and it reports improvements relative to each base harness rather than absolute superiority over unrelated systems. A framework that improves a weak base harness is not automatically better than a strong one.
• The contrastive step is explicitly not a correctness check. The paper states that behavioural contrasts inform composition rather than verifying outputs, because execution stochasticity and shared model biases limit reliability. Any reading that treats a Harness2 gain as evidence of correctness is reading beyond the source.
• The repository is versioned research software with a disclaimer that it is not an officially supported Google product. Treat the interface and the defaults as things that will change.

FAQ

What is Harness2?

Harness2 is a plug-and-play framework for recursive agent harnessing, released by Google with a paper and an Apache 2.0 licensed repository. It improves the harness around a frozen model, meaning the prompts, guardrails, memory, skills, tool guidance, scripts, subagents and middleware, without training model weights. It runs two levels of recursion: a task-level step that refines the harness for the current task, and a harnessing-level step that keeps lessons to guide future refinements.

How does it improve an agent without labels?

By comparing executions instead of scoring answers. For each task it produces a reference execution with the current harness, proposes two candidate harnesses, one aimed at general agentic weaknesses and one at the current domain, runs each candidate on the same task under matched conditions, and composes a successor harness from the behavioural contrasts. Because the evidence is comparative, none of it depends on knowing the correct answer, though the paper notes this also means it verifies behaviour rather than correctness.

Is it ready for production?

The repository answers that itself: Harness2 is not an officially supported Google product. It is Linux and Python 3.12 with uv, a local demo runs both recursion modes without model credentials, and model-backed runs need a Vertex AI project with per-benchmark dependencies. The more important production question is the sandbox one, since the README states that executor network access is unrestricted and that Codex runs with its sandbox disabled, and instructs users to restrict network access before evaluation.

The short version

Harness2 is Google's Apache 2.0 framework for recursive agent harnessing, released on 9 October 2026 with a paper on arXiv. It edits the eight files that make up an agent harness, from system prompt and guardrails to subagents and middleware, while leaving model weights frozen. Task-level recursion refines the harness for the current task using a contrastive propose, probe and compose step that needs no ground truth, and it scales either wider with parallel recursion or deeper with sequential recursion. Harnessing-level recursion keeps the adopted harnesses and the lessons behind them, so future proposals start from accumulated experience, and the paper reports that a library built on one benchmark improved results on another. A single step lifted every tested configuration on every benchmark, with gains up to 11.5 points, and higher budgets produced further gains. The caveats matter as much as the results: the contrasts verify behaviour rather than correctness, the numbers are the authors' own, and Google's own README warns that executor network access is unrestricted, so anyone evaluating it should restrict the network first.

Sources

• Google Cloud AI Research and Northwestern University, Harness2: Recursive Agent Harnessing for an Open World, arXiv 2610.14224, 9 October 2026, published under CC BY 4.0. The abstract and method sections are the source for the definition of harnessing, the open-world challenges, the contrastive propose, probe and compose step, the eight components and the headline gains: https://arxiv.org/abs/2610.14224
• Google Research, the Harness2 repository, Apache 2.0. The source for the component list, the install and run instructions, the parallel and sequential recursion flags, the benchmark support, the reproducibility requirements, the network access warning and the disclaimer: https://github.com/google-research/harness2