About this video
One sentence took this AI agent from 60 to 100. Nobody told the AI what to write.
What's the one rule you'd add to your agent's prompt?
We read the new Google Cloud AI Research + Northwestern preprint "Harness²" page by page: what an agent's harness is (the eight files around the model: system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, plugin); the single sentence that took a coding task from 60 to 100; the four ideas that let an agent improve its own harness with no answer key (propose with two editors, probe then compose, go wider or deeper, and a library that makes the improver better); the proof on WorkBuddy-Bench, JobBench and Harvey's legal benchmark, where GLM-5 with an improved harness beat Gemini 3.5 Flash with its stock one; why rewriting a harness without running it made things worse; Claude Opus 5's self-written watchdog plugin; where the method broke (the blind picker, the checker that said PASS three times); and five things to do about it if you build AI agents.
Chapters
0:00 A weaker AI beat a stronger one
0:39 The problem: no answer key
1:49 One sentence: sixty to a hundred
2:34 Idea 1: Propose, with two editors
3:25 Idea 2: Probe, then compose
4:20 Idea 3: Go wider, or go deeper
5:02 Idea 4: Learn how to improve
5:57 The proof: weaker beats stronger
8:04 Three more fixes, one pattern
9:40 Where it fails
11:12 What to do about it
12:19 Recap
Paper: Harness²: Recursive Agent Harnessing for an Open World. Ruiyao Xu, Yanfei Chen, Zhongying CuiZhu, Bhavana Dalvi Mishra, Yifei Ming, Han Yu, Rujun Han, Chen-Yu Lee, Tomas Pfister (Northwestern University, Google Cloud AI Research). arXiv:2610.14224, October 2026 (preprint, not yet peer reviewed). https://arxiv.org/abs/2610.14224
Code: https://github.com/google-research/harness2
Figures, tables and prompt excerpts from the paper are shown under its CC BY 4.0 licence (https://creativecommons.org/licenses/by/4.0/) with credit; the highlights, redrawn bars, animations and characters are ours.
Music: Voice Over Under by Kevin MacLeod, CC BY 3.0, via Wikimedia Commons (https://commons.wikimedia.org/wiki/File:Voice_Over_Under_(ISRC_USUAN1600001).mp3)
Pranav Innovates: AI research, explained. Subscribe to stay up to date.
YouTube: https://www.youtube.com/@PranavInnovates
Instagram: https://www.instagram.com/pranavinnovates
What the video says
Google researchers took a weaker AI model. No retraining. Not a single weight changed. They only changed the files around it: its instructions, its tools, its checklists. And the weaker model beat a stronger one. The catch? Nobody gave it the right answers. No answer key, no score. It worked out what to fix by watching itself work. On one task, a single sentence the system added took the score from sixty to a hundred. You'll see that sentence in two minutes, then the method that found it, so you can use it on your own agents. This is Harness squared, a new preprint from Google Cloud AI Research and Northwestern University. Let's read it, page by page. First, what's a harness? An AI agent is two things. The model, the brain that predicts the next word. And the harness, everything wrapped around it. The paper splits the harness into eight parts, each kept as files. A system prompt. Guardrails, rules that always hold. Memory. Tool guidance. Skills, recipes that load only when they're needed. Scripts, small programs. Subagents, helpers that work in their own context and report back. And a plugin, code that sits inside the agent's loop, where it can't be ignored. Same model, different harness, very different results. So the dream is an AI that improves its own harness. That's called recursive self-improvement: AI that improves the thing doing the improving. But there's a problem. Earlier methods tuned a harness on practice tasks with known answers, then shipped it. Real tasks don't come with answers. And a harness tuned for one task often fails on the next. So the paper asks one question. Can an agent improve its harness for the task in front of it, with no answer key, and also get better at improving, task after task? Before the method, the result I promised. Here's a coding task from the paper: make a router's tests pass. The agent scored sixty. The run shows why. The agent was writing its tool calls as plain text. It looked busy. Then the turn just ended, and nothing ran. Of those eight files, which one would you change? Take a guess. The fix was one rule in the tool guidance. Never write a tool call as ordinary text. Text like that is not executed. Score, one hundred. Every test, on every attempt. Nobody told the system what was wrong, and no grader looked at it. So how did it find that sentence? Four ideas. Let's take them one at a time. Idea one. Propose. First, the agent simply does the task with its current harness. That's the reference run. The paper is careful here. The reference run shows how the agent behaves, not whether its answer is right. Nobody knows that. Then two editors read the run, and each one edits the harness files. The first, the invariant editor, asks: how does this agent work? Planning, tool use, managing its context, handing off work. The second, the domain editor, asks: what would an expert in this field know? The procedures, the rules, the checks a professional makes. Their instructions are strict. Every edit must trace to a moment in a run. If you can't name the moment, the edit is speculation. For builders: before you change a prompt, find the exact step in the log where it went wrong. No moment, no edit. Idea two. Probe, then compose. Each edited harness runs the same task again. Same model, same setup. Now you can compare. Did the agent stop making the mistake? Did nothing change? Did something new break? The paper calls this a behavioral contrast. It's still not a grade. Runs are random, and models share blind spots, so the evidence can mislead. It only guides the next step. Then a composer reads everything: the runs, the edits, the differences. It can merge the edits that earned their place, fix ones that clash, adopt one candidate whole, or change nothing at all. Changing nothing even has a name in the prompts. Keep base. And the prompt says it plainly: keep base is a real answer, not a failure. For builders: test every prompt change on the same task, side by side, and make no change an allowed outcome. Idea three. Recursion. One round already helps, so do more. You can go wider: run the original harness several times, draft several pairs of edits, and compose several finished harnesses at once. That's parallel. Or go deeper: each round builds on the last round's harness and everything it saw. That's sequential. The number of tries is called k. With more than one finished answer, a final picker chooses which one to deliver. It's blind on purpose. It can't see which harness made which answer, and picking the untouched original is allowed. For builders: in their tests, wider finished slightly ahead at five tries. And it runs side by side, so you pay mostly in tokens, not in waiting time. Idea four tackles the other problem from the start: a fix for one task often fails on the next. So the second level of recursion improves the improver itself. After each task, a reflector reads the whole record and writes a library entry: the harness that was adopted, plus a short experience note. What weakness it fixed, when it applies, and the evidence. And it's picky. Being picked doesn't prove an edit worked. A lesson is kept only if a contrast between runs supports it. With no real evidence, it writes no lesson at all. Here's the clever part. The next task does not inherit the last harness. It starts again from the plain original. Only the improver has learned. It reads the library and borrows what fits, and an old fact is treated as a guess until this task's evidence confirms it. So the agent doesn't drag one task's baggage into the next. It carries the skill of fixing itself. Now, the proof. Two models did the work: Google's Gemini 3.5 Flash, and the open model GLM-5. Each started inside two popular coding-agent harnesses, OpenCode and OpenAI's Codex. The editor was Claude Opus 4.8. Three tough benchmarks. WorkBuddy-Bench: coding, web pages and office files. JobBench: long, real professional jobs. And Harvey's legal agent benchmark. Every score is the average of three runs, and the graders' answers never reached the pipeline. One round of improvement helped in every setup. GLM-5 on WorkBuddy went from sixty four point two to seventy five point seven. That's eleven and a half points. On legal work, GLM-5 rose eleven point eight percentage points. And here's the headline. Seventy five point seven beats Gemini's seventy two point four with its original harness. A weaker model with a better harness beat a stronger model with its stock one. Going wider, with k of five, added a few more points on every benchmark. And in the paper's scaling test, both versions at just two tries beat every rival method at five. The rivals struggled. One memory method fell up to six point six points below the plain harness on coding, and a per-task rewriting method finished below it in seven of twelve tests. Harness squared beat every rival on WorkBuddy and JobBench in all four setups. The one exception was legal work with Gemini in Codex, where Meta-Harness, tuned ahead of time on practice tasks, came out ahead. Now a guess. What if you skip the runs, and just ask the AI to rewrite the harness by reading it? Better, or worse? Worse. On coding, the score fell from seventy three point four to sixty three point two. Running and comparing is the whole trick. And you don't need a smarter editor. With each model editing its own harness, all five improved on every benchmark, from GLM-5 to Claude Opus 5. For builders: before you pay for a bigger model, try a better harness. Here, the harness was worth more than the model upgrade. So what else did it change? Three more fixes, and then the pattern. Another job, for a producer: turn schedule, crew and budget files into a set of production documents. Score, forty three point one. The run had two failures. Numbers were never reconciled across the files, and the finished files were never reopened. The new guardrail says: confirming a file exists is not confirming it is correct. Add a reconciling skill, a script that reopens every output, and a tip that spreadsheet cells often store numbers as text. Seventy seven point eight. In legal work, an agent marked up a document with Word's tracked changes. But read as text, the changes vanished, and the markup looked like a clean rewrite. A skill to write deletions and insertions into the text itself: forty four point four to ninety four and a half. And my favourite. Claude Opus 5, improving its own harness, kept researching while its output files stayed unwritten near the deadline. So it wrote itself a watchdog plugin. After twenty five tool calls with an empty output folder, it adds a line: stop researching, write every required artifact. Its own comment says why. An instruction is skippable. A line appended to a tool result is not. Seventy two to a hundred. Notice what these are, the sixty to a hundred sentence too. Not genius. Habits. Use your tools for real. Check your inputs. Reopen your outputs. Stop researching and ship. Across the study, skills and scripts made up about half of all edits, and taking the skills back out cost the most. Now, what this paper does not show, and where the method broke. The blind picker can pick wrong. On one coding task, it chose an answer scoring fifty five over one scoring ninety five, because it looked like, quote, the complete, plainest implementation. And this one should sound familiar if you watched our last episode. An editor wrote a skill with its own checker script. The checker reported pass, three times. The tests disagreed. The paper's verdict: a checker written by the editor cannot catch the editor's assumption. Sometimes an edit worked and bought nothing. A form-filling skill got thirty three out of thirty three values right, and no grading criterion even read those files. It used eighty five of the run's hundred and thirty two steps. The paper's own limits: every round costs extra runs and editor sessions. Its evidence is a contrast between runs, not proof of correctness, so randomness and shared blind spots can fool it. And it tested a limited range of budgets. To be fair on cost, the paper counts every token, including the improving. Both settings it measured sat on the best cost-for-score curve, and Meta-Harness spent more compute for a lower score. One note of my own. Many of the grading items were judged by AI models, Gemini and Claude, and on JobBench the grader was the same Claude model as the editor. The rubrics were hidden from the pipeline, but it's worth checking in follow-up work. And this is a preprint, not yet peer reviewed: three benchmarks, two models, two starting harnesses. So, what do you do with this if you build with AI? Five things. The first four come from the paper's results and prompts. The last one is my take. One. Read your agent's logs before you touch its prompt. Find the moment it went wrong. The best fixes here came from one specific step. Two. Put knowledge where it's cheap. The paper's prompts rank it: a skill for anything with a trigger, a script for repeated mechanical work, a subagent for a big search with a small answer, a plugin for rules the model keeps skipping. Always-on text comes last, because every word is paid for on every run. Three. Make the agent reopen what it wrote. A file that exists isn't a file that's correct. Four. Keep a library of lessons with the evidence attached, not a pile of old prompts. And treat every old fact as a guess on a new task. Five, my take. Check your checkers with something the editor didn't write. Last episode, an agent's checker said forty one out of forty one. This time, an editor's checker said pass, three times. Same lesson, two papers in a row. Let's recap. Harness squared improves an agent's harness with no answer key. Propose two kinds of edits. Probe them on the same task. Compose only what the runs support. Go wider or deeper. And keep a library, so it gets better at improving. One round lifted a weaker model above a stronger one. And the fixes were habits: real tool calls, reconciled numbers, reopened files, and a watchdog that says stop and ship. The model didn't get any smarter. Its harness did. So the next time your agent fails, don't go shopping for a bigger brain. Open the logs, find the moment, and write the one sentence it was missing.