Self-improving agent harnesses: RRSI and Harness²
Two Google Cloud AI Research papers, explained together · 100 level · October 2026
What these papers are about
An LLM agent is a model plus a harness. The harness holds everything outside the model's weights: the system prompt, standing rules, memory files, skills, helper scripts, tool instructions, and the loop that decides when the agent plans, acts, checks its work, or stops. Both papers show the same model gaining more than ten points on some benchmarks from harness changes alone.
Most teams tune a harness by hand: an engineer reads failed runs and rewrites prompts. These two papers give that job to an AI. An editor model reads how the agent did, rewrites harness files, tests the edits, and keeps the ones that help. The model's weights never change. When the system's own output shapes its next round of changes, researchers call it recursive self-improvement (RSI).
The harness
The files around a frozen model: prompts, rules, memory, skills, scripts, tool guidance and the control loop. Every harness edit is a diff to these files.
RRSI, September 2026
Regularized Recursive Self-Improvement. Tunes one harness on practice tasks before deployment and adds limits so the tuning cannot memorize those tasks.
Harness², October 2026
Recursive Agent Harnessing for an Open World. Improves the harness live, one task at a time, with no answer key, and saves what it learns for the next task.
The core idea: one loop, two problems
Both papers run the same loop. An editor model reads the agent's past runs, drafts changes to the harness, runs the agent again with each change, and keeps the changes that look like improvements. The updated harness then produces the runs the editor reads next round. That feedback is what makes the loop recursive.
The loop needs a signal that says which edits helped, and the two papers differ on where that signal comes from. RRSI has a grader and worries that the loop will learn to please it. Harness² has no grader at all, so it judges edits by comparing how the agent behaved with and without them.
RRSI: tuning on practice tasks without memorizing them
RRSI starts from a fixed set of practice tasks with a grader, such as unit tests or a judge model with a rubric. The loop runs 20 to 40 rounds over those same tasks. Each round, the editor proposes candidate harnesses, the agent runs each one on the practice set, and the top scorer becomes the new harness.
Scoring against the same tasks every round invites overfitting. A student who drills one practice exam can ace it and still fail the real test, and the editor does the same thing: it learns what this grader rewards and what these documents look like. The authors name three ways it happens: edits that encode benchmark details, edits that win on run-to-run noise, and edits that add machinery and token cost with no better method underneath.
RRSI leaves every harness file open to editing and limits how the search moves through them. The authors borrow the names from regularization in machine learning:
| Brake | What it does | ML idea it borrows |
|---|---|---|
| Edit budget | Early rounds may bundle 3 or 4 edits. The budget shrinks to 1 by the last round, so every late gain traces to one change. | L0: cap how many things change |
| Leak critic | A model reads each diff before it runs and rejects edits that name tasks, entities, answers, or benchmark-specific logic. | Keep test data out of training |
| Noise floor | RRSI first measures how much the unchanged harness's score wobbles between runs. A gain smaller than the wobble earns no credit, and no candidate may score below the best so far minus the wobble. | Reusable holdout sets |
| Cost cap | A candidate that spends more tokens must show a bigger gain. On coding tasks, each extra solved task buys 25 percent more tokens on top of a 10 percent base allowance. | L2: shrink total size |
| Pruning | A component that produced no gain over the last four or five rounds goes on a deletion list for the editor. | L1: delete what does not pay |
| Exploration | When progress stalls, the editor must spend part of its budget on components it has not touched yet. | Entropy bonus |
RRSI also logs every tested edit with its hypothesis and result, so the editor stops retrying ideas that already failed. The authors call the L0, L1 and L2 labels analogies. RRSI does not optimize those penalties.
What happened
The authors tuned harnesses in three areas: coding, legal and office work, and engineering design. They then ran each harness unchanged on benchmarks the loop never saw. Claude Opus 4.8 served as the agent's model and as the editor. In the office-work area, tuned on Harvey's legal benchmark (LAB):
| Method | LAB practice set | Unseen benchmarks, average |
|---|---|---|
| Starting harness | 89.4 | 39.7 |
| Meta-Harness | 93.0 | 40.6 |
| HarnessX | 91.8 | 39.7 |
| TTHE | 91.1 | 38.0 |
| AHE | 90.7 | 39.2 |
| RRSI | 90.5 | 43.6 |
Unseen average covers JobBench, GDPval and APEX-Agents, from the paper's Table 1.
RRSI posted the smallest practice-set gain of any tuned harness and the only unseen gain above one point. Two prior methods ended below the harness they started from. RRSI's harness used 2.42 million tokens per trial, against 3.80 million for the same loop with every brake removed. On engineering tasks, where simulators grade the work with no judge model, the unseen Frontier-Eng benchmark rose 4.3 points. A harness tuned with Gemini 3.5 Flash also helped a smaller model, Gemini 3.1 Flash Lite, that never took part in the search.
What the brakes kept out
The paper puts the final harnesses side by side. Meta-Harness ended with a 730-word standing instruction that restates how the practice set grades work. TTHE carried about 8,500 words of protocol, including 1,000 words that apply only to redlined legal documents, a format the unseen benchmarks never ask for. RRSI accepted 4 of 32 candidates. All four hook into the check the agent already ran before finishing: re-read the deliverable and report what is missing, such as a source value that appears in no written file.
Harness²: improving live, with no answer key
Harness² works in a different setting. Tasks arrive one at a time during real use, nobody has seen them before, and no grader says whether an answer is right. The system may rerun the current task within a budget, but it never goes back to finished tasks. With no practice set to score against, RRSI's approach cannot run here, so Harness² works at two levels.
Level one: fix the harness for this task
- Run once. The agent attempts the task with the starting harness. This run shows how the harness behaves. It says nothing about whether the answer is right.
- Propose two edits. One editor targets how the agent works: planning, tool use, managing its context, checking its own output. A second targets what an expert in the domain knows, such as the sections a legal memo needs or the checks an analyst runs on a budget.
- Probe. The agent runs again with each edited harness, on the same task with the same model and setup. Comparing each new run with the first shows whether the targeted failure went away, stayed, or got worse.
- Compose. A composer reads all the runs and diffs and builds the final harness. It may merge both edits, keep one, revise them, or keep the original. Each decision must point to something it saw in a run.
- Pick an output. With a bigger budget of k candidates, run in parallel or as k rounds in a row, a blind selector compares the finished deliverables against the request and source files and picks one. It does not know which harness made which output.
Level two: get better at fixing
After each task, a reflector reviews the full record and writes down which changes fixed which problems, and under what conditions. It saves the adopted harness and an EXPERIENCE.md note to a library. The next task starts again from the plain harness, but the editors can read the library and copy or adapt its components. The model, the prompts and the procedure stay fixed while the library grows. This second loop explains the name: the system improves the harness, and it also improves the process that improves the harness.
The editor can change eight kinds of file, and each has a different cost:
| Components | When the model sees them | Cost |
|---|---|---|
| System prompt, guardrails, memory, tool guidance | Every call | Tokens on every turn of every run |
| Skills, scripts, subagents | Only when invoked | Nothing until used; a subagent works in its own context and returns a short answer |
| Plugin | Inside the tool loop, on every tool call | No prompt tokens, and the model cannot skip it |
What happened
Gemini 3.5 Flash and GLM-5 did the work, each inside two stock coding agents, OpenCode and Codex. Claude Opus 4.8 did the editing. The benchmarks were WorkBuddy-Bench (code, web and office tasks), JobBench (professional job tasks) and Harvey's LAB.
| Benchmark | Setup | Starting harness | One step | Gain |
|---|---|---|---|---|
| WorkBuddy-Bench, average | GLM-5, OpenCode | 64.2 | 75.7 | +11.5 |
| JobBench | Gemini 3.5 Flash, OpenCode | 31.5 | 36.0 | +4.5 |
| LAB, criteria passed | GLM-5, OpenCode | 59.6 | 71.4 | +11.8 |
Largest one-step gain on each benchmark, from the paper's Tables 1 and 2.
A single improvement step beat the starting harness in all twelve benchmark and setup pairs. Running five candidates in parallel added another 2.6 to 6.7 points. With its improved harness, GLM-5 outscored Gemini 3.5 Flash on its stock harness on WorkBuddy-Bench. Removing the library cost 3.1 points on WorkBuddy-Bench and 1.8 on JobBench, and a library built on JobBench still helped on WorkBuddy-Bench. The gains held when one model did both the work and the editing, for all five models tested, from GLM-5 to Claude Opus 5.
Harness² spends more compute per task than a single run. The paper counts every token, editing included, and both budgets it tested sit on the best cost-for-gain curve among the methods it compared.
Side by side
| RRSI | Harness² | |
|---|---|---|
| When it runs | Before deployment, on a fixed practice set | During deployment, one task at a time |
| Signal for keeping an edit | Scores from a grader | Comparison of runs with and without the edit |
| What it produces | One harness, shipped unchanged | A harness per task and a growing library of lessons |
| Main worry | Overfitting to the practice set | No answer key, and lessons that fail to carry over |
| Compute | Cuts token cost of the final harness | Spends extra runs per task to gain points |
| Editor model | Claude Opus 4.8 | Claude Opus 4.8 |
| Shared benchmarks | JobBench and Harvey's LAB, with Meta-Harness as a baseline in both | |
Where they meet and where they clash
Both found the same habit
The edits that survived in both papers make the agent reopen and check its own deliverable before it stops. RRSI's four accepted edits all sit in the pre-finish check. In a Harness² case study on JobBench, the score rose from 43.1 to 77.8 after the editor added two things: a rule to trace every figure to its source file, and a script that reopens each output file and flags spreadsheet cells a reader would see as blank.
Opposite rules about task facts
The Harness² editor prompt tells the editor to write verified facts about the current workspace into the harness, for example "role X in file A maps to position Y in file B." RRSI's critic rejects any edit that names task entities or values. Each rule fits its setting. Harness² builds a harness for the task in front of it, and when a later task borrows from the library, the prompt tells the editor to treat old facts as guesses and check them again. RRSI ships one harness to benchmarks it never saw, so a task fact in that harness can only overfit.
Meta-Harness gets two verdicts
In RRSI, Meta-Harness posted the best practice score and almost no gain on unseen benchmarks. In Harness², Meta-Harness, tuned offline on separate tasks from the same benchmarks, was the strongest baseline. Both results fit RRSI's argument: offline tuning pays off when test tasks resemble the training tasks and fades when they differ.
Could you combine them?
This part is my reading, not a claim in either paper. The Harness² library grows with every task and nothing prunes it. The authors list consolidating the library as future work. RRSI's pruning rule and leak critic look like the right tools for that job.
Limits and what to check
RRSI needs a practice set
It still tunes against a finite task set and several hand-set limits: the noise band, the edit budget, the cost allowance. The authors fixed these before each run and never tuned them on unseen benchmarks.
The ML names are labels
The authors say so themselves. The brakes are rules of thumb named after L0, L1 and L2, and RRSI optimizes no penalty.
Harness² pays per task
Every task costs extra runs and editor sessions. Parallel runs shorten the wait, but total compute stays the same.
Comparing runs cannot prove correctness
The failure analysis shows the blind selector picking a 55-point output over a 95-point one, and one edit that wrote a wrong rule into every candidate.
Judges grade most benchmarks
LAB, JobBench, GDPval and parts of WorkBuddy-Bench use LLM judges. RRSI's engineering results come from simulators, which makes them the best check against a harness that learns to please the judge.
Further reading
- RRSI: Regularized Recursive Self-Improvement of Agent Harnesses: the full paper, with the brake formulas in Appendix D and the final-harness comparison in Table 9.
- Harness²: Recursive Agent Harnessing for an Open World: the full paper, with every editor, composer and selector prompt in Appendix H.
- google-research/harness2: the Harness² code release.
- harness2.github.io: the Harness² project page.