Google’s Harness² Lets AI Agents Rewrite Themselves Without Retraining — And It’s Open Source
Google Research has released an open-source framework that lets AI agents improve themselves without touching a single model weight. Harness², published under the Apache 2.0 license alongside a paper titled “Harness²: Recursive Agent Harnessing for an Open World” and a project site, does its learning in plain text files: prompts, tools, memory, skills and scripts. The model stays frozen. The scaffolding around it gets rewritten, diffed and versioned like any other artifact in a repository.
That reframes self-improving agents. It is not a training problem. It is an engineering discipline.
What “harness” means, and why the word matters
A harness is everything around a model that lets it act as an agent: the prompts, the tools it can call, its memory, its skills and the orchestration that ties them together. “Harnessing” is the work of optimizing that layer, and it is work most teams already do by hand. An engineer watches an agent fail, rewrites a prompt, adds a tool, patches a script.
That manual loop collapses in what the paper calls an open world, where tasks arrive that nobody anticipated at design time. A human reviewer cannot keep pace with every failure mode across every deployment. Harness² automates the tuning while keeping model weights fixed, which means no fine-tuning, no fresh training data and no GPU cluster reserved for gradient updates.
The framework exposes eight editable components. The first four build the model’s context. Tool guidance and scripts define the tool interface. Subagents handle delegation, and plugins control middleware. Together they cover nearly everything about agent behavior except the model itself, which is precisely the point: the editable surface is large, and all of it is inspectable.
The two loops behind the squared name
The superscript is structural, not decorative. Harness² runs two nested improvement loops.
Loop 1 improves the harness for the current task, and it runs on every task. Loop 2 improves how harnesses get improved across tasks. The improvement harness itself persists between runs, so what the system learns about editing carries forward and shapes the next round of edits. That persistence is the recursive part: the improver is not reset each time, it accumulates.
The learning signal is unusual. Harness² learns from behavioral contrasts between executions, without ground-truth feedback. It does not need the correct answer. It needs the difference between two runs of the same task, and from that contrast it infers which edits helped. After each task an experience reflector stores the adopted harness together with evidence-supported lessons in the persistent improvement harness. The lessons are tied to evidence rather than asserted, which matters for anyone who has watched an agent “learn” something wrong and commit to it.
The compute budget: what k buys you
Loop 1 is tunable through a budget parameter, k, and a mode. Each task costs 4k executor rollouts and 3k improver sessions, per run_sweep.py in the Google Research harness2 repository. Setting --k 3 means 12 rollouts and 9 improver sessions for a single task.
That budget explains the shape of the examples. The LAB benchmark alone contains 1,143 tasks. At those per-task costs, a full sweep is not something you run casually, which is why the shipped examples start with a single task. The compute is spent on execution and editing rather than on training, but it is not free, and teams planning an evaluation should size their k against their budget rather than against their curiosity.
Benchmark results and their caveats
A “model – harness configuration” is one pairing of a base model with a starting harness, meaning the prompt set, tools, memory and orchestration it begins from; the same model can appear in more than one configuration. Google tested GLM-5 and Gemini 3.5 Flash across four such configurations on three benchmarks. A single step, k = 1, improved both models over their base harnesses, with the largest reported gain reaching up to roughly 20 percent over the base harness for at least one configuration. The repository README notes that a larger k brings further gains, with per-configuration numbers in the paper.
Three caveats deserve equal billing with those results. First, the headline improvements are best-case “up to” figures, not averages. Second, LAB’s figure is reported on its Partial score, the fraction of grading criteria passed, rather than on a binary pass rate. Third, and most important, these are Google’s own results on Google’s own benchmarks. Independent reproduction is the next real test, and until it arrives the numbers should be read as a strong signal rather than a settled fact.
The framing also differs from the agentic reinforcement learning line of work. Earlier systems in that space assumed the training framework owns the interaction loop with the environment, an assumption examined in coverage of Agent Lightning v1.0: Microsoft’s 3,500-Line Framework Trains the Agent Harness You Already Deploy. Harness² sidesteps that architecture entirely by leaving weights alone.
Why this matters for teams without weights
Most teams building agents consume models through an API, with no training data, no GPUs and no access to weights, so weight-level self-improvement has always been a spectator sport for them. Harness² keeps every improvement in plain files that can be read, reviewed in a pull request, diffed and rolled back, an auditability a weight update never offers. That places it in the broader pattern of agents becoming configuration rather than code, the same instinct behind Docker Agent: Run AI Agents Like Containers with a Single YAML File, except that Harness² does not just declare the configuration, it edits it.
Try it for free
The project ships a demo that runs both recursion modes with deterministic editors and real Python executions. It makes no model calls, which is why it requires no credentials and costs nothing to run; real sweeps, by contrast, spend API calls on every rollout and improver session.
The setup path is conventional for modern Python tooling. Install uv through Astral’s installer script (the flags -L, -s, -S and -f appear in the instructions, and pip install uv also works), then verify with uv --version. Clone the Google Research harness2 repository into a harness2 folder, create an isolated Python 3.12 environment with uv venv, activate it, and install in editable mode with the [render] extra, which adds openpyxl. Follow the repository README for the exact install invocation.
Open questions worth tracking
Three things remain unresolved.
The first is procedural: the documentation should state the install command plainly, because a small gap in setup is the kind of small thing that stops a reproduction cold.
The second is scale. The published gains come from k = 1. The README promises more from larger k, but the cost curve is steep, and whether the marginal improvement per rollout holds up at k = 5 or k = 10 is an empirical question nobody outside Google has answered yet.
The third is generalization. Self-improving harnesses trained and evaluated on a lab’s own benchmarks may be very good at the tasks the lab chose to measure. Whether the lessons stored by the experience reflector transfer to the messier, unanticipated tasks of a real deployment is the question that decides whether Harness² is a research artifact or a tool teams keep in their stack. The plain-text format at least makes that question testable: every adopted harness can be inspected, and every claim can be checked against a diff.
