Google's Harness² leaves the model frozen and improves the harness around it. This article explains how the loop works — then shows the exact code and steps we used to point it at a red-teaming agent.
Google published Harness² in early October 2026: a framework for recursive agent harnessing. The idea is simple and radical at once. Stop trying to improve the agent by changing the model. Freeze the weights, and let an automated loop rewrite everything around them — the system prompt, the guardrails, the memory, the tool guidance, the subagents, the skills, the scripts, the plugins. Eight editable components. The loop proposes a harness edit, probes it by running the task, and composes the refined harness from the behavioral contrast. No ground truth. No gradients.
We tested it on a red-teaming agent: an attacker whose job is to get a victim assistant to transfer $500 to an attacker wallet. The attacker, the improver, and the victim all ran on one frozen free model through OpenRouter. Total model spend: effectively $0. The base attacker succeeded in two messages. The loop then audited the harness, rejected three of its own proposed trees — including one that changed nothing, because the base itself shipped an invalid plugin file — and made the evidence-backed decision to keep a working harness untouched. Along the way it found two real defects, which we fixed and verified.
The eight components are the whole story. The system prompt, the guardrails, the memory, the tool guidance, the subagents, the skills, the scripts, the plugins — these files are the only things the loop may edit, and in our run they were the only things that needed editing. The model never changed. Nothing was retrained, fine-tuned, or swapped. Every improvement came from rewriting the harness around it, which means every improvement is readable: you can open the diff and see exactly what changed and why.
Figure 1 is the setup: Harness²'s Propose-Probe-Compose loop, the eight-component attacker harness it edits, and the frozen victim it never touches.
Figure 1. The experiment: Harness²'s Propose-Probe-Compose loop optimizes only the attacker's eight-component harness. The attacker model, the improver model, and the victim model are frozen. All model calls go through OpenRouter.
If you run agents in production, this reframes a familiar question. When an agent underperforms, the instinct is to reach for a bigger model. Our run suggests checking the harness first: the playbook, the verification, the guardrails, the memory of what worked. In our case the model was never the bottleneck — two lines of config were, and the loop found them on its own. That is the promise of a self-improvement harness: the agent gets better while you watch, and you can read exactly why. The paid section below is the full breakdown: how the framework works, what each of the eight components does, and the exact steps and code to run it yourself.
In the paid section:
What Harness² is — the framework, the two recursion levels, and the paper's reported gains (11.5 points on WorkBuddy-Bench with weights frozen).
How the loop works — propose, validate, probe, compose; what the improver reads and why KEEP_BASE is a first-class answer.
The eight components — what each file does in a real harness and which lever it gives the loop, from system prompt to plugins.
How to do it — the red-team example as six numbered steps with the actual code: OpenRouter wiring, the frozen victim, the base harness, the adapter, the run command, the audit trail.
What happened when we ran it — the episode table, the two defects the loop found, and the verification probe.
Limitations, stated plainly — n=1, free-model variance, and the atomic-fallback flaw we would fix in the loop itself.
Why this matters for continuous red-teaming — the $0 cost argument and why a harness with a changelog beats a tuned prompt.
