HELIX: Model-Harness Co-evolution for Recursive Self-Improvement

Tianyu Fan; Chao Huang

cs.AIAug 14, 2026

HELIX: Model-Harness Co-evolution for Recursive Self-Improvement

Authors: Tianyu Fan, Chao Huang

Organizations: In3 Lab, The University of Hong Kong

Abstract

Scaling agent capability has largely focused on improving the model, yet an interactive agent acts through a runtime harness that mediates context, tools, control flow, and stopping. The harness shapes both what a model can accomplish and the trajectories from which it learns. This coupling motivates model-harness co-evolution for recursive self-improvement: build harnesses for a fixed model, update the model from verified sibling trajectories, and rebuild the harnesses as model capabilities change. Realizing this loop requires a controlled way to evolve harnesses while preserving intervention identity and effect. We present HELIX, a source-traceable substrate for harness evolution. HELIX decomposes agent systems into typed ports, reusable atoms, recipes, product shells, and runtime policies. It makes interventions explicit and auditable while retaining trajectories, test outcomes, and provenance. Harness evolution thus serves two linked roles: improving fixed-model execution and producing matched successes, regressions, near misses, and alternative solutions as data for subsequent model improvement. We evaluate HELIX in one evolution round on code repair. A 65-candidate portfolio discovers a fixed harness that improves task coverage by 4.0% over Pi, while the full portfolio exposes up to 58.0% more verified coverage through complementary sibling behavior. Selected candidates are assessed with repeated runs and the SWE-bench evaluator. A 200-slot sibling slice yields 438 verified SFT, critic, filter, and preference records. These results show how harness, model, and data form a feedback system: harness evolution expands current capability and creates learning signal for the next model; model updates motivate the next round of harness evolution. HELIX provides an auditable interface for studying this recursive process. Code is available at https://github.com/HKUDS/HELIX.

Figures & tables

Figure 1: Two timescales of model–harness recursive improvement. Within a task,

H_{i}

supplies context, tool results, permissions, and control decisions to

M_{t}

, while

M_{t}

returns messages and actions. Across rounds, verified sibling trajectories supply the update signal for

M_{t+1}

, whose changed capability profile conditions the next harness rebuild.

Figure 2: HELIX architecture. Source-derived behavior is represented behind stable ports and assembled into declared runtime candidates. Solid arrows show executable assembly; dashed paths show derived or explicitly applied evidence. The figure distinguishes unique atom identifiers from contract-expanded occurrences.

Verified pattern	Export	Data Description
Resolved, path-clean, minimal patch	Clean SFT example	A concise successful trajectory/trace.
Resolved versus regression, target miss, or no action	Critic example; outcome preference	why local progress is not sufficient for task resolution.
Clean versus noisy resolved siblings	Filter example/preference pair for a certain scenario	Separate solution correctness from artifact quality.
Different clean resolutions	Alternative SFT examples; minimality/cost preference	Preserve solution diversity while preferring a smaller or cheaper trajectory.

Table 1: Evidence-linked siblings support multiple learning objectives. The benefit is not a particular export format: intervention identity and outcome evidence remain attached as the same rollouts are reused for SFT, critic, filter, or preference learning.

Figure 3: The complete 65-candidate distribution is shown. Bars show trace-strict fixed-candidate coverage under one attempt per task and are sorted only for display. Pi solves 50/100 tasks, two candidates exceed it, and the 23 zero-score non-baseline candidates are marked along the axis. The 79/100 post-hoc union is portfolio coverage, not the score of another fixed candidate.

