Harness² is a framework from Google Cloud AI Research and Northwestern University that improves an AI agent without touching the model. The model stays frozen; only its harness changes: the prompts, tools, skills, and scripts around it. On WorkBuddy-Bench, a benchmark of office, web, and coding tasks, that alone raised GLM-5's average score by 11.5 points.
I made the same argument in the first post of my series on building a harness: the model is rented, the harness is yours. The next parts cover how a message reaches the right agent and how to test a harness that learns from its mistakes.
Most summaries of Harness² stop at the headline. I read the paper (2026) and its code to see where the gains came from, because that is the part any team can use without running the framework.
Harness² works one task at a time. An editor model writes a few versions of the harness for the task in front of it, the same frozen model runs the task under each version, and the framework compares how the runs behaved: what each one read, did, and produced.
It then combines the changes that helped. There is no answer key: it judges by behavior.
What worked goes into a library. Each entry holds the adopted harness and a short EXPERIENCE.md file with the situation the lesson applies to, the lesson itself, and the evidence behind it. The next task starts again from the clean base harness, but the editor reads the library before proposing anything.
It does not need a stronger model to do the editing. With the same model as executor and editor, every model they tried improved, and GLM-5 editing its own harness gained 13.7 points on LAB, a benchmark of legal work.
The paper also tried the shortcut: let the editor rewrite the base harness directly, without seeing any runs, any probes or the library. On coding tasks, the score fell from 73.4 to 63.2, and on web tasks from 69.9 to 65.0. Asked to improve its own setup blind, the model made it worse.
That matches what I have seen building agents. When an agent fails, the first instinct is to add a line to its prompt, before looking at what it actually received and what it did. Harness² is built the other way around: every change comes from comparing real runs.
It is careful even with its own winners. The step that writes the lessons is told that being picked is not proof an edit helped: the chosen run may have won for another reason. A lesson that rests only on mixed evidence is narrowed or dropped.
Rewriting the harness without seeing any runs dropped the coding score from 73.4 to 63.2. (Harness², 2026)
In an appendix (Table 6), the authors take the improved harness and remove one group of components at a time. Removing the prompt-related components costs 1.5 points on average. Removing the skills costs 5.3, and removing the scripts 3.7.
It is one setup, Gemini 3.5 Flash on WorkBuddy-Bench, and the authors note the effects do not simply add up, but the prompt carried the least.
A script, in their terms, is code the agent runs instead of reasoning through a step token by token. A skill is a procedure for one kind of job, loaded only when that job comes up. Both are more specific than a prompt, which the model reads on every call whether it needs it or not.
In my experience, a rule added to a prompt tends to fix the case it came from, and a check in code holds every time. The paper's own case study shows it.
On a JobBench task, the agent never reopened the spreadsheets it wrote. The improved harness added, among other changes, verify_outputs.py: a script that reopens every file the agent produced and flags, for example, a formula cell a reader would see blank.
Its rule reads: confirming a file exists is not confirming it is correct. The score on that task went from 43.1 to 77.8.
Removing the skills cost 5.3 points. Removing the prompt-related components cost 1.5. (Harness², 2026)
The editor's instructions are printed in the paper's appendix, and one line stands out: verified facts about the workspace are "the most valuable thing you can encode".
If the runs established that the role "HR" in one file maps to "HR Manager" in another, the editor writes that mapping into the harness, not a rule telling the agent to reconcile role names. The rule leaves the hardest step to the agent; the fact removes it. It also labels those facts ("in this workspace...") and treats a fact copied from an earlier task as a hypothesis to check again. This is a design choice in their instructions, not a measured result, but it is the one I would copy first: many agent mistakes that look like poor reasoning are a fact the model never saw.
Lessons are written once. An EXPERIENCE.md entry keeps the confidence it was given when it was written, and nothing changes it when a later task reuses the lesson, and it goes badly. The authors list revising outdated experience as future work.
Its judge is the model itself. The limitations section says plainly that behavioral comparisons are "sensitive to execution variability and shared model biases", and every probe adds runs and cost.
It also answers the question of learning without retraining differently from Hermes Agent, which I read for the first post. Hermes writes skills after a session and keeps them for the next ones. Harness² starts every task from a clean harness and tests candidates before it adopts anything.
You can use what Harness² found without running it: look at what the agent received and did before changing anything, move what must happen the same way every time out of the prompt and into code, and give the agent the fact instead of the instruction to find it.
In every comparison in the paper, the model stayed the same. What moved the score was what the harness gave it to work with.