Harness²: Self-Improving AI Agents Without Retraining Model Weights

Concept: Agent = Model + Harness

The paper defines an agent as the combination of a frozen model and a harness — all external scaffolding that lets the model act as an agent: system prompts, guardrails, memory, skills, tool guidance, scripts, sub-agents, and plugins. Optimizing this layer is called harnessing . The key attraction is cost: harness changes require no weight updates or training, only file-level diffs.

Two Core Challenges in Recursive Self-Improvement (RSI)

RSI means an AI system makes persistent modifications to itself that further influence how future improvements are generated, evaluated, and retained. In open-world deployment, two problems arise:

No ground-truth verifier: New tasks at test time were unseen during harness design, so there is no standard answer to judge whether a modification helps or hurts.

Poor generalization: Harnesses tuned for a specific task become over-specialized; directly inheriting them on a new task distribution introduces noise.

Harness² addresses these with two nested recursive loops: task-level recursion solves the verification problem, and improvement-level recursion solves the generalization problem.

Task-Level Recursion: Propose–Probe–Compose

For a new task, the agent first runs a reference execution with the current harness to expose behavioral patterns (not to judge correctness). Then:

Propose: Generate two candidate harness edits — an invariant candidate targeting cross-domain failure modes (planning, tool use, context management, delegation) and a domain candidate targeting task-specific knowledge, processes, and constraints. Candidates are direct file edits that may reuse components from the experience library, but task-relevant facts must be verified against current task evidence.

Probe: Execute each candidate harness on the same task, model, and environment. Compare behavior against the reference execution ( behavioral contrast ) to see if the target defect is mitigated, unchanged, or new regressions appear.

Compose: Synthesize a new harness by merging evidence-supported edits, resolving conflicts, adopting a single candidate, or keeping the original. Every decision is tied to a concrete observation, not an assumed score increase.

On top of a single step, task-level recursion extends in two modes controlled by budget k:

Parallel recursion: Run k reference executions, propose k invariant + k domain candidates, and run k independent composition sessions — breadth-oriented search.

Sequential recursion: Chain k contrast steps serially, each carrying forward the previous harness and accumulated evidence — depth-oriented optimization.

When k > 1, a final selector picks the best anonymized deliverable from the pool without generating new content.

Improvement-Level Recursion: Persisting "How to Improve"

After each task, the full improvement trace — reference execution, candidates, probe results, composition decisions — is reviewed. Only experiences backed by behavioral contrast enter the harness improvement library . Each library entry contains an executable harness plus an EXPERIENCE.md documenting applicability, lessons, and supporting evidence. The library is indexed for on-demand retrieval.

Subsequent tasks still start from the shared initial harness, but the updated improvement harness guides Propose, Probe, and Compose. Old components are selectively reused or rewritten via Propose, not automatically inherited. Model weights, phase instructions, and decision rules remain fixed throughout; only the experience library evolves. This design directly answers the generalization challenge: transferable improvement experience crosses tasks, while task-specialized harnesses do not.

Harness Decomposition: 8 Editable Files

Harness² extends the AHE file-level decomposition to eight components:

System Prompt — systemprompt.md — activated on every call

Guardrails — guardrails.md — activated on every call

Memory — LongTermMEMORY.md — activated on every call

Skills — skills/<n>/SKILL.md — activated when invoked

Tool Guidance — tool_guidance.md — activated on every call

Scripts — scripts/<name>.py — activated via bash execution

Sub-Agents — sub_agents/<n>/AGENT.md — activated via task tool

Plugins — plugin/<name>.ts — middleware, hooks every tool call

The first four build context; tool guidance and scripts handle tool interfaces; sub-agents manage orchestration; plugins act as middleware on every tool call. Every optimization corresponds to a clear set of file diffs, simplifying version control and audit.

Experimental Results: Weaker Models Surpass Stronger Baselines

Setup: Three professional benchmarks — WorkBuddy-Bench (office, web, code deliverables), JobBench (end-to-end professional work), LAB (Harvey's legal agent benchmark, Partial single-pass rate). Two frozen execution models: Gemini 3.5 Flash and GLM-5. Two initial harnesses: OpenCode and Codex. Harness edits performed by Claude Opus 4.8 under OpenCode. Baselines: ReasoningBank (retrieval-based experience memory), Meta-Harness (offline search), Harness Scaling (test-time per-instance harness editing).

Single-step improvement (k=1) gains:

WorkBuddy-Bench, GLM-5 + OpenCode: 64.2 → 75.7 (+11.5)

JobBench, Gemini 3.5 Flash + OpenCode: 31.5 → 36.0 (+4.5)

LAB (Partial), GLM-5 + OpenCode: 59.6 → 71.4 (+11.8 pp)

Weaker models benefit more. On WorkBuddy-Bench, GLM-5 after single-step improvement reaches 75.7 (OpenCode) and 75.3 (Codex), exceeding Gemini 3.5 Flash with original harness (72.4 and 74.5). An improved harness lets a weaker model outperform a stronger model's default configuration.

Recursive budget yields further gains. Parallel recursion at k=5 adds 2.9–3.9 points on WorkBuddy-Bench, 3.0–4.2 on JobBench, and 2.6–6.7 pp on LAB Partial. At k=2, both recursion modes already surpass all baselines at k=5.

Ablation (Gemini 3.5 Flash + OpenCode, k=1) confirms each component contributes:

Removing experience library: WorkBuddy-Bench −3.1, JobBench −1.8

Removing invariant/domain dual roles: −2.9 and −3.7

Removing composition step: −1.6 and −1.9

Cross-benchmark transfer: Experience library accumulated on JobBench improves WorkBuddy-Bench single-step by +0.6 (Code), +0.5 (Web), +2.9 (Office).

Compute efficiency: Both Harness² configurations lie on the Pareto frontier; Meta-Harness consumes more compute than Harness² k=5 yet scores lower.

Getting Started: Demo Without Model Credentials

Requirements: Linux, Python 3.12, uv.

uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

The local demo uses a deterministic editor with real Python execution, running both recursion modes without any model credentials.

Running real benchmarks requires model access: Node.js 20+, Google Cloud CLI, Vertex AI project and model ID in .env; LAB additionally needs Pandoc and Poppler; WorkBuddy-Bench needs Docker. Example LAB workflow:

harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel --only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel

--k

sets task-level recursion budget, --mode chooses parallel or sequential, --substrate cx switches executor to Codex. Results save to runs/; repeat the same command to resume; use a new HARNESS2_RUNS_DIR when changing model or task set.

Network restrictions must be configured before evaluation. Executor network access is unrestricted; Codex sandbox is off by default. Public benchmark scoring rubrics may be online — without restrictions, the agent could fetch answers and grading criteria. Model-driven runs incur API costs; use --dry-run to preview task selection and start with small task sets.

Conclusion: Optimize Harness Before Upgrading Model

Harness² opens a performance dimension beyond "use a larger model": refine the runtime cognitive engineering. A single contrastive improvement can push a weaker model past a stronger model's default harness; the dual recursion lets the improvement process itself accumulate experience. For developers, optimizing the existing harness before upgrading to a more expensive base model may offer better cost-effectiveness.

References

GitHub: https://github.com/google-research/harness2

Paper: https://arxiv.org/abs/2610.14224