LLM agents’ capabilities depend not only on their underlying models but also on their execution harnesses. Recursive self-improvement (RSI) offers a promising approach to automatically evolve these harnesses. However, deploying RSI in open-world settings still faces two critical challenges. First, open-world tasks are typically unseen during the harness design phase and novel at test time, leaving no ground-truth verifiers to reliably guide online harness edits. Second, the RSI process remains highly task-specific and fails to generalize to novel scenarios. We introduce Harness2, a plug-and-play, recursive agent harnessing framework that addresses these challenges through two connected levels of recursion. Task-level recursion refines the current task’s harness using a contrastive Propose–Probe–Compose step that reliably guides edits without ground-truth verifiers, and can be scaled further via parallel or sequential recursion. Harnessing-level recursion then extracts experience from these edits to update a continual improvement harness, enabling the agent to better adapt to future tasks. Across three professional benchmarks and four model–harness configurations, a single step consistently improves GLM-5 and Gemini 3.5 Flash over their base harnesses, yielding gains of up to 11.5 points on WorkBuddy-Bench, 4.5 points on JobBench, and 11.8 percentage points on LAB, with further gains as the task-level recursion budget increases.
\nAn LLM agent’s effectiveness depends not only on its underlying model, but also on its harness: the prompts, memory, skills, tools, and orchestration through which the model performs tasks (OpenAI, 2025; SST, 2024; Weng, 2026). Even a strong model can perform substantially differently under different harnesses (Team et al., 2026). As agents expand beyond coding into office workflows and high-stakes domains such as legal work, harness design must accommodate increasingly diverse tasks and operational requirements (Team et al., 2026; Harvey AI, 2026). Manually designing and refining harnesses for these demands requires repeated engineering effort, motivating recursive self-improvement on harness design (Lee et al., 2026b; Lin et al., 2026; Qian et al., 2026; Weng, 2026; Meng et al., 2026). Recursive self-improvement (RSI) pursues AI that improves AI: a system autonomously makes persistent changes to itself, and these changes further shape how later improvements are generated, evaluated, and retained (Duan et al., 2026).
\nEarly harness RSI methods (Lee et al., 2026b; Lin et al., 2026) focus on optimizing candidate components against fixed training tasks, unit tests, or validation feedback, selecting the best configuration before deployment. However, a static harness selected beforehand often fails to generalize to the diverse, unpredictable environments encountered in the open world (Wang et al., 2026a), a dynamic setting where agents continually encounter new tasks with diverse and evolving requirements. To address this, researchers have moved harness RSI to the open world, allowing systems to dynamically adapt to newly arriving tasks. Current open-world methods typically address this by recursively improving a harness for the current task (Lee et al., 2026a; Wang et al., 2026a), or by carrying a successful execution harness forward across successive task batches (Nie et al., 2026b).
\nHowever, open-world harness evolution faces two connected challenges. First, tasks typically lack ground-truth labels or reliable verifiers. While existing methods rely on proxy signals, assumed ground truth answers, or pairwise output judgments (Lee et al., 2026a; Nie et al., 2026b; Liu et al., 2026), safely using imperfect execution evidence to guide harness changes remains difficult. Second, improving a harness for one task does not automatically improve how the next task is refined. Task-specific edits often fail when requirements change, and directly inheriting a highly tailored execution harness can cause noisy recursive improvement as task distributions shift. The refinement process itself, however, produces highly reusable experience: how a weakness is diagnosed, which changes are tested, and what their execution reveals. Therefore, the improvement process itself must become a source of learning, enabling the system to recursively upgrade its own refinement mechanism. This leads to our central question:
\nCan recursive self-improvement improve both the current harness
\nand how future harnesses are improved?
\nTo this end, we introduce Harness2, a plug-and-play framework for recursive agent harnessing in an open world. We use harnessing to describe the process of optimizing the runtime scaffolding around a frozen base model to enable it to act as an autonomous agent. Harness2 improves the harness for the current task and extracts lessons from that process to guide future harnessing. It implements these updates through two coupled levels of recursion: ❶ Task-level recursion refines the current task’s execution harness. To overcome the absence of ground-truth feedback, we introduce a contrastive Propose–Probe–Compose step: it proposes harness edits, tests their effects under matched conditions, and composes changes supported by behavioral contrasts. Building on this, parallel recursion explores multiple candidates simultaneously and composes changes from their execution evidence, while sequential recursion builds successive revisions iteratively. ❷ Harnessing-level recursion uses the resulting task-level explorations to update a continual improvement harness. Instead of inheriting the previous execution harness, this improver selectively retains reusable components and lessons about when and why they worked, guiding future proposals and composition.
\nWe evaluate Harness2 on WorkBuddy-Bench, JobBench, and Harvey’s Legal Agent Benchmark (Team et al., 2026; Li et al., 2026; Harvey AI, 2026) across four executor–harness configurations. One contrastive step improves performance on all three benchmarks in every configuration, with gains of up to 11.511.5 points on WorkBuddy-Bench, 4.54.5 points on JobBench, and 11.811.8 percentage points in LAB Partial pass rate. Parallel recursion adds up to 3.93.9 points on WorkBuddy-Bench, 4.24.2 on JobBench, and 6.76.7 percentage points on LAB Partial (Figure 1); the budget study shows gains from both parallel and sequential recursion. Importantly, task-level exploration also benefits subsequent harnessing. Libraries accumulated with a larger recursion budget support stronger subsequent harness edits even without additional probing, and a library transferred from JobBench improves performance on WorkBuddy-Bench (Figure 7). Our contributions are threefold:
\n①
Recursive agent harnessing:\nHarness2 refines the current execution harness and learns from the\nrefinement process to guide future harnessing.
②
Task-level recursion without ground-truth feedback:\nWe introduce a contrastive Propose–Probe–Compose step that supports\nboth parallel and sequential recursion.
③
Experimental results:\nWe demonstrate consistent gains across three benchmarks and four\nexecutor–harness configurations, including settings where the same\nmodel serves as both executor and editor.
Refer to caption
\nFigure 2: The eight harness components in Harness2, grouped by their role in the runtime.
\nWe first define recursive agent harnessing and its open-world setting\n(§2.1). We then present task-level recursion for refining\nthe execution harness (§2.2), followed by\nharnessing-level recursion for updating the improvement harness across\ntasks (§2.3).
\nHarness Configuration and Setting.\nLet ℳ\\mathcal{M} be a model with frozen parameters. A harness\nℋ=(c1,…,cK)\\mathcal{H}=(c^{1},\\ldots,c^{K}) consists of KK editable components,\nwith cic^{i} denoting component i∈{1,…,K}i\\in{1,\\ldots,K}. It\ncomposes with ℳ\\mathcal{M} to form an agent\n𝒜(⋅,ℳ,ℋ)\\mathcal{A}(\\cdot;\\mathcal{M},\\mathcal{H}) without changing its\nweights (Lee et al., 2026b; Huang et al., 2026b; Qian et al., 2026).\nFor the execution harness, we adopt the file-level decomposition of\nAHE (Lin et al., 2026) and extend it by one component, exposing\nK=8K=8 components: a system prompt,\nguardrails, memory, skills, tool guidance, scripts, subagents, and a\nmiddleware plugin. Each component is mounted as a file in the runtime.\nFigure 2 shows their runtime roles, and\nTable 5 in Appendix D.3 lists their\nfiles, activation, and definitions. We study harness evolution over a\nstream of NN open-world tasks q1,…,qNq_{1},\\ldots,q_{N}, without ground-truth\nanswers or labeled validation feedback.\nEach task starts from the common execution harness ℋ0\\mathcal{H}_{0}.\nThe pipeline may rerun the current task within a bounded budget before\nreturning its final deliverable.
\nRecursive Agent Harnessing.\nRecursive self-improvement (RSI) is the capability of an AI system to turn\nexecution outcomes and internal reflections into persistent changes to\nitself, such that these changes also affect how later improvements are\ngenerated, evaluated, and retained (Duan et al., 2026). The object of such\nchanges varies: model weights, as in self-rewarding language\nmodels (Yuan et al., 2024); improvement programs, as in\nSTOP (Zelikman et al., 2024); and agent code, as in the Darwin\nGödel Machine (Zhang et al., 2026b). The agent harness can be such an\nobject as well. It is the system surrounding a base model that enables\nit to act as an autonomous agent\n(Agent=Model+Harness\\text{Agent}=\\text{Model}+\\text{Harness}), without changing the\nmodel weights (Weng, 2026). We call the process of optimizing\nthis layer harnessing. Rather than only revising an execution harness under\na fixed improvement procedure (Lee et al., 2026a; Lee et al., 2026b),\nwe also update the harness guiding future revisions:
\nDefinition: Recursive Agent Harnessing
\nRecursive agent harnessing couples two recursive updates:\ntask-level recursion refines the current execution harness\nusing generated harnesses and execution evidence;\nharnessing-level recursion updates the improvement harness\nthat guides this refinement, using adopted harnesses and\nimprovement experience after each task to inform subsequent\nrefinement.
\nRecursive agent harnessing thus extends the model–harness view\nfrom an agent that executes tasks to an agent that also learns\nhow to improve its harness: the execution harness is the system\nbeing improved, and the improvement harness is the mechanism\nthat improves it. In Harness2, as shown in Figure 3, the\nexecution harness is refined for the\ncurrent task, while the continual improvement harness\nsupports refinement across tasks. The improvement harness\nremains fixed during task-level recursion and is updated\nafterward through its harness improvement library.\nThis library retains adopted harnesses together with lessons\nfrom their refinement, making both available for reuse and\nadaptation in subsequent proposals and composition.
\nTask-level recursion aims to improve the execution harness for the\ncurrent task. The challenge in our open-world setting is to guide\nrevisions without ground-truth feedback. We therefore introduce a\ncontrastive improvement step that proposes changes, executes\nthem, and examines their behavioral consequences. Building on this\nstep, parallel and sequential recursion use the generated harnesses\nand execution evidence for further refinement.
\nRefer to caption
\nFigure 3: The Harness2 pipeline. Task-level recursion proposes invariant and\ndomain-specific harness edits, probes their effects, and composes a successor\nexecution harness. After each task, harnessing-level recursion updates the\nimprovement harness with reusable harnesses and lessons from the refinement\nprocess.
\nA contrastive step consists of Propose, Probe, and\nCompose. Let e=(τ,y)e=(\\tau,y) denote an execution record, with\ntrajectory τ\\tau and deliverable yy. The step applies an improvement\noperation Φ\\Phi to the current execution harness ℋ\\mathcal{H} and\nthe available task-local execution and improvement history ℰ\\mathcal{E}:
\n| (ℋ′,e′,ξ)=Φ(qt,ℋ,ℰ,ℛt).(\\mathcal{H}^{\\prime},e^{\\prime},\\xi)=\\Phi(q_{t},\\mathcal{H},\\mathcal{E};\\mathcal{R}_{t}). | (1) |
It returns a successor harness ℋ′\\mathcal{H}^{\\prime}, its execution record\ne′e^{\\prime}, and a step record ξ\\xi containing the reference executions,\ncandidate harnesses and probes, composition decisions, and successor\nexecution. The model and environment are omitted because they stay\nunchanged; the improvement harness ℛt\\mathcal{R}_{t} also remains fixed\nthroughout the task.
\nPropose.\nThe pipeline first obtains a reference execution\ne0∼𝒜(qt,ℳ,ℋ)e^{0}\\sim\\mathcal{A}(q_{t};\\mathcal{M},\\mathcal{H}).\nHere ∼\\sim denotes sampling an execution from the agent. The reference reveals how the\nharness behaves, not whether its deliverable is correct. Conditioned on\nthe task, current harness, reference, earlier history, and library in\nℛt\\mathcal{R}_{t}, the pipeline proposes two candidates. The\ninvariant candidate targets agentic deficiencies that may recur\nacross domains, such as planning, tool use, context management, or\ndelegation. The domain-specific candidate targets the knowledge,\nprocedures, and constraints of the current domain or environment.\nEach candidate is an executable harness obtained by editing the current\nharness’s component files. Proposals may reuse or adapt\nexisting harness components from the library, but task-specific facts\nmust be checked against the current task’s evidence.
\nProbe.\nEach candidate harness is executed on the same task under matched\nmodel and environment configurations. Comparing its trajectory and\ndeliverable with those of the reference execution yields a\nbehavioral contrast, providing evidence of whether the edits\nmitigate the targeted deficiency, leave the relevant behavior unchanged,\nor introduce regressions. These contrasts inform subsequent composition\nrather than verify task correctness, as execution stochasticity and\nshared model biases limit the reliability of the evidence.
\nCompose.\nThe pipeline reads the reference, candidate harnesses, their diffs\nagainst the current harness, and all available task-local execution\nevidence to form the successor ℋ′\\mathcal{H}^{\\prime}.\nComposition is selective: it may merge supported changes, revise\nconflicting edits, adopt one candidate, or preserve the current harness.\nEach decision is tied to a concrete observation rather than a presumed\nscore gain. The composed harness is then executed to produce e′e^{\\prime},\nand the decisions and their evidence are recorded in ξ\\xi.\nThe step therefore returns an executed successor together with the\nevidence and decisions behind its refinement.
\nRefer to caption
\nFigure 4: Two forms of task-level recursion.\n(a) Parallel recursion probes multiple candidates and independently\ncomposes successor harnesses. (b) Sequential recursion carries each refined harness and\naccumulated execution evidence into the next step.
\nBuilding on the contrastive improvement step, we introduce two\nforms of task-level recursion (Figure 4): parallel recursion composes\nrefinements from multiple candidate harnesses and their executions,\nwhile sequential recursion carries the refined harness and\nexecution evidence into subsequent steps. A positive integer kk\ncontrols the exploration budget: kk candidates per scope and\nkk compositions in parallel, or kk chained steps in sequence.\nThe improvement harness ℛt\\mathcal{R}_{t} remains fixed throughout.
\nParallel Recursion.\nParallel recursion follows the aggregation principle of RSA (Venkatraman et al., 2025), but operates on executable\nharnesses and their behavioral consequences rather than reasoning\noutputs. The pipeline collects kk reference executions of the current\nharness ℋ\\mathcal{H}, then independently proposes and probes\nkk invariant and kk domain-specific candidates. Let ℬ\\mathcal{B}\ndenote the reference executions and 𝒫\\mathcal{P} the pool of\ncandidate harnesses paired with their execution records.\nEach of kk independent composition sessions receives the full pool:
\n| ℋj′=Composej(qt,ℋ,ℬ,𝒫;ℛt),j=1,…,k.\\mathcal{H}^{\\prime}{j}=\\textsc{Compose}{j}(q_{t},\\mathcal{H},\\mathcal{B},\\mathcal{P};\\mathcal{R}_{t}),\\qquad j=1,\\ldots,k. | (2) |
Each session selectively combines or revises supported edits to\nproduce a successor ℋj′\\mathcal{H}^{\\prime}_{j}, which is then executed.\nThe recursive update thus uses generated harnesses and execution\nevidence for further refinement, not merely output ranking.\nOur implementation performs one population update; kk controls\nits width rather than its depth.
\nSequential Recursion.\nSequential recursion applies iterative self-refinement\n(Madaan et al., 2023) to the execution harness.\nStarting from ℋ(0)=ℋ0\\mathcal{H}^{(0)}=\\mathcal{H}_{0}, it chains kk\ncontrastive steps, each conditioned on the preceding harness\nand accumulated execution history ℰ(r−1)\\mathcal{E}^{(r-1)}:
\n| (ℋ(r),e(r),ξ(r))=Φ(qt,ℋ(r−1),ℰ(r−1);ℛt),r=1,…,k.(\\mathcal{H}^{(r)},e^{(r)},\\xi^{(r)})=\\Phi(q_{t},\\mathcal{H}^{(r-1)},\\mathcal{E}^{(r-1)};\\mathcal{R}_{t}),\\qquad r=1,\\ldots,k. | (3) |
Here, Φ\\Phi is the contrastive step defined in\nEquation 1, returning the refined harness,\nits execution record e(r)e^{(r)}, and the step record ξ(r)\\xi^{(r)}.\nThe initial history contains kk base executions and is extended\nafter each step with ξ(r)\\xi^{(r)}. Later steps can therefore retain,\nrevise, or correct earlier changes using both current and\nprevious evidence.
\nFinal Selection.\nFor k>1k>1, an agentic selector compares anonymized deliverables\nagainst the task request and source materials. It returns an\nexisting output without access to its originating harness or\nsynthesizing new content. The corresponding harness is denoted\nℋt⋆\\mathcal{H}_{t}^{\\star}, where the star indicates adoption rather\nthan verified optimality. Selection adds no harness revision.\nAt k=1k=1, both forms reduce to the basic contrastive step and\nbypass selection. Appendix H provides the stage prompts.
\nHarnessing-level recursion uses the experience of refining the\ncurrent execution harness to improve future harnessing. After each\ntask, the pipeline updates the library within the improvement\nharness ℛt\\mathcal{R}_{t}, making adopted harnesses and lessons from\ntheir refinement available to subsequent tasks.
\nReflect on the Improvement Process.\nAfter returning the deliverable, the pipeline reviews the complete\nimprovement record, denoted by 𝒟t\\mathcal{D}_{t}. This record includes\nreference executions, candidate harnesses and probes, composition\ndecisions, and the selected result. Reflection extracts lessons\nabout which changes addressed the observed deficiencies, under\nwhat conditions, and with what consequences. Lessons are retained\nonly when supported by execution contrasts; selecting an output\nalone does not establish transferability.
\nUpdate the Improvement Harness.\nThe pipeline retains the adopted harness ℋt⋆\\mathcal{H}_{t}^{\\star}\nand supported lessons in the harness improvement library.\nWe summarize reflection and the resulting library update as
\n| ℛt+1=Update(ℛt,ℋt⋆,𝒟t).\\mathcal{R}{t+1}=\\textsc{Update}(\\mathcal{R}{t},\\mathcal{H}{t}^{\\star},\\mathcal{D}{t}). | (4) |
Each library entry contains an executable harness and an\nEXPERIENCE.md recording the applicable situation,\nlessons, and supporting evidence. An index enables subsequent\nsessions to inspect relevant entries on demand. Existing harnesses\nprovide components for direct reuse or adaptation, while the\naccompanying experience guides their application. When evidence\nis insufficient, reflection adds no new experience entry.\nAppendix D.2 describes the library organization.
\nReuse in Subsequent Improvement.\nThe next task starts from the common execution harness\nℋ0\\mathcal{H}_{0}, but refinement is guided by the updated\nimprovement harness ℛt+1\\mathcal{R}_{t+1}. Earlier components are\nselectively reused or adapted through Propose, rather than\nautomatically inherited; accumulated experience also informs\nProbe and Compose. Model weights, stage instructions, and the\ndecision rule remain fixed, while the library evolves. Increasing task-level exploration produces additional execution\nevidence and composition decisions from which future harnessing\ncan learn. Figure 7 examines this connection using\nlibraries accumulated under different recursion budgets.
","headings":[{"level":1,"text":"Harness²: Recursive Agent Harnessing for an Open World","id":"harness2-recursive-agent-harnessing-for-an-open-world"},{"level":2,"text":"1 Introduction","id":"1-introduction"},{"level":2,"text":"2 Harness2","id":"2-harness2"},{"level":3,"text":"2.1 Recursive Agent Harnessing","id":"2-1-recursive-agent-harnessing"},{"level":3,"text":"2.2 Task-Level Recursion","id":"2-2-task-level-recursion"},{"level":3,"text":"2.3 Harnessing-Level Recursion","id":"2-3-harnessing-level-recursion"}]}}