
Harness the agent. Then harness its self-improvement
Harness² is a research project from Google Cloud AI Research and Northwestern University that introduces recursive agent harnessing: a method that improves an AI agent's performance by editing the harness around a frozen model rather than the model itself. It works at two levels — refining the execution harness within a task, and updating an improvement library that guides how future harnesses are refined. The method is documented in a paper (arXiv:2610.14224) with accompanying code and benchmarks showing score improvements on WorkBuddy and JobBench.
Task-level recursion refines the execution harness for the current task (Propose → Probe → Compose), while harnessing-level recursion updates an improvement library with reusable harnesses and experience (including EXPERIENCE.md files) to guide future tasks.
The agent is defined as Model + Harness. Model weights stay fixed; the harness — made of eight editable components (system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, plugins) — is what gets improved.
Parallel recursion explores k independent candidates per scope and composes them; sequential recursion carries the composed harness through k successive improvement steps. Scaling k from 1 to 5 adds +4.3 points on WB-Code.
Improvements can touch what enters the context, tool usage, orchestration, and middleware — e.g., a JobBench case added verification guardrails, a reconciliation skill, and precise tool guidance rather than just prompt tweaks.
Each new task starts the executor at the base harness H₀; reusable knowledge lives in the improver's library rather than in the executor's harness, avoiding unbounded harness drift.
On WorkBuddy (Code, Web, Office domains), a single improvement step lifts Gemini 3.5 Flash / OpenCode from 72.4 to 77.5 average; k=5 parallel recursion reaches 80.8, outperforming ReasoningBank, Meta-Harness, and Harness Scaling baselines.
The executor starts a fresh run from the base harness H₀; prior experience resides only in the improver's library.
The improvement harness executes the base harness as a reference, then proposes invariant and domain-specific candidate edits to the harness components.
Each candidate is executed to gather evidence; a composer reads all candidates and execution evidence, retaining only edits supported by results, and produces the final harness H′.
The final harness executes and delivers the task output. The improver then reflects on the full improvement record and updates the library of reusable harnesses and lessons for future tasks.
Harness² is a method for recursive agent harnessing: it improves an agent by refining the harness around a frozen model (system prompt, guardrails, memory, tools, subagents, skills, scripts, plugins), then updates an improvement library so future harness refinements benefit from past experience.
No. The model weights stay frozen. All improvement happens in the editable harness components, so the same executor model scores higher without fine-tuning.
On the WorkBuddy benchmark, Gemini 3.5 Flash with OpenCode improves from 72.4 (base harness) to 77.5 after one improvement step, and to 80.8 with parallel recursion at k=5, across the Code, Web, and Office domains. Gains are also reported on JobBench and LAB.
The reported experiments use Gemini 3.5 Flash and GLM-5 as executors with the OpenCode and Codex initial harnesses. The harness component names and paths in the paper's appendix follow OpenCode.
Parallel recursion explores k independent candidates per scope and composes them, with each composer reading all candidates and execution evidence. Sequential recursion carries the composed harness through k successive improvement steps. Scaling parallel recursion from k=1 to k=5 added +4.3 points on WB-Code.
The project page links to a code repository and a paper (arXiv:2610.14224) with a BibTeX entry, indicating the code is publicly available for research use.
The page does not list any pricing — it is a research project with code and a paper rather than a commercial product. Usage costs would come from the inference runs needed for reference execution, candidate probes, and final harness execution.