Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
The Target of Optimization Shifts to the System Around the Model
Google Cloud AI Research has open-sourced Harness², a framework that recursively improves an agent's runtime harness during deployment. It targets a familiar but difficult setting: tasks arrive after system design, and at runtime there may be no answer key to tell the agent directly whether it has succeeded. The framework neither trains the model nor changes its weights. Instead, it edits surrounding files such as prompts, tools, and orchestration instructions.
The change is worth a technical leader's attention not because it proves that a model can make itself smarter, but because it shifts optimization beyond the model alone and toward the whole runtime system. Problems that appear to reflect limited model capability may also come from unclear tool guidance, unreliable planning, or poorly designed handoffs. Harness² tries to make these factors objects that can be modified, exercised, and compared.
Changes Are Split into Proposal, Probe, and Composition
Harness² exposes eight kinds of editable components: system prompts, guardrails, memory, skills, tool guidance, scripts, subagents, and middleware plugins. Together they cover how context is assembled, how tools are used, how work is delegated, and how the agent behaves inside its tool loop. The engineering implication is that improvement need not be crammed into an ever-longer system prompt; it can be assigned to files with specific responsibilities.
Within a task, the framework uses Propose–Probe–Compose. An editor proposes a general change and a domain-specific one in response to observed behavior, runs the candidate harnesses on the same task, then compares trajectories and outputs. It keeps changes supported by behavioral evidence and can retain the original if the evidence is insufficient. This comparison can show whether a change affected behavior, but it cannot establish that the result is correct.
The Score Gains Are a Signal, Not a Universal Promise
The paper evaluates four executor-and-harness configurations on WorkBuddy-Bench, JobBench, and the legal-task benchmark Harvey's LAB. Its main results use one refinement step and report means and standard deviations over three runs. The most striking figures are for GLM-5 with OpenCode: WorkBuddy-Bench rises from 64.2 to 75.7, a gain of 11.5 points, while the LAB Partial measure rises from 59.6 to 71.4, a gain of 11.8 points. Gemini 3.5 Flash with OpenCode moves from 31.5 to 36.0 on JobBench, a 4.5-point increase.
This is not a case where only one successful pairing was reported: the material says all four configurations improved on all three benchmarks after one step. But the spread in gains is a reason not to equate “can improve” with “will improve substantially.” GLM-5 with Codex moves only from 23.6 to 24.8 on JobBench, a 1.2-point gain. Weaker executors sometimes benefit more, and after one refinement GLM-5 exceeds baseline Gemini 3.5 Flash on WorkBuddy-Bench, but that remains an observation tied to particular benchmarks and configurations.
Cross-Task Learning Adds Both Memory and Cost
The framework does not stop at repeated attempts on one task. After each task, it records the adopted harness and lessons in an improvement library, including the conditions under which a change had supporting evidence. Later proposals can draw on that experience. Crucially, the next task still starts from the base harness rather than inheriting the previous task's customized version unchanged. The design aims to accumulate useful experience without treating a one-off edit as a universal rule.
The recursion budget determines the scale of the search. In parallel mode, the framework probes multiple general and domain-specific candidates before composing them; in sequential mode, it chains refinement steps. The paper reports that increasing the budget to k=5 adds 2.9–3.9 points over one step on WorkBuddy-Bench, 3.0–4.2 points on JobBench, and 2.6–6.7 points on LAB Partial. These gains belong to specific experimental settings. A larger budget also means more model calls and inference cost, so the results do not imply that every workload should use the largest search.
Separate the Evidence Limits and the Roles Before Deployment
One potential source of confusion is that “no answer key” does not mean “no scoring in the experiments.” The method avoids relying on answer keys or labeled verification feedback while modifying the harness at runtime; final evaluation still uses benchmark scoring. Another important condition is the division of roles: GLM-5 and Gemini 3.5 Flash are frozen-weight executors in the main experiments, while Claude Opus 4.8 is the default harness editor. The reported gain for GLM-5 therefore should not be described as GLM-5 independently rewriting its entire system.
The authors also note that execution randomness and shared model biases can affect trajectory comparisons. Behavioral evidence cannot guarantee that a change is correct or that it will transfer to new tasks. The project code is licensed under Apache-2.0, but that does not mean third-party code, benchmarks, and datasets share the same license; the repository also notes custom licensing and a regional restriction related to EU use for WorkBuddy-Bench. The repository states that the project is not an officially supported Google product. For technical leaders, the prudent approach is to treat Harness² as a controlled harness-search tool: use it with an explicit cost budget, auditable changes, and independent evaluation on separate tasks, rather than as a verification-free mechanism for online self-evolution.