Case	Matched contrast	Why it is useful
SWE sphinx-10673	Pi 0/2; other siblings 7/8 resolved; selected gap patch 6,661 bytes vs. resolved patch 758 bytes	A baseline-miss/sibling-hit contrast that links candidate complementarity to a clean official-evaluator positive.
SWE pytest-5787	Matrix 2 resolved / 8 gaps; selected Pi patch passes 2/2 F2P but fails two P2P tests, selected sibling passes both sets	Shows why target-test success alone is an unsafe positive and supplies a regression-aware critic/preference pair.
SWE xarray-6461	Matrix 9 resolved / 1 gap; same OpenCode shell/tools and attempt index, Pi config yields an 837-byte gap while OpenCode config yields a 778-byte resolve	Both patches are single-file, production-only, path-clean, and regression-free; the observed hygiene is held constant while semantic outcomes differ.
LCB v6-025-abc391-f	Trace-strict: Pi 0/10 vs. OpenCode session/hooks/config/tools 4/10; first candidate success at attempt 2	Representative candidate repairs after two failed bash calls, rewrites, then executes a passing verifier: a supporting closure path.
LCB v6-088-arc191-d	Trace-strict: Pi 7/10 vs. the two recompositions 2/10 and 4/10	Both substitutions regress on the same task, preventing a monotonic “more active harness is better” story.

Table 2: Cases drawn from selected-member validation matrices. Selection deliberately includes gains, losses, semantic near misses, and regression evidence. Counts are descriptive outcomes from non-deterministic rollouts, not single-factor causal estimates.

Output dataset	Records	Share of 438
Clean SFT	63	14.38%
Cleanup-needed SFT	56	12.79%
Critic negatives	52	11.87%
Filter samples	113	25.80%
Preference pairs	154	35.16%
Total multi-purpose rows	438	100.00%

Table 3: Verified training-data accounting from selected-member SWE validation. The export contains 438 derived rows, not 438 independent rollouts; one verified sibling can contribute to more than one objective.

Figure 4: Verified multi-purpose rows from the selected-member sibling slice. The audit maps verifier and patch-quality labels to more than clean SFT: failed, noisy, and alternative-success siblings supply critic, filter, and preference categories.

Appendix figures & tables4 assets

Supplementary material from the paper’s appendix.

Appendix

Selected member	Tasks $\geq$ 1/10	Successful slots
Pi Mono	72/100	529/1,000
OpenCode session/hooks/config/tools; other modules Pi	75/100	549 /1,000
OpenCode session/hooks/tools; other modules Pi	75/100	546/1,000

Appendix

Table 4: Repeated-run validation of selected portfolio members. All LCB outcomes use trace-strict status. Tasks count at least one successful attempt out of ten; slots count successful attempts out of 1,000. “Pi core” denotes Pi prompt, turn loop, and acceptance; the third row also retains Pi config.

Selected member	Nonempty	Resolved slots	Gaps	Empty	Tasks $\geq$ 1/2
Pi Mono	108/110	81	27	2	44/55
Hermes session/hooks + Pi remainder	108/110	81	27	2	44/55
Hermes session/hooks/config + Nanobot tools + Pi core	109/110	80	29	1	44/55
OpenCode session/hooks/tools + Pi config/core	109/110	83	26	1	46/55
OpenCode session/hooks/config/tools + Pi core	109/110	86	23	1	46/55
Selected-member post-hoc union					49/55

Appendix

Table 5: Official-evaluator validation of selected portfolio members. Each member has two slots per task. “Resolved slots” counts successful attempts; the final column counts tasks with at least one resolved attempt. The union is portfolio coverage, not fixed-harness performance.

Trace stage	Pi baseline, attempt 1	Evolved sibling, attempt 1
Run identity	pi-mono ; 43 observed tool calls in 355 seconds.	OpenCode session/hooks/config/tools with Pi prompt/turn; 54 observed tool calls in 377 seconds.
Inspection	Searches for report serialization, then repeatedly reads src/_pytest/reports.py and src/_pytest/_code/code.py . It correctly identifies ExceptionChainRepr.chain as the missing information.	Reads the same implementation files and also inspects testing/test_reports.py , including the existing serialization contract that accesses top-level reprtraceback .
Patch	Changes only src/_pytest/reports.py (6,400 bytes). For a chained exception, it emits a new longrepr object containing only chain and sections .	Changes src/_pytest/_code/init.py and src/_pytest/reports.py (6,854 bytes). It exports ExceptionChainRepr , preserves reprcrash , reprtraceback , and sections , and adds the full chain .
In-rollout checks	Writes a custom chained-exception script and observes successful round trips. Attempts to run repository tests stop at the local environment guard requires pytest-2.0 ; the compatibility tests are therefore not closed inside the rollout.	Attempts testing/test_reports.py and encounters the same environment guard, then performs custom import and chain round-trip checks. These checks exercise the new path but do not substitute for the official regression set.
Official targets	Both FAIL_TO_PASS tests pass (2/2).	Both FAIL_TO_PASS tests pass (2/2).
Official regressions and label	121/123 PASS_TO_PASS tests pass. The two failures, test_xdist_longrepr_to_str_issue_241 and test_deserialization_failure , raise KeyError: reprtraceback . Label: gaps-found ; data role: regression-aware critic negative.	123/123 PASS_TO_PASS tests pass. Label: resolved ; data role: clean positive and preference winner.

Appendix

Table 6: Condensed Pytest paired trace. Both patches solve the target, but only the evolved sibling preserves the pre-existing serialization schema.

Trace stage	Pi-config sibling, attempt 2	OpenCode-config sibling, attempt 2
Run identity	24 observed tool calls in 130 seconds; 837-byte patch.	27 observed tool calls in 122 seconds; 778-byte patch.
Diagnosis	Locates where() in xarray/core/computation.py , traces attribute collection through apply_ufunc , and reproduces the IndexError for scalar x with keep_attrs=True .	Locates the same expression and reproduces the same IndexError .
Patch	If attrs[1] is unavailable, falls back to attrs[0] when present, which can be the condition’s attributes.	If attrs[1] is unavailable, returns an empty dictionary because scalar x has no attributes to preserve.
In-rollout checks	Runs several direct Python examples and reports them as passing; its scalar example uses an attribute-empty condition. The repository test command cannot run because that interpreter has no pytest module.	Runs direct Python examples covering scalar and DataArray inputs and reports them as passing. The repository test command encounters the same missing pytest module.
Official target	The added test_where_attrs case uses condition attributes {’attr’: ’cond’} and scalar x . The patch returns those condition attributes instead of {} , so FAIL_TO_PASS is 0/1.	The same test receives {} as required, so FAIL_TO_PASS is 1/1.
Official regressions and label	247/247 PASS_TO_PASS tests pass. Label: gaps-found ; data role: clean semantic negative.	247/247 PASS_TO_PASS tests pass. Label: resolved ; data role: clean positive and preference winner.

Appendix

Table 7: Condensed Xarray paired trace. Patch hygiene and local examples are matched; the official target isolates the fallback semantic that separates the near miss from the resolved patch.

LLM Agent Harnesses

LLM agent harnesses are the software and runtime systems that organize an agent’s tools, context, state, execution, and safeguards.

See all 387 papers

Jun 12, 2026

HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry

AI agent performance depends critically on the runtime harness, comprising the prompts, tools, memory, and control flow that mediate how a model observes, reasons, and acts. Yet today's harnesses remain largely hand-crafted and static: each new model or task still demands bespoke scaffolding, and the rich traces produced during execution are rarely distilled back into systematic improvement. We introduce HarnessX, a foundry for composable, adaptive, and evolvable agent harnesses. HarnessX assembles typed harness primitives via a substitution algebra, adapts them through AEGIS, a trace-driven multi-agent evolution engine grounded in an operational mirror between symbolic adaptation and reinforcement learning, and closes the harness-model loop by turning trajectories into both harness updates and model training signal. Across five benchmarks (ALFWorld, GAIA, WebShop, tau^3-Bench, and SWE-bench Verified), HarnessX yields an average gain of +14.5% (up to +44.0%), with gains largest where baselines are lowest. These results suggest that agent progress need not come from model scaling alone: composing and evolving runtime interfaces from execution feedback is an actionable and complementary lever. The complete codebase will be open-sourced in a future release.

Tingyang Chen, Shuo Lu, Kang Zhao +11

Darwin Agent Team

LLM Agent Orchestration Agent Harness Optimization LLM Agent Workflow Optimization LLM Agent Self-Improvement LLM Agent Harnesses Self-Evolving Agents

Ask PDF

Jul 17, 2026

Recursive Harness Self-Improvement

Under model--harness co-evolution, harnesses are not merely inference-time scaffolds but data-generating components whose execution traces can shape future foundation models. This motivates harness-in-the-loop learning: optimizing harnesses for both immediate agent performance and the quality of traces used for future model training. However, continually updating provider-built scaffolds is costly and labor-intensive. We therefore investigate whether optimizing user-constructed harnesses in a task-specific manner can improve execution-trace quality while remaining computationally lightweight and requiring only a few update iterations. To this end, we introduce Recursive Harness Self-Improvement (RHI), which represents the harness as a prompt-level specification of the agent loop and iteratively refines it using pairwise feedback over its own revision history. Across 30 synthetic machine-learning research tasks spanning quantitative finance, robotics, and pharmacy, a few RHI iterations suffice to substantially raise the performance ceiling of low-reasoning-effort agents, exceeding the corresponding maximum-reasoning-effort setting while reducing inference cost by up to 60%. We show that these gains arise primarily from improved task-specific context management through more effective inter-agent information flow rather than longer reasoning traces. Finally, we formalize this behavior as an information-theoretic hypothesis for RHI's implicit optimization objective, suggesting RHI as a practical algorithm for continual learning within the paradigm of model--harness co-evolution.

Hyunin Lee, Jinglue Xu, Jeffrey Seely +3

1Sakana AI, 2UC Berkeley

Continual Learning for LLM Agents Agent Harness Optimization LLM Agent Self-Improvement Prompt Optimization LLM Agent Harnesses

Ask PDF

Sep 29, 2026

Self-Evolving Harness on Multiple Tasks with the Agent as Its Own Optimizer

A harness is the code around a language-model agent that organizes prompts, calls tools, manages context, and controls execution. As models grow stronger, recent work has begun to let agents improve their own harnesses, a line of work known as self-evolving harnesses. In most existing methods, a separate proposer running on a human-designed harness modifies the solver's harness, and a separate harness is evolved for each benchmark. Real-world tasks come from many domains, so both the evolution and the evaluation of a harness should cover a diverse range of tasks. We propose a framework close to recursive self-improvement: the same frozen model, on the same version of the harness, first solves tasks as the solver and then, as the proposer, reads the complete run records and directly edits the harness that runs it. Each evolution batch draws tasks from five benchmarks in different domains. To measure generalization, training and held-out tasks are strictly separated, and we additionally evaluate on five out-of-distribution benchmarks never used during evolution. We frame the evolution process as deep-learning training with two stages, multi-task pretraining and continual training. Starting from a 49-line seed harness, the harness obtained at the end of the first stage improves the average score by 4.48 points on the in-distribution benchmarks and by 12.64 points on the out-of-distribution benchmarks, surpassing Codex on the former and matching it on the latter. In the second stage, continued evolution on Claw-Eval, one of the out-of-distribution benchmarks, further raises the score on that benchmark from 66.17 to 68.06, exceeding Codex. We also provide an in-depth analysis of the mechanisms that emerged during evolution, including output truncation, history compaction, and independent review.

Qiankai Xu

Nanjing University

Continual Learning for LLM Agents AI Agent Evaluation Agent Harness Optimization LLM Agent Workflow Optimization LLM Agent Self-Improvement

Ask PDF

Abstract

LLM Agent Harnesses

Explore similar work

HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry

Recursive Harness Self-Improvement

Self-Evolving Harness on Multiple Tasks with the Agent as Its Own Optimizer