One-sentence Summary

Northwestern University and Google Cloud AI Research introduce Harness2, a plug-and-play recursive agent harnessing framework that evolves LLM-agent harnesses for unseen open-world tasks without ground-truth verifiers by combining task-level contrastive Propose-Probe-Compose refinement with harnessing-level experience extraction, improving GLM-5 and Gemini 3.5 Flash over their base harnesses with gains of up to $11.5$11.5 points on WorkBuddy-Bench, $4.5$4.5 points on JobBench, and $11.8$11.8 percentage points on LAB.

Key Contributions

• Harness2 is introduced as a plug-and-play recursive agent harnessing framework that evolves LLM agent execution harnesses in open-world settings where test-time ground-truth verifiers are unavailable.

• Task-level recursion refines the current harness through a contrastive Propose, Probe, and Compose step that supports parallel or sequential recursion and can scale with a larger refinement budget.

• Harnessing-level recursion updates a continual improvement harness from adopted edits and accumulated experience, yielding gains across three professional benchmarks and four model and harness configurations, including up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB.

Introduction

LLM agents depend not only on model quality but also on their harness, meaning prompts, memory, skills, tools, and orchestration logic. As agents are used for office, legal, and other high stakes workflows, manually designing and updating this harness becomes expensive, so the authors study recursive self improvement of the harness itself.

Prior methods often optimize harnesses against fixed tasks, unit tests, or validation feedback and then deploy a static configuration, which can fail in open world settings where task requirements keep changing. Newer online approaches can adapt to new tasks or carry a prior execution harness forward, but they still struggle because real tasks often lack ground truth, task specific edits may not transfer, and directly reusing a highly tailored harness can introduce noise as conditions shift.

The authors introduce Harness2, a plug and play framework for recursive agent harnessing. It uses task level recursion to improve the harness for the current task through a contrastive Propose, Probe, and Compose step that tests candidate edits using behavioral contrasts rather than ground truth. It also uses harnessing level recursion to learn from those refinement episodes, storing reusable components and lessons about why changes worked so future harness updates can be better targeted.

Method

The authors introduce Harness2, a plug-and-play framework for recursive agent harnessing in an open world. Harnessing refers to the process of optimizing the runtime scaffolding around a frozen base model to enable it to act as an autonomous agent. The framework improves the harness for the current task and extracts lessons from that process to guide future harnessing through two coupled levels of recursion.

Harness Configuration and Setting Let $M$M be a model with frozen parameters. A harness $\mathcal{H} = (c^1, \ldots, c^K)$H=(c1,…,cK) consists of $K$K editable components. It composes with $M$M to form an agent $A(\cdot; M, \mathcal{H})$A(⋅;M,H) without changing its weights. The execution harness adopts a file-level decomposition, exposing $K=8$K=8 components: a system prompt, guardrails, memory, skills, tool guidance, scripts, subagents, and a middleware plugin. Each component is mounted as a file in the runtime.

Recursive Agent Harnessing Pipeline Recursive agent harnessing couples two recursive updates. Task-level recursion refines the current execution harness using generated harnesses and execution evidence, while harnessing-level recursion updates the improvement harness that guides this refinement. The execution harness is the system being improved, and the improvement harness is the mechanism that improves it.

Task-Level Recursion Task-level recursion aims to improve the execution harness for the current task. To overcome the absence of ground-truth feedback in an open-world setting, the authors introduce a contrastive improvement step consisting of Propose, Probe, and Compose.

Let $e = (\tau, y)$e=(τ,y) denote an execution record with trajectory $\tau$τ and deliverable $y$y. The step applies an improvement operation $\Phi$Φ to the current execution harness $\mathcal{H}$H and the available task-local execution and improvement history $\mathcal{E}$E:

$$(\mathcal{H}', e', \xi) = \Phi(q_t, \mathcal{H}, \mathcal{E}; \mathcal{R}_t).$$(H′,e′,ξ)=Φ(qt​,H,E;Rt​).

It returns a successor harness $\mathcal{H}'$H′, its execution record $e'$e′, and a step record $\xi$ξ.

• Propose: The pipeline first obtains a reference execution $e^0 \sim \mathcal{A}(q_t; M, \mathcal{H})$e0∼A(qt​;M,H). Conditioned on the task, current harness, reference, earlier history, and library in $\mathcal{R}_t$Rt​, the pipeline proposes two candidates: an invariant candidate targeting agentic deficiencies such as planning and tool use, and a domain-specific candidate targeting the knowledge and constraints of the current domain.
• Probe: Each candidate harness is executed on the same task under matched configurations. Comparing its trajectory and deliverable with the reference execution yields a behavioral contrast, providing evidence of whether the edits mitigate the targeted deficiency or introduce regressions.
• Compose: The pipeline reads the reference, candidate harnesses, their diffs, and all available evidence to form the successor $\mathcal{H}'$H′. Composition is selective, merging supported changes or preserving the current harness based on concrete observations.

Building on this contrastive step, the authors introduce two forms of task-level recursion controlled by an exploration budget $k$k.

• Parallel Recursion: The pipeline collects $k$k reference executions, then independently proposes and probes $k$k invariant and $k$k domain-specific candidates. Each of $k$k independent composition sessions receives the full pool of candidates and reference executions to produce a successor $\mathcal{H}'_j$Hj′​:

$$\mathcal{H}'_j = \text{COMPOSE}_j(q_t, \mathcal{H}, \mathcal{B}, \mathcal{P}; \mathcal{R}_t), \quad j = 1, \dots, k.$$Hj′​=COMPOSEj​(qt​,H,B,P;Rt​),j=1,…,k.

• Sequential Recursion: Starting from $\mathcal{H}^{(0)} = \mathcal{H}_0$H(0)=H0​, it chains $k$k contrastive steps, each conditioned on the preceding harness and accumulated execution history $\mathcal{E}^{(r-1)}$E(r−1):

$$(\mathcal{H}^{(r)}, e^{(r)}, \xi^{(r)}) = \Phi(q_t, \mathcal{H}^{(r-1)}, \mathcal{E}^{(r-1)}; \mathcal{R}_t), \quad r = 1, \dots, k.$$(H(r),e(r),ξ(r))=Φ(qt​,H(r−1),E(r−1);Rt​),r=1,…,k.

For $k > 1$k>1, an agentic selector compares anonymized deliverables against the task request to select the final harness $\mathcal{H}^\star_t$Ht⋆​. One contrastive step improves performance across benchmarks, and parallel recursion adds further gains as the budget $k$k grows.

Harnessing-Level Recursion Harnessing-level recursion uses the experience of refining the current execution harness to improve future harnessing. After each task, the pipeline updates the library within the improvement harness $\mathcal{R}_t$Rt​.

• Reflect on the Improvement Process: The pipeline reviews the complete improvement record $\mathcal{D}_t$Dt​, which includes reference executions, candidate harnesses, composition decisions, and the selected result. Reflection extracts lessons about which changes addressed observed deficiencies and under what conditions. Lessons are retained only when supported by execution contrasts.
• Update the Improvement Harness: The pipeline retains the adopted harness $\mathcal{H}^\star_t$Ht⋆​ and supported lessons in the harness improvement library:

$$\mathcal{R}_{t+1} = \text{UPDATE}(\mathcal{R}_t, \mathcal{H}^\star_t, \mathcal{D}_t).$$Rt+1​=UPDATE(Rt​,Ht⋆​,Dt​).

Each library entry contains an executable harness and an experience record. An index enables subsequent sessions to inspect relevant entries on demand.

• Reuse in Subsequent Improvement: The next task starts from the common execution harness $\mathcal{H}_0$H0​, but refinement is guided by the updated improvement harness $\mathcal{R}_{t+1}$Rt+1​. Earlier components are selectively reused or adapted. Libraries accumulated with a larger recursion budget support stronger subsequent harness edits, and experience transferred across benchmarks improves performance.

Experiment

the paper evaluate the approach across professional task benchmarks, two executor models, and two harness settings, comparing it against fixed, retrieval-based, offline optimized, and per-instance scaling baselines. The results show that a single harness improvement step consistently enhances performance, with weaker executors often gaining more and task-level recursion providing additional but non-uniform improvements across harnesses. Further analyses attribute the gains to recursive refinement, favorable compute-performance tradeoffs, the improvement library, scoped editing, and composition, while also demonstrating cross-benchmark reuse and self-improvement without requiring a stronger editor.

Across the evaluated models and initial harnesses, a single improvement step generally raises WorkBuddy-Bench domain scores, with GLM-5 showing larger absolute gains than Gemini 3.5 Flash. Parallel task-level recursion adds further improvements over the single step, while changing the difference between OpenCode and Codex in model-specific ways. A single improvement step improves average WorkBuddy-Bench scores for both Gemini 3.5 Flash and GLM-5 under both initial harnesses. Task-level recursion after the single step provides additional gains and can shrink OpenCode versus Codex gaps, but not uniformly across models.

Across JobBench and LAB, Harness2 improves over the base harness and many alternative methods under both OpenCode and Codex. Parallel task-level recursion adds further gains on JobBench scores and LAB partial pass rates, especially narrowing the gap between the two initial harnesses on JobBench. The improvement is not uniform, as some alternatives can reduce performance and one alternative can lead on LAB partial pass rate for Gemini under Codex. Harness2 raises JobBench scores over the base harness for both initial harnesses. Recursion extends gains beyond a single harness update on JobBench and LAB. Initial harness differences persist but are reduced on JobBench after recursion.

The full Harness2 configuration outperforms all ablated variants on both WorkBuddy-Bench and JobBench. Removing scoped candidates causes the clearest weakness on JobBench, while removing the library and composition also reduces performance across the two benchmarks. The complete configuration gives the best results among the compared ablations. Scoped candidates appear especially important on JobBench, where excluding them lowers performance noticeably. The library and composition each contribute to the final performance, as removing either reduces scores relative to the full setup.

Across WorkBuddy-Bench, JobBench, and LAB, Harness2 generally improves performance over the base harness and several alternatives, with a single improvement step raising benchmark scores and task-level recursion providing further gains. These improvements reduce, but do not eliminate, differences between initial harnesses such as OpenCode and Codex, showing that gains are robust yet model and harness dependent. Ablations indicate that the full Harness2 design is most effective, while removing scoped candidates, library components, or composition mechanisms lowers performance.