Google's Harness² Proves the Scaffold Beats the Model

Every agent team has had the same argument this year: the agent is mediocre, so should we upgrade the model? Google's new research suggests that in a large share of cases the answer is no. The company open-sourced Harness², a framework that rewrites the scaffolding around a frozen model, and its reported gains exceed most model upgrades shipped this year. The paper, Harness²: Recursive Agent Harnessing for an Open World, was submitted on October 9 and the code is on GitHub under Apache 2.0.

For anyone building agents on n8n, LangGraph, or a homegrown runtime, the framing matters. A harness is everything around the weights: prompts, tools, memory, skills, subagents, and the middleware inside the tool loop. Google's claim is that this layer is not decoration. It is a second programmable surface where 10-point swings happen without touching a weight.

What Google Actually Shipped

Harness² keeps the model frozen and edits the runtime instead. It works at two levels that feed each other.

Task-level recursion refines the harness for the task in front of the agent. Because open-world tasks have no ground-truth verifier, the framework uses a contrastive step it calls Propose-Probe-Compose: a harness editor proposes invariant and domain-level edits, candidate probes execute them under matched conditions, and a composer keeps only the changes that behaviour actually supports. It can run the probes in parallel (several candidates at once) or sequentially (one revision built on the last).

Harnessing-level recursion turns that work into reusable experience: instead of dragging a task-specific harness into the next job, an experience reflector updates a persistent improvement harness with the adopted edits and their evidence. The refinement process itself becomes the thing that improves.

The implementation is deliberately mundane, which is what makes it credible. Each of the eight editable components is a file, so every harness change is a diff: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins that hook tool calls outside the model's discretion. Evaluations run on WorkBuddy-Bench (office, web, and code deliverables), JobBench (end-to-end professional jobs), and Harvey's Legal Agent Benchmark. Executors are Gemini 3.5 Flash and GLM-5, both frozen, under OpenCode and Codex harnesses, with Claude Opus 4.8 as harness editor.

The Numbers That Should Change Your Roadmap

The headline results come from a single improvement step.

GLM-5 under OpenCode on WorkBuddy-Bench goes from 64.2 to 75.7, an 11.5 point jump. On Harvey's legal benchmark, GLM-5's partial pass rate rises from 59.6 to 71.4, up 11.8 points. On JobBench, Gemini 3.5 Flash moves from 31.5 to 36.0, up 4.5 points. Adding parallel recursion at a budget of five probes pushes WorkBuddy further: Gemini 3.5 Flash under OpenCode climbs from 76.5 to 80.8 on the code domain and from 79.5 to 83.4 on office work.

The most uncomfortable number for model-first teams is a cross-comparison. On WorkBuddy-Bench, GLM-5 with an improved harness reaches 75.7 and 75.3 under the two harnesses, above the base Gemini 3.5 Flash scores of 72.4 and 74.5. A weaker model with a better harness beat a stronger model with its original one. Google is explicit about the direction: weaker executors gain more on WorkBuddy and LAB.

Two popular shortcuts did badly. ReasoningBank, which retrieves distilled strategies into context while leaving the harness fixed, fell as much as 6.6 points below the base harness on coding tasks. Test-time harness scaling, which spends more inference on revision without carrying state, underperformed the base harness in seven of twelve benchmark-configuration pairs. Throwing tokens at a broken scaffold does not fix the scaffold.

Ablations show where the value sits. On the three-domain WorkBuddy average, removing skills costs 5.3 points, scripts 3.7, and the prompt group 1.5. The improvement library is worth 3.1 and 1.8 points on WorkBuddy and JobBench, scoped editor roles 2.9 and 3.7, composition 1.6 and 1.9. Against unchanged production harnesses, Harness² starting from OpenCode beat the strongest fixed alternative by 4.6, 5.8, and 4.9 points across code, web, and office.

Reliability moves with the scores. After one step, tool-error rates fall from 0.8 to 0.5 percent on WorkBuddy, from 14.4 to 9.1 percent on JobBench, and from 2.0 to 1.6 percent on the legal benchmark.

Where Recursive Harnessing Still Breaks

The paper reports nine regressions and does not hide them. Candidate selection sometimes prefers a weaker variant: on WorkBuddy code, an output scoring 55 was adopted over one scoring 95, and on the legal benchmark a narrower edit cut the score from 54 to 26. A wrong premise propagates: a literal-key requirement or an unchecked cache assumption cost 2 to 11 points across candidates. And refining the base harness directly, without reference executions or an experience library, actively degrades performance, dropping code from 73.4 to 63.2 and web from 69.9 to 65.0.

Cost is real: proposing, probing, and composing needs extra executions and editor sessions, and the authors say the trade-off was characterised over a bounded range, not solved. Feedback is behavioural, not ground truth, so adopted edits can encode a shared model bias. Transfer is uneven: a harness tuned for Gemini 3.5 Flash lifted GLM-5 by 17.3 points on code, but gave Claude Opus 4.8 only 2.6 and 1.1. Harness quality is portable. Optimal harnesses are not.

What This Means for Builders

Strip the benchmark framing and the paper is a specification for the layer most teams still treat as glue code.

• Diagnose before you buy. When your agent fails at a step, the fix is usually the cheapest component that addresses it, not the largest model on the market. Google's editor prompt starts by tracing the workflow and fixing the earliest observed divergence.
• Map your stack to the eight components. In an n8n build, system prompt and guardrails are agent instructions, skills are intent-triggered sub-workflows, scripts are code nodes replacing repeated reasoning, plugins are pre-tool-call checks, subagents are separate contexts returning only results. If you cannot point to a file or node for each, you have a prompt, not a harness.
• Write facts, not advice. The strongest cases encode verified workspace facts: which key columns join, which units a field uses. "Be thorough" changes nothing; "role X maps to position Y" removes the hardest step.
• Version the harness like code. Every component is a file and every edit is a diff. That is the only way to tell a genuine improvement from run-to-run noise, which the failure analysis repeatedly flags as a confounder.
• Measure tool errors separately. Falling error rates are the leading indicator that a harness edit worked, and they move before benchmark scores do.

n8n Lab argued earlier that the harness is the real hero, not the model. Google has now published the missing half: a repeatable method for improving the harness without retraining anything, with numbers attached. Labs will keep shipping models. Teams that learn to edit their own scaffolding will get more out of the ones they already pay for.