Google Research has released Harness², a framework that recursively improves the environment of an AI agent: from system prompts and guardrails to memory, tool guidance, sub-agents, skills, scripts, and plugins. The model weights remain untouched: the Propose–Probe–Compose mechanism selects edits based on behavioral contrasts of runs and does not require a pre-known correct answer or an external verifier. In published tests with Gemini 3.5 Flash and GLM-5, a single optimization step yielded significant improvements on the WorkBuddy-Bench, JobBench, and LAB benchmarks. The project is distributed under the Apache 2.0 license, runs locally without API keys, and the code and documentation are hosted on GitHub.

image
image

What happened

Google Research has made the Harness² framework publicly available on GitHub in the repository google-research/harness2. It optimizes eight components of the agent's environment: system prompt, guardrails, memory, tool guidance, sub-agents, skills, scripts, and plugins. The Propose–Probe–Compose cycle works as follows: the system suggests configuration edits, tests several variants on the same task, and assembles an improved configuration by comparing how different runs behaved. The second level of recursion retains the accepted configuration and run-verified conclusions for future tasks. It supports parallel and sequential recursion, as well as OpenCode and Codex executors. In tests with Gemini 3.5 Flash and GLM-5, a single improvement step yielded up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points in partial pass rate on LAB; additional iterations further improved the results.

Context

By 'harness,' we mean everything that surrounds the model and determines how the agent works on a task: system prompt, guardrails, memory, tool guidance, sub-agents, skills, scripts, and plugins. Historically, agent quality was improved by training and scaling the models themselves or by manually tuning these elements; Harness² turns the environment into an automatically tunable artifact and considers 'agent capability' as a separate axis of improvement from 'model capability.' Crucially, the method does not require a pre-known correct answer: instead of checking against a ground truth, the system records improvement at the level of observed behavior and assembles the configuration from behavioral contrasts of runs. The paper describing the approach has been published on arXiv (arXiv:2610.14224), and the benchmarks JobBench, LAB, and WorkBuddy-Bench, on which the authors report, are documented in the project materials.

Why this matters for the industry

For the industry, the main takeaway is that agent performance can be significantly improved by optimizing not the model weights, but its environment, which is cheaper than fine-tuning. The method is reproducible and designed as a plugin, so it can be integrated into existing agent pipelines without modifying the model; this reduces the cost of adaptation to new professional fields—office, web, code, law. If the approach is confirmed by third-party teams, advantages like 'we tuned the prompts and tools well' will be devalued, as the environment will be able to be tuned automatically, and the protected asset will become not the configuration, but the flow of real tasks and accumulated, run-verified conclusions retained by the second level of recursion. For teams working with closed models without access to weights, automatic environment tuning may become the primary method of adaptation. Future outlook: harness configuration selection could become a standard stage in the lifecycle of agent systems—an analog of CI for prompts and eval runs, with a configuration registry, automatic runs, and regression rollback.

Why this matters for users

The framework can be installed and tested on your own hardware: the launch is described for Linux with Python 3.12 and the uv manager, and the demo works without API keys, so the cost of experimentation is almost zero. A practical scenario is to clone the google-research/harness2 repository, run it on your own typical tasks, and compare the result with the current agent configuration; integrations with OpenCode and Codex allow doing this on already familiar executors. Project materials include a video review, benchmark documentation, and the arXiv:2610.14224 paper for in-depth familiarization. This is a concrete working example of how an 'agent tunes its own working environment,' not just a discussion of the idea. An important caveat for practice: for legal, financial, and safety-critical work, the results of such improvements need to be independently verified.

What is still unknown / limitations

Figures like 'up to 11.5 points' describe the best case, not the average across tasks: the distribution of improvements, variance between repeated runs, and confidence intervals are not disclosed in the open materials, so the actual effect may be significantly lower than the maximum. Improvements were measured on the authors' own benchmarks and have not yet been confirmed by independent replications; the key open question is whether the selected configuration transfers to tasks that did not participate in the optimization. For production use, there are no published data on latency and the cost of probe runs, so it is too early to integrate the framework into working pipelines. The authors themselves emphasize that contrastive improvement does not guarantee the actual correctness of the result: the signal in this method is weak and relies on run behavior, not on checking against a ground truth.

Sources

Author

Look at AI, editorial team