Model training · Model–Harness co-evolution
InferenceNet challenges reveal capabilities that agents need to develop: understanding research requirements, interpreting data and constructing justified analyses. We explore model training and model–harness co-evolution as two routes to improvement. The three detailed harness methods and the current InferenceNet experiments keep model weights fixed.
Research directions
The task demonstrations across econometric replication and business analysis lead to four questions about the capabilities behind reliable agent work.
Understand the requested method and constraints, then carry them into sample selection, model specification and statistical inference.
Use task materials and data evidence to identify what each observation represents, how variables are coded, and what units and groups mean.
Turn the research question into justified transformations, scaling and interactions. Check their meaning against the task and data, alongside checking that the code runs.
Reconcile rules and records across source documents, preserve live calculation formulas in spreadsheets, and verify that reports and workpapers agree before submission.
Well-specified tasks provide the background and data clues needed for these judgments. Ambiguous variable definitions and rubric edge cases also inform improvements to task design and evaluation.
01 / Model training
Study how supervised fine-tuning, distillation and reinforcement learning can teach models to interpret data, plan analyses, use tools and verify their work. Use verified training tasks and evaluate the learned capabilities on held-out tasks.
02 / Model–Harness co-evolution
Explore alternating model updates with improvements to planning, tools, context and evidence checks. Compare model-only, harness-only and joint changes on held-out tasks under the same evaluation conditions.
Phase 1 · Completed on Econometric Replication
Our current four-harness Dev100 comparison and the ModularRSI study below were conducted in Phase 1 on econometric replication tasks in InferenceNet’s run_python sandbox. ModularRSI evolved submission-policy hooks and statistical-audit feedback in LangGraph’s ToolNode, raising strict replication from 64% to 67% with GPT-5.6 Sol. The next step for Subtrack 1 is upgrading static text guidance to executable diagnostic hooks that automatically inspect sample attrition, collinearity drops, cluster granularity and unit scaling before final submission.
Phase 2 · Planned for Finance & HR (Harbor + Claude Code)
Subtrack 2 (Business Analysis & Deliverables) has not yet undergone harness optimization. Its tasks currently run on the Harbor (0.20.0) evaluation framework driving Claude Code (2.1.114), where pilot errors stemmed from missing Excel formulas, cross-file count mismatches and rubric misclassifications. We plan to adapt our modular harness hooks and evolution loop to the Harbor + Claude Code workflow—adding pre-submission readback checks for spreadsheet formulas (.xlsx), report-to-workbook consistency (.docx/.xlsx) and source-evidence indexing.
These are research directions. The InferenceNet ModularRSI study below evolves the harness on econometric replication tasks while keeping model weights fixed.
01 / Concept
Harness self-evolution, also called automatic harness optimization, means proposing, testing and keeping harness versions on the basis of feedback from the harness’s own runs. The three methods detailed on this page do this in offline rounds: an outer loop edits the harness between evaluations, and the model’s weights do not change. That is how these three work, not a limit of the idea. Other methods change the harness across a stream of tasks, during a single run or for each task instance, and some also train the weights; the research map below places them.
The language model and its weights. Within a controlled harness comparison, both versions use the same solving model. Separate searches may use different frozen solving or proposer models, and must be identified separately. Methods that train model weights are another branch on the research map.
The software that runs the model as an agent: the loop, tool definitions, how observations are shown, how context is kept, prompts, memory and when to stop. This is what the loop changes, as a whole or in parts.
The model running inside one harness version on one task. Its trajectories and outcomes are the evidence the loop learns from.
The libraries that implement the agent runtime. Our ModularRSI adaptation uses a pinned copy of DeepAgents, LangChain and LangGraph with scoped hook and source edits, while model weights and the evaluator remain fixed.
What the tools act on: tasks, data, files, sandboxes. It is held constant so that a change in score can be traced to the harness.
The scorer that grades finished runs. It decides which version looks better, so it is never among the things edited; methods differ in how much of its output the proposer may see.
The editable boundary must be recorded per method and release. All results below retain their original task split, budget caps and selection policy.
The six terms follow the Harness page, which also explains how harnesses such as DeepAgents and DeepSeek Harness, and extensions such as Superpowers, are built. This page is about improving a harness once it exists.
Research map · 2025–2026
Methods in the four lanes below run an agent, read feedback from those runs, edit part of the harness and keep some of the edits. They differ in when that happens: between rounds on a task set, across a stream of new tasks, within one continuing run, or once per task instance. The lanes are alternatives, not stages of a history. Around them sit routes that change or describe something else: a branch that also trains model weights, systems that compose several harnessed agents, the representation a harness is written in, and the evaluation that scores it.
CompositionAbove the harness · coordinates several harnessed agents
Runs existing harness–model pairs, such as Codex, OpenCode and Pi, through rounds of planning, coding and independent testing, with a versioned project history. What improves is the software project, not the harness code.
arXiv 2609.01481v1 1 Sep 2026Code
A host agent turns a goal into a task graph and assigns each step to a model–harness specialist: Raven’s own, or third-party agents such as Claude Code and Codex. Memory and skills carry experience across tasks, and Raven’s own evolution component revises specialist harnesses, testing candidates with a frozen task model.
arXiv 2609.33439v1 27 Sep 2026
Both call runnable harnesses, which the Harness page maps:Harness systems, 2025–2026
Search and optimizationThe harness itself changes · the target model’s weights do not
The same task set runs again after each round of edits.
Feedback
Scores, traces and tests of earlier versions, or the agent’s own review
Edit
The target model, a separate coding agent, a trained editor or an optimizer edits part or all of the harness
Selection
Gates, regression tests, score frontiers, prediction checks or self-preference; the result is usually frozen before use
Repeats each round
Each new task is attempted once; edits land before the next tasks.
Feedback
Each attempt’s context: actions, outcome, feedback
Edit
A solver reflects; an evolver compiles general and topic skills into the harness
Selection
Lessons that transfer are kept and guide later tasks
Repeats after each batch
One continuing episode; the environment is never reset.
Feedback
Failure signatures in the latest stretch of the trajectory
Edit
The agent’s own model, as refiner, edits prompt, sub-agents, skills and memory in place
Selection
Edits take effect from the next step
Repeats every few steps
Before each new instance runs, with no search for that instance.
Feedback
The instance, plus a playbook from an earlier global search
Edit
A separately trained editor patches the global harness; the execution model is not trained
Selection
One editor call; the patch serves that instance only
Separate branchModel weights change too · not fixed-model harness evolution
Representation and runtimeBelow the harness · what an editable harness is written in
Natural-Language Agent Harnesses write run-level policy, such as stages, roles, state, checks, recovery and stopping, as an editable document; a shared runtime executes it through child-agent calls, and scripts keep exact operations such as tests. A representation and runtime, not an optimizer.
arXiv 2603.25723v1 26 Mar 2026 · v2 18 May 2026
Optimizers need such surfaces too: AHE edits component files on NexAU, Self-Harness edits declared parts of a DeepAgents harness, and SoL-Pi uses Pi’s public extension interface.
| Method | What changes | Feedback | Who edits | How a change is kept | Held fixed |
|---|---|---|---|---|---|
| Between rounds on a task set | |||||
| ModularRSI · Self-Harness · Meta-HarnessDetailed in sections 03 and 04 | One module; declared surfaces; whole program, respectively | Same-task contrasts; failure clusters; all earlier traces, respectively | The agent’s own model; a separate coding agent for Meta-Harness | Three gates; no regression on two splits; score frontier, respectively | Model weights, environment, evaluator |
| AHEAgentic Harness EngineeringarXiv 2604.25850v1 28 Apr 2026 · v4 18 May 2026Code | Seven component types, kept as files | Layered evidence distilled from trajectories | An evolve agent on the same fixed base model | Predicted effect checked next round; misses reverted per file | Base model |
| AutoHarnessarXiv 2603.03329v1 submitted 10 Feb 2026 | Harness code: a move checker and proposer, or the whole policy | Illegal moves and code errors; reward for the policy | Gemini-2.5-Flash, in a Thompson-sampling tree search | Search runs until every move is legal or time runs out | Model weights; TextArena games as the benchmark |
| HARBORarXiv 2604.20938v1 22 Apr 2026 | A finite set of harness feature flags | Task reward from repeated runs, adjusted for cold start | A constrained, cost-aware Bayesian optimizer | Reward model plus a probabilistic safety condition | Model and task set; one production case study |
| RRSIarXiv 2609.24972v1 21 Sep 2026 · v3 4 Oct 2026Code | Prompts, control flow, tools, memory, context | Scores on its evolution split; the full edit history | A proposer with a shrinking edit budget | A critic screens benchmark-specific edits; a pruner drops weak ones | The backbone model |
| RHOarXiv 2606.05922v1 4 Jun 2026 · v3 29 Aug 2026Code | Skills, tools, workflows, instruction files | Re-solved past tasks, self-checked; no external grades | The agent itself; no model is trained | Pairwise self-preference, a proxy for correctness | Model weights |
| Harness-R1arXiv 2608.02276v1 3 Aug 2026Code | Typed Python patches at four lifecycle hooks | A batch of the target’s failure trajectories | A separately trained 9B engineer model, via SFT then RL | Validated patches; in training, rerun success is the reward | Target model weights during engineer training |
| SoL-PiarXiv 2609.20519v1 17 Sep 2026Code | One Pi extension package with four opt-in mechanisms | Token use and completed work over a growing pool of rollouts | Auto-research agent loops | Surviving mechanisms ship off by default; no self-rewriting | Pi itself, unpatched |
| Across a task stream | |||||
| Evo-HarnessarXiv 2608.15071v1 15 Aug 2026 · v2 30 Aug 2026Code | General and topic skills | Each one-shot execution context | A solver reflects; an evolver updates the harness | The evolver keeps what transfers, before the next batch | The agent’s model, frozen |
| Within one run | |||||
| Continual HarnessarXiv 2605.09998v1 11 May 2026Embodied agents, evaluated on Pokémon games | Prompt, sub-agents, skills, memory | Failure signatures in the recent trajectory | A refiner played by the agent’s own model | Applied in place from the next step; no reset | Model weights in the main setting |
| Per instance | |||||
| Turbo HarnessarXiv 2609.40330v1 30 Sep 2026Code | One patch to the global harness per instance | The instance, plus a playbook from an earlier search | A separately trained editor, an RL-tuned Qwen3.5-9B | One editor call per instance; no per-instance search | The execution model, untrained; the global harness |
| Separate branch: model weights change too | |||||
| WHALEarXiv 2609.00196v1 31 Aug 2026Code | Model weights and harness code, in turn | Rollouts for the weights; search scores for the harness | Rejection-sampling fine-tuning; Meta-Harness search | Stages switch on a schedule or an adaptive patience rule | Not a fixed-weight method |
| Harness-ZeroarXiv 2609.24974v1 21 Sep 2026 | Model weights, distilled from an evolved harness | Student turns corrected by a reviewer guided by that harness | Supervised fine-tuning | The distilled model runs under the fixed minimal harness; the evolved harness and reviewer are removed | A minimal mini-SWE-agent harness with one Bash tool |
Self-evolution
Self-evolving methods wrap the run in an outer loop: what each round records becomes proposed harness edits, and only candidates that pass the check carry forward.
The current harness version works through tasks and records every step.
Traces, scores and failures are collected, and a proposer writes candidate edits to the harness.
Candidates are evaluated, and the selected version becomes the harness for the next round.
02 / Improvement loop
The methods differ in how much of the harness they open up, who writes a change and how a candidate is judged. Each iteration still has the same five steps, and the candidates evaluated so far, with their run evidence, inform the proposals of the next round.
Run the current harness version on the search tasks with the fixed model.
Keep the trajectories, meaning messages, tool calls and outputs, together with the evaluator’s scores.
A proposer reads selected evidence and writes a changed harness: one module function, a constrained edit or a whole program.
Depending on the method: interface or execution checks, a review of the diff, or scores from the fixed evaluator. Section 04 lists each method’s gates.
Each method keeps candidates its own way: ModularRSI and Self-Harness carry accepted changes into the next version, while Meta-Harness keeps every evaluated candidate in a population with no fixed parent.
Changes between iterations
The harness version, and nothing else
Held fixed
Model weights · environment · task split · evaluator · budgets
After the search
The chosen harness is frozen, then evaluated or used unchanged
In all three methods, versions are proposed and selected between evaluation rounds, and the result is frozen before it is evaluated or used. When an evaluation feeds tasks as a stream, as in Meta-Harness’s online text-classification setting, that describes how the application receives its inputs. It does not mean the harness edits itself while it runs.
Two methods on the research map differ on exactly this point: Evo-Harness updates its harness between the tasks of a stream, and Continual Harness edits it during a single run.
03 / Methods
ModularRSI, Self-Harness and Meta-Harness come from different groups and are separate methods. Each mechanism summary follows the paper and its official repository, tracing one iteration of the method’s improvement loop.
Method 1
ModularRSI: Modular and Generalizable Recursive Harness Self-Improvement
Evolves a Terminus-2-based harness one module at a time. The agent’s own model contrasts passing and failing rollouts of the same task on evolution tasks curated apart from the evaluation benchmarks, then changes functions inside one of five modules: agent loop, tool use, observation management, context management and task completion detection. The evolved modules are integrated and frozen before any benchmark evaluation.
One iteration
Run the current harness K times on each task of a batch of evolution tasks. The paper curates 2,000 executable evolution tasks that do not overlap with the evaluation benchmarks and uses 240 of them in its main experiments. Each task’s own tests mark every rollout as passed or failed.
Paper §3.3, §5.3Tasks with mixed results pair a passing with a failing rollout. Tasks that always fail look up an earlier success in a trajectory memory, or are diagnosed on their own. Tasks that always pass are checked for wasted steps.
Paper §3.3, Eq. 1The Code-Modify Agent, run by the same model, reads the trajectories, finds where the passing and failing rollouts diverge and asks whether a change to the module under evolution would have changed the outcome.
Paper §3.3; App. B, C.1Findings that target the same function are merged into one candidate, whose vote count is the number of distinct tasks supporting it. An evolution history of earlier changes helps avoid repeated or contradictory edits.
Paper §3.4The agent writes one change that has to hold for all supporting findings, by adding, modifying or replacing a function variant, and it may write only inside that module.
Paper §3.4; App. C.2A program check of syntax, imports and protocol; a diff review that does not see rewards and rejects task-specific code; an execution check on two tasks sampled from the current batch. A change that fails any gate is rolled back, and one that passes becomes the next generation.
Paper §3.5; App. C.3After three epochs per module, the five modules are combined and one integration epoch repairs cross-module conflicts; then the function library is frozen. Overlapping functions inside a module can be merged along the way.
Paper §3.6–3.7; App. C.4Method 2
Self-Harness: Harnesses That Improve Themselves
Lets the agent’s own model improve its harness, without human engineers or a stronger external agent. Each round mines failure patterns from the held-in traces, has the same model propose several small edits to declared parts of the harness, and keeps an edit only if it passes regression tests on a held-in and a held-out split. The search starts from a minimal benchmark-specific harness built on LangChain DeepAgents; each later round continues from the version accepted so far, while every task runs in a fresh environment.
One round
Run the fixed model inside the current harness on the held-in and held-out splits with the fixed evaluator, two attempts per task, and record each trace and its verifier outcome.
Paper v3 §3.1–3.2; Alg. 1Give each failed held-in run a failure signature: the verifier-level cause, whether the agent’s behavior caused it, and the mechanism involved. Failures with the same signature are grouped into evidence clusters.
Paper v3 §3.2The same model, now as proposer, sees the editable surfaces, the failure clusters, passing behavior to preserve and summaries of earlier attempts, but no raw logs and no held-out evidence. It returns several distinct, minimal edits.
Paper v3 §3.3Each edit is applied to the harness definition, such as its instructions, subagents, skills, middleware or runtime policy. An edit that changes nothing is invalid.
Paper v3 §3.3–3.4, §4.1A candidate is accepted only if its pass count drops on neither split and rises on at least one. Trade-offs between the two splits, and candidates that fail to run, are rejected.
Paper v3 §3.4; Alg. 1Compatible accepted edits are merged into the next harness; if none is accepted, the harness stays as it was. Every decision is logged.
Paper v3 §3.4; Alg. 1Method 3
Meta-Harness: End-to-End Optimization of Model Harnesses
Searches over whole harness programs with a separate coding agent. The proposer, Claude Code with Opus 4.6, can selectively inspect the code, scores and raw execution traces of earlier candidates in a filesystem, and writes new single-file harnesses, from small edits to full rewrites of prompting, retrieval, memory and orchestration. The base model stays frozen.
One iteration
A coding-agent session starts with a short human-written skill for the domain: where to write harnesses, how to inspect the history and which files are off limits.
Paper §3The proposer browses a filesystem with the source code, search-set scores and execution traces of all earlier candidates and decides what to read. In the TerminalBench-2 run it read a median of 82 files per iteration.
Paper §3; App. A.1It diagnoses failure modes and writes k new single-file Python harnesses, either by editing an earlier one or by rewriting it.
Paper §3; Alg. 1Each candidate has to pass interface validation before it is evaluated.
Paper Alg. 1; App. DA fixed evaluator runs each valid harness with the frozen model on the search set. Its code, scores and traces are added to the filesystem; nothing is deleted.
Paper Alg. 1; App. DAll evaluated candidates stay in a population with a Pareto frontier, for example accuracy against context tokens, and there is no fixed rule for choosing a parent. After a fixed number of iterations comes one final evaluation: the frontier on held-out test sets for classification, a single harness chosen by search-set performance on held-out problems for math, and the same 89 search tasks for TerminalBench-2, which the paper treats as a discovery setting. The proposer never sees test-set results.
Paper §3; Alg. 104 / Comparison
The rows answer the six questions from section 02, alongside the evaluation benchmarks and our ModularRSI adaptation on DeepAgents.
| Question | ModularRSI | Self-Harness | Meta-Harness | InferenceNet ModularRSI (our adaptation) |
|---|---|---|---|---|
| Starting harness | Terminus-2 on Harbor, split into five behavioral modules | A minimal benchmark-specific harness on LangChain DeepAgents; later rounds build on the accepted version | Seed harnesses per domain, such as zero-shot, few-shot or Terminus-KIRA | DeepAgents 0.7.13 with InferenceNet’s run_python tool and five no-op hook functions |
| What is edited | Function variants inside one module at a time, integrated afterwards | Minimal edits to declared surfaces: instructions, subagents, skills, middleware, runtime policy | Whole single-file harness programs: prompting, retrieval, memory, orchestration; full rewrites allowed | Scoped module hooks and SDK execution points (agent_loop, tool_use, completion, observation) |
| Who proposes | The evolving agent’s own model, as Code-Modify Agent | The same fixed model, in a proposer role | A separate coding agent: Claude Code with Opus 4.6 | Contrastive trajectory analyst, module editor and diff reviewer |
| Evidence the proposer sees | Pass or fail over K rollouts; same-task contrasts; votes across tasks | Clustered held-in failures, passing behavior to keep, earlier attempts; no held-out evidence | Code, search-set scores and raw traces of every earlier candidate; never test results | Contrasts across three rollouts of 100 development tasks; no reference values |
| How a version is kept | Program check, reward-blind diff review, small execution check; otherwise rolled back | No drop on held-in or held-out and a gain on at least one; compatible edits merged | Interface validation, then search-set scores; population with a Pareto frontier; no threshold | Static checks, diff review, execution probes and development validation |
| When it runs | Offline on evolution tasks; frozen before evaluation; functions composed per task from the frozen library | Offline rounds on fixed splits; the harness changes only between rounds | Offline loop of fixed length; the frontier gets one final evaluation | Offline evolution rounds on Dev100; frozen before paired evaluation |
| Held fixed | Model weights, harness infrastructure and module interfaces, environments, evaluators | Model weights, decoding, budget, tools, environments, evaluator, task splits | Base model, evaluator, proposer, task splits, iteration budget | Model, DeepAgents, sandbox, budgets, scorer and the 100 / 900 split |
| Selection data and final test | Evolution tasks are kept apart from Terminal-Bench 2.0 and SWE-bench Verified | Held-out pass counts guide promotion, so that split acts as validation | Held-out test sets for classification and math; TerminalBench-2 reuses its 89 tasks as a discovery problem | Dev100 development tasks (100 tasks) |
| Evaluated in the paper | Terminal-Bench 2.0 and SWE-bench Verified, including transfer across base models | Terminal-Bench 2.0, SWE-bench Verified and AppWorld with MiniMax M2.5, Qwen3.5-35B-A3B and GLM-5 | Online text classification, retrieval-augmented math and TerminalBench-2 | InferenceNet Dev100 econometric replication tasks |
Narrows every edit to one module and keeps evolution tasks apart from the benchmarks it reports on.
Lets the model edit its own harness in small steps and accepts only edits that do not regress on either split.
Opens the whole harness program to a coding agent that can read all earlier code, scores and traces.
05 / InferenceNet ModularRSI
We apply ModularRSI’s modular, between-rounds improvement loop to InferenceNet’s DeepAgents harness on econometric replication tasks. Across module-level hook evolution and scoped SDK integration, the evolved harness combines budget-aware submission control with statistical-audit observation feedback. Below, inspect the modular architecture, the source modifications and the paired Dev100 evaluation against pristine DeepAgents.
Evolves the agent_loop, tool_use and completion modules so the agent batches exploratory data checks, reserves calls for verification, and submits a complete Python program before budget exhaustion.
Integrates the evolved submission and tool-guidance policies directly into the pinned DeepAgents and LangChain model-binding path so they execute deterministically on every turn.
Inspect the SDK integrationEvolves ToolNode._normalize_tool_response in LangGraph to enrich run_python outputs with structured statistical-audit checks covering sample filtering, model specification and standard-error clustering.
How our harness is revisedFeedback → edit → selection, between evaluation rounds
Module hook search
Feedback
Roll out the harness three times per task on Dev100. Contrast passing and failing traces on the same task to isolate recurring failures such as exhausted call budgets and missing final programs.
Edit
Parallel module lineages revise one scoped function at a time (agent_loop, tool_use, completion) to enforce efficient data inspection, verification and final program submission.
Selection
Candidates must pass static syntax/interface checks, reward-blind diff review and a two-task execution probe before integration into the runtime.
Scoped runtime search
Feedback
Analyze execution traces where programs ran and submitted output but missed strict replication due to sample construction, fixed effects or clustering mismatches (183/300 → 191/300 across development rollouts).
Edit
Modify ToolNode._normalize_tool_response in LangGraph to preserve raw Python execution output while appending targeted verification prompts for sample scope, specification and inference.
Selection
Select the non-regressive candidate on development validation and freeze all module and SDK source hashes prior to the paired Dev100 evaluation.
| Component | Editable code | Behavior |
|---|---|---|
| Loop & submission hooks | agent_loop.pytool_use.pycompletion.py | Budget-aware finalization and repair nudges; consolidated data inspection; explicit instructions to verify and submit a complete program. |
| Runtime wiring | deepagents/middleware/filesystem.pyFilesystemMiddleware._filter_unsupported_tools_and_apply_promptlangchain/agents/factory.pycreate_agent._get_bound_model | Integrates the evolved submission and tool-guidance policies into the native model-call and tool-binding path. |
| Observation feedback | langgraph/prebuilt/tool_node.pyToolNode._normalize_tool_response | Invoked after tool execution; appends statistical-audit guidance (sample filters, model specification, clustering) while retaining the raw execution output. |
Paired evaluation · Dev100
Evaluated with GPT-5.6 Sol via OpenRouter Responses (non-streaming, explicit high reasoning effort) across all 100 Dev100 tasks under identical sandbox and budget limits.
Pristine DeepAgents
64%64 / 100 strict replicationsModularRSI-evolved DeepAgents
67%67 / 100 strict replications| Measure | Pristine DeepAgents | ModularRSI-evolved DeepAgents |
|---|---|---|
| Strict replication | 64% | 67% |
| Compilation Success | 96% | 98% |
| Partial Replication | 75% | 78% |
| Correct Coefficient Direction | 94% | 95% |
| Significant Level Correctness | 78% | 81% |
Strict replication requires coefficient and standard-error relative errors ≤ 1% and p-value absolute error ≤ 0.01 (local-paper-v1). Partial replication checks coefficient error ≤ 5%; significance compares p-value bands at 0.01, 0.05 and 0.1. All 100 tasks remain in the denominator.