Harness²: How AI Agents Improve Their Own Tooling Without Retraining

Harness² asks a practical question: can an agent improve by editing the system around a frozen model? It changes the harness—not model weights—and tests those changes through execution. It is aimed at open-world tasks that were not known when the harness was designed and may have no ground-truth verifier at runtime.

The target is the gap between model capability and agent performance. A capable model may still fail because its tools are poorly described, memory is irrelevant, delegation is weak, or workflow instructions omit a needed step. Harness² offers a repeatable test-time process for changing these surrounding components without fine-tuning. It is most relevant when teams can run tasks repeatedly and inspect execution traces.

Task-level recursion starts with reference execution(s) using the base harness. An editor proposes general/invariant and domain-specific candidates; the system probes those candidates on the same task, compares their execution trajectories, and composes refined versions from observed behavioral contrasts. After adoption, a reflector stores the adopted harness and evidence-supported lessons in a per-domain experience library. Later tasks can use earlier lessons; each task still starts from its base harness.

The framework exposes eight harness components. Together they shape the context the model receives, the tools it can use, how work is delegated, and how behavior unfolds inside the tool loop.

The paper evaluates three professional-work benchmarks across four executor–harness combinations: Gemini 3.5 Flash or GLM-5, each run with OpenCode or Codex. The reported single-step setup uses k=1; results are means over three runs. WorkBuddy-Bench reports average score, JobBench reports benchmark score, and LAB reports partial pass rate. These are project-reported results, not independent replications.

The repository includes a deterministic local demo and model-backed benchmark workflow. Start with the demo before spending on real model calls. The package metadata declares Python >=3.12,<3.14, POSIX, version 0.1.0, and a small core dependency set; rendering and bridge dependencies are optional extras. The published model-backed workflow uses Vertex AI credentials and executor tooling.

Harness² is an experiment framework, so its evaluation controls matter as much as the refinement loop. The repository documents a concrete leakage risk: all three benchmarks are public, and JobBench publishes per-task RUBRICS.json files. In a validation run, a Codex rollout downloaded a task rubric without being instructed to. The release does not restrict executor network access by default; Codex runs with its sandbox disabled.

The central contribution is a practical loop for improving agent scaffolding at test time: compare candidate harness behavior on the same task, compose the useful changes, and preserve supported lessons for future tasks. It complements model training rather than replacing strong evaluations, security controls, or domain-specific validation.

The source tree exposes separate command-line entry points for running sweeps, judging, reporting, setting up benchmark dependencies, checking setup, running the demo, and starting an optional bridge. This separation is useful operationally: a successful refinement run is not the same thing as a scored evaluation or a generated report.

The reported results suggest harness refinement can help different executors, with the largest single-step gains in the weaker GLM-5 configurations. However, the results are bounded by the chosen professional-work benchmarks, model/executor versions, the editor model, and the evaluation environment. The authors report means over three runs; the public repo cautions that network access and benchmark-rubric exposure can undermine evaluation validity.

No—Harness² is optional infrastructure, not a prerequisite for building or deploying an AI agent. It is most valuable when you have repeatable tasks, a measurable baseline, access to execution traces, and enough budget to test several candidate harnesses. For a simple chatbot or a one-off workflow, manually improving instructions and validating them may be sufficient.

This article should target several related search clusters rather than repeat the paper title as a keyword list. The central discovery terms are “Harness²”, “Recursive Agent Harnessing for an Open World”, “recursive agent harnessing”, “self-improving AI agents” and “agent harness engineering”. These capture navigational and high-intent research searches. The core technical cluster is “recursive self-improvement (RSI)”, “harness evolution”, “test-time harness optimization”, “open-world agent adaptation”, “verifier-free optimization”, “ground-truth-free agent improvement”, “Propose–Probe–Compose”, “contrastive execution”, “behavioral feedback” and “persistent improvement harness”. These describe the actual mechanism, not generic AI hype.

The implementation and developer-intent cluster includes “agent orchestration”, “agent runtime optimization”, “agent memory”, “agent skills”, “tool-use optimization”, “prompt optimization”, “middleware plugins”, “OpenCode”, “Codex”, “parallel recursion”, “sequential recursion”, “task-level recursion budget k”, “frozen model weights” and “test-time adaptation without fine-tuning”. These are useful for readers trying to reproduce or adapt the open-source framework. The eight editable harness components—system prompt, guardrails, memory, skills, tool guidance, scripts, subagents and middleware plugins—are specific long-tail topics worth linking from the implementation section.

The benchmark and application cluster includes “WorkBuddy-Bench”, “JobBench”, “Harvey Legal Agent Benchmark”, “LAB benchmark”, “professional AI agents”, “legal AI agents”, “enterprise AI automation”, “coding agents”, “GLM-5”, and “Gemini 3.5 Flash”. Use benchmark names alongside the task domain and model configuration so searchers can distinguish reported results from broad claims. The evaluation and safety cluster includes “agent evaluation”, “reproducible agent evaluation”, “benchmark contamination”, “benchmark rubric leakage”, “network isolation for evaluation”, “evidence-backed reflection”, “adopted harness provenance” and “per-domain lesson retention”.

Suggested natural-language search phrases: “How do AI agents improve their own tools without retraining?”, “recursive self-improvement for AI agents”, “how Propose Probe Compose works”, “agent harness vs model fine-tuning”, “open-world agent adaptation without a verifier”, “parallel vs sequential harness recursion”, “Harness² benchmark results”, “how to build a self-improving agent harness”, and “agent harness engineering for enterprise workflows”. Use these phrases in the introduction, relevant subheadings, image alt text and FAQ-style explanations where they genuinely fit. Avoid keyword stuffing or repeating every phrase in every section.

Trend evidence and freshness: the official Google Research repository had approximately 21.2k stars, 2.1k forks and a reported +3,425 stars over the preceding week in an AI repository-ranking snapshot crawled 31 October 2026; another snapshot reported +337 stars in 24 hours. These are third-party snapshots, not GitHub API-verified counts, and can change quickly. The paper was also highlighted in the DAIR.AI Academy Week of October 12–18 paper roundup. Treat this as evidence of developer and research attention, not proof of broad public virality. Sources: https://github.com/google-research/harness2 ; https://airanks.app/repo/google-research/harness2 ; https://academy.dair.ai/papers/harness-2-recursive-agent-harnessing-for-an-open-world-2610.14224 ; https://harness2.app/docs/tutorial ; https://github.com/google-research/harness2/blob/main/docs/EXPERIMENTS.md