The paper
Harness^2: Recursive Agent Harnessing for an Open World, by Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee and Tomas Pfister, of Northwestern University and Google Cloud AI Research. Submitted to arXiv on 9 October 2026. Code: google-research/harness2, Apache 2.0.
The finding in plain English
An agent's results depend on the model and on the harness around it: the system prompt, guardrails, memory, skills, tool guidance, scripts, subagents and middleware plugins. You can change all of these without retraining anything.
Most of us tune the harness by hand, one task at a time. The paper names two problems with that in real deployments. New tasks rarely come with a checker that confirms the output is correct, and an edit that helped on one task often fails on the next.
Harness^2 improves the harness for each new task by testing candidate edits against a reference run of the same task, and keeps a library of which edits worked and why. Model weights stay frozen. In the authors' tests, a single refinement step improved every configuration, with gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench and 11.8 percentage points on the partial pass rate of LAB, a legal benchmark.
How they did it
Task level: Propose, Probe, Compose.
Propose an invariant edit (general agent behaviour) and a domain-specific edit.
Probe each edit by running the task and comparing behaviour against a reference run under the current harness.
Compose a new harness from only the changes the observed behavioural differences support.
The reference run shows how the harness behaves; it does not judge whether the deliverable is correct. That is why no ground-truth verifier is needed.
Harnessing level: the experience library. After each task, the adopted harness and the lessons about when and why it worked go into a library that guides edits on later tasks.
The search scales in parallel or sequential mode: probe K general and K domain-specific candidates, or chain K refinement steps.
Tests used Gemini 3.5 Flash and GLM-5 on the OpenCode and Codex substrates, against three baselines: ReasoningBank, Harness Scaling and Meta-Harness (optimised offline on separate training tasks). Results are the mean of three runs.
Why it matters
The weaker open model gained most. GLM-5 on OpenCode rose from 64.2 to 75.7 on WorkBuddy-Bench after one step.
It beat an offline method. For GLM-5 on OpenCode, one step scored 75.7 on WorkBuddy-Bench against 69.7 for Meta-Harness. On LAB, Harness^2 led in every configuration except Gemini on Codex, where Meta-Harness led.
More candidates add further gains. Scores rose as the number of candidates or refinement steps increased, in both parallel and sequential mode.
The ablations show which parts carry the weight. For Gemini on OpenCode, removing scoping, the split between general and domain-specific edits, dropped JobBench from 36.0 to 32.3.
This connects to a question we covered in Do AI Models Actually Learn?: the system improves across tasks while the model stays frozen, because what it learns is stored in the harness and the library.
Caveats
Scoring relies largely on LLM judges. WorkBuddy-Bench mixes deterministic checks with judge items scored by Gemini 3.5 Flash. JobBench is scored against a rubric by Claude Opus 4.8, and LAB per criterion by Claude Sonnet 4.6.
Cost is unstated. Recursive refinement adds inference cost. The paper plots compute in millions of tokens but states no token totals or dollar costs.
No guarantees. The authors do not guarantee correctness or establish that an adopted change will transfer to a different task, and the signals remain sensitive to run-to-run variation.
Early research code. The README says the repo is not an officially supported Google product and warns about API costs. It had 6 stars and 3 commits when we checked.
Judged benchmark gains may not match gains in your own workflow, a gap we examined in the METR study on AI productivity.
How builders can use it today
You can apply the loop by hand to an agent in Claude Code, Codex, OpenCode or n8n.
Save a reference run. Pick one task your agent does often, run it with your current setup and keep the full transcript: tool calls, files touched, output.
Write two edits separately. One general (for example, "check every requirement in the brief before finishing") and one task-specific (for example, "invoices must include the ABN line"). Keep them in separate prompt sections or skill files.
Probe each against the reference. Rerun the same task with only edit A, then only edit B, and compare with the reference: right tool called, steps skipped, loops, early stops.
Keep what the comparison supports. Merge edits whose effect shows in the transcript; drop the rest.
Log it in a library. One entry per edit: what changed, which task it was tested on, what behaviour changed, when to apply it, tagged general or task-specific.
Start new tasks from the library. Read the general entries first, since those are the ones designed to carry over.
To try the code, the README offers a no-credentials demo (harness2-demo --output runs/demo --k 2) on Linux with Python 3.12 and uv. Model-backed runs use Vertex AI, so start with a small task selection.