When Harnesses Evolve, Which Models Should Follow?

Jiaqi Su, Guibin Zhang, Jie-Jing Shao, Cong Pang, Tiankuo Yao, Ivor Tsang, Haiyan Yin, Shuicheng Yan

CoEvo-RSI aligns language models and execution harnesses through bidirectional historical inheritance to solve brain–body mismatch.

How can we effectively co-evolve an agent's execution harness and its underlying model parameters to improve performance while maintaining interface compatibility?

Recursive self-improving agents often suffer from "brain–body mismatch," where an evolving execution harness demands behaviors the model hasn't learned, or restricts capabilities it already possesses. CoEvo-RSI addresses this by maintaining a shared archive of historical harnesses and model checkpoints, allowing a meta-agent to select or merge past designs and weights that are mutually compatible. This approach enables a compact 9B model to outperform significantly larger frontier models on specialized tasks like multi-agent failure attribution and role-aware SQL generation.

Paper Primer

The framework treats model–harness co-evolution as a search for compatibility: harness editors browse the archive to build on proven structural designs, while model inheritance selects or merges historical checkpoints to match the new harness's requirements. This bidirectional inheritance ensures that the "brain" (model) is initialized with capabilities suited to the "body" (harness) it must operate.

CoEvo-RSI achieves superior performance on specialized vertical tasks compared to larger, general-purpose models.

On the TraceElephant failure attribution benchmark, the co-evolved Qwen3.5-9B model outperformed DeepSeek-V4-Pro by 14.16% in agent accuracy. 14.16% accuracy gain over a significantly larger model.

The framework effectively minimizes interface violations during evolution.

Across ten rounds of co-evolution, the Turn-level Interface Mismatch Rate (TIMR) remained at or below 0.22%, indicating high interface compatibility.

Why is "bidirectional historical inheritance" necessary instead of just training the model on the latest harness?

Training only on the latest harness ignores useful capabilities learned in earlier rounds that might be restricted by the current harness. By selecting or merging historical checkpoints, the framework recovers past behaviors that are specifically compatible with the current execution scaffold.

What is the Turn-level Interface Mismatch Rate (TIMR) and why does it matter?

TIMR is a diagnostic metric that counts observable interface violations, such as malformed outputs or calls to unavailable tools. It serves as an inexpensive signal to identify "brain–body" friction before committing to full task evaluation.

For researchers building specialized agents, this paper demonstrates that aligning model initialization with harness evolution is more effective than optimizing either in isolation. The archive-based inheritance strategy provides a scalable way to maintain performance without needing massive, general-purpose models.

Introduction and Motivation

Why jointly evolving an agent’s harness and model is essential to avoid performance plateaus.

Model–harness co‑evolution promises agents that improve both their reasoning core (the “brain”) and their execution scaffolding (the “body”). In practice the two sides drift apart: the harness may demand behaviors the model has never learned, or it may suppress capabilities the model already possesses. This drift creates a performance plateau that stalls further improvement.

Co‑evolving the harness and the model is required because each component shapes the other’s learning trajectory; without joint evolution the agent quickly runs out of useful gains.

**Table 10.** Comparison of published evolution procedures. Select denotes choosing model initialization from historical checkpoints independently of the harness’s parent lineage; Merge denotes combining multiple historical model checkpoints. Model updates list the main training instantiations; “–” indicates a fixed model.

Co‑evolving harnesses and models is necessary to avoid performance plateaus caused by brain–body mismatch.

Related Work

We survey prior work on recursive self‑improvement, focusing on harness and model evolution.

Prior work on recursive self‑improving agents clusters around three themes: (i) improving the external execution harness, (ii) improving the model itself, and (iii) jointly evolving both sides. These strands motivate the CoEvo‑RSI framework introduced later.

These are agents that rely solely on a language model’s internal parameters, without any external execution scaffold, to perform tasks.

These agents augment a language model with an external “harness” that supplies tools, memory, or control flow, allowing the model to offload computation.

The CoEvo-RSI Framework

CoEvo‑RSI jointly evolves harnesses and models while tracking interface mismatch with TIMR.

When a model’s output format (e.g., XML) does not match the harness’s expected interface (e.g., JSON), execution fails; this interface mismatch is the primary pain point the method addresses.

CoEvo‑RSI repeatedly inherits harness designs and model checkpoints from a historical archive, evaluates each candidate pair, and promotes the pair that best reduces interface mismatch for the next generation.

Inherit$_\phi$ mutates $H^{(a)}$ to produce $H_{t,1}=H^{(a)}\!\!+\!\!\text{add-tool}$ and copies $H^{(b)}$ unchanged as $H_{t,2}=H^{(b)}$; evidence $e_t$ records which tool was added.

Inherit$^{m}_\phi$ pairs $H_{t,1}$ with $\theta^{(2)}$ (a checkpoint from a later generation) and $H_{t,2}$ with a merged checkpoint $\theta^{(1:2)}=\text{average}(\theta^{(1)},\theta^{(2)})$.

Each candidate pair is evaluated on a small validation set; TIMR is measured, and the pair with the lowest TIMR is selected for the next generation.

Co‑evolution can reuse a harness that previously failed with $\theta^{(1)}$ by pairing it with a newer checkpoint, demonstrating the benefit of cross‑generational inheritance.

TIMR quantifies how often a model turn triggers an interface violation, giving a cheap signal of how well the harness and model communicate.

Compute total turns: $5 + 4 = 9$.

Sum violations: $1 + 0 = 1$.

Calculate TIMR: $1 / 9 \approx 0.111$ (11.1 % of turns violate the interface).

Even a single violation can dominate the metric when the total number of turns is small, highlighting the importance of early‑stage robustness.

**Figure 2.** Brain–body alignment in model–harness co-evolution. Left: Historical harnesses and checkpoints are recombined and adapted to resolve interface mismatch. Right: Step accuracy versus Turn-level Interface Mismatch Rate (TIMR; §3.1) for ten evolved versions per method, from a three-round run evaluated on the Who&When test benchmark.

**Figure 3.** Overview of CoEvo-RSI. Left: The Curator draws on archived designs, checkpoints, and outcomes to guide evolution. Center: Harness editors choose historical harness bases; checkpoint selection or merging supplies the paired models. Right: Each round evaluates candidate pairs, tracks TIMR, adapts the selected model to its harness, and promotes improvements by validation performance. Outcomes return to the archive.

Harness Inheritance Mechanisms

We describe Harness Inheritance, a systematic evidence‑driven reuse of historical harnesses for new checkpoints.

When a newly evolved model checkpoint encounters a mismatch with its execution harness, naïve reuse of the previous harness often fails, forcing costly redesign. Harness Inheritance solves this by systematically curating evidence of past mismatches and selecting a compatible historical harness as a base for the offspring.

Like a detective gathering clues, the Curator assembles a history of past designs before picking a base, ensuring the new harness inherits proven compatibility.

Action $u_{t,1}$ samples “read harness $H_2$”; history $r_{\text{cur}}$ becomes $[H_2]$.

Action $u_{t,2}$ samples “read harness $H_3$”; history $r_{\text{cur}}$ becomes $[H_2, H_3]$.

Curator forms evidence $e_t$ from mismatches observed in $H_2$ and $H_3$ and generates $K=2$ hypotheses: $b_{t,1}$ = “adjust interface A”, $b_{t,2}$ = “adjust interface B”.

Editor 1 receives $b_{t,1}$, browses $A_{<t}$ and selects base index $i_{t,1}=1$ (harness $H_1$), producing offspring $(H_{t,1},U_{t,1})$ with $U_{t,1}=\{H_1\}$.

Editor 2 receives $b_{t,2}$, selects base index $i_{t,2}=3$ (harness $H_3$) and inherits $U_{t,2}=\{H_3\}$.

Even with only two retrieval actions, the mechanism can combine evidence from multiple past harnesses to guide distinct editors toward different compatible bases.

How does Harness Inheritance differ from simply fine‑tuning a harness on the new checkpoint?

Fine‑tuning adapts a single harness by gradient updates but does not explicitly collect evidence of past incompatibilities nor select a base from an archive. Harness Inheritance instead curates evidence, proposes multiple hypotheses, and lets independent editors pick historically compatible bases, guaranteeing that the resulting offspring inherits proven compatibility rather than relying on stochastic gradient descent alone.

Model Inheritance and Selection

Model inheritance selects and merges past checkpoints to initialize offspring harnesses compatibly.

When a new harness changes the behavior a model must execute, initializing the model becomes a compatibility decision. Selecting a single checkpoint is easy—like picking one tool from a toolbox—whereas merging several checkpoints is harder—like assembling a custom tool from parts.

The meta‑agent chooses a weighted combination of archived checkpoints, merges them with TIES, and validates the result before promoting the best offspring.

Step 1: TIES discards any task‑vector entry whose absolute value is below 0.1 in all three checkpoints.

Step 2: For each remaining entry, signs are compared; entries with conflicting signs are resolved by taking the majority sign (e.g., two positives vs one negative → positive).

Step 3: The surviving entries are weighted by $\alpha$ and summed: $\theta$($\alpha$) = 0.5·$\theta$₁ + 0.3·$\theta$₂ + 0.2·$\theta$₃.

Step 4: The merged parameters $\theta$($\alpha$) are evaluated on the validation set $V$; the score improves from 0.72 (to $\theta$₁) and 0.68 (to $\theta$₂) to 0.78 for the merged model.

Even a modest blend of checkpoints can yield a higher‑scoring initialization because TIES preserves only the mutually‑consistent signal while discarding noisy components.

How does this inheritance differ from simply picking the best past checkpoint?

Simple selection (one‑hot $\alpha$) copies a single checkpoint verbatim, guaranteeing exact compatibility but missing any synergistic benefit. Model inheritance blends multiple checkpoints with TIES, which can create a richer initialization—provided the merged signs agree—potentially surpassing any single checkpoint’s performance.

1️⃣ Meta‑agent defines coefficient vector $\alpha$ and decides whether to use one‑hot selection or multi‑checkpoint TIES‑Merging.

2️⃣ Candidate checkpoints are sampled from $\pi$₍inherit₎ using historical evidence $e_t$ and fixed evaluation feedback O(q).

3️⃣ TIES merges the selected checkpoints into $\theta$($\alpha$) if multi‑checkpoint mode is chosen.

4️⃣ All proposals are scored on the validation set $V$; the top proposal $\bar{p}_t$ is selected.

5️⃣ Supervised fine‑tuning refines $\bar{p}_t$ into p⁺ₜ with the harness fixed.

6️⃣ Promotion compares pₜ, $\bar{p}_t$, p⁺ₜ using ≻₍prom₎ and the margin $\delta$₍prom₎ to produce the next model p₍t+1₎.

Experimental Setup

CoEvo‑RSI achieves top failure‑attribution accuracy across four OOD benchmarks.

CoEvo‑RSI outperforms all baselines on failure‑attribution across the four OOD benchmarks.

Table shows CoEvo‑RSI achieving 42.06%, 31.75%, 44.71%, and 47.89% on Who&When Hand, Algo., Pro, and TraceElephant respectively, surpassing the next‑best baseline by up to 12.5%.

Across the four benchmarks, CoEvo‑RSI exceeds the strongest direct‑LLM attribution (DeepSeek‑V4‑Pro‑0813 at 66.30% on Who&When Algo.) and the best harness‑enhanced system (FALAT + MiniMax‑2.5 at 25.90% on Algo.) while also surpassing the leading harness‑evolution baseline (Meta‑Harness at 68.25% on Hand) and the model‑training approaches (GRPO at 62.17% on Hand). These gains come from jointly evolving the harness and model, reducing interface mismatch.

We evolve the Qwen3.5‑9B model from a hand‑written initial harness over ten rounds, sampling up to three trajectories per task per round, and fine‑tune the model for one epoch with a learning rate of 5e‑6 and batch size 8 on four H100 GPUs.

Main Results

Co‑evolved agents beat larger baselines while keeping interface mismatch negligible.

Recall that recursive self‑improving agents evolve both their execution harness and model parameters; CoEvo‑RSI manages the resulting interface mismatch via historical inheritance and compatibility‑guided selection.

CoEvo‑RSI raises agent accuracy (AA) by +11.11 points over ten co‑evolution rounds while keeping interface mismatch negligible.

AA improves from the initial round to 61.90 % after round 8; TIMR never exceeds 0.22 % throughout the run.

**Figure 1.** Co-evolution elevates Qwen3.5-9b-based agent across three domains. Agent Failure Attribution (I) and (II) report Who accuracy (correct identification of the responsible agent) on Who&amp;When Hand and TraceElephant, respectively. Role-aware SQL reports safe execution accuracy (Safe-EX) on RBAC Spider; Household Agent reports success rate on HomeBench’s valid multi-device instructions (VM). All scores are percentages, with higher being better. Hatching marks CoEvo-RSI, and the outlined solid Qwen3.5-9B bar is its base model. Dashed arrows trace the improvement from the base model to CoEvo-RSI.

**Figure 4.** Co-evolution on Who&amp;When Algo. Dashed/solid curves show AA/SA, and marker labels give TIMR (%). Panels show harnesses at rounds 6–8. The left panel compares full CoEvo-RSI with Harness-only, Model-only, and Latest-only evolution across ten rounds. The right panels connect selected rounds to actor-summary recovery, budget-aware evidence coverage, and evidence rechecking, including reuse of round-4 model weights. Full CoEvo-RSI improves accuracy while keeping TIMR at or below 0.22%, illustrating the complementary roles of joint adaptation and historical inheritance.

**Figure 7.** Inference cost–accuracy trade-offs. CoEvo-RSI uses OpenRouter’s Qwen3.5-9B pricing. The left and right panels report Who accuracy on Who&amp;When Hand and Safe-EX on RBAC Spider against the cost of a full evaluation pass, using a logarithmic cost axis. Dashed staircases and shaded regions summarize the baseline Pareto frontiers, while stars mark the co-evolved 9B agent.

Framework Analysis and Limitations

We evaluate robustness, cost, and inheritance limits of CoEvo‑RSI across candidate budgets.

Robustness and stability are examined by varying the number of harness candidates K while keeping all other settings fixed.

Cost analysis separates training and inference expenses, revealing how candidate budget influences wall‑clock time and API spend.

Inheritance analysis shows that a growing archive drives interface compatibility toward lower TIMR, and that later rounds reuse high‑quality checkpoints from earlier generations.

**Figure 6.** Sensitivity to the number of harness candidates K (three rounds, single run): (a) AA, (b) SA, (c) TIMR, (d) run span, (e) evaluation time, (f) API cost. Each bar corresponds to K ∈ {4, 6, 8, 10}, with the remaining settings fixed. The top row reports held-out task performance and interface violations, while the bottom row summarizes wall-clock run span, evaluation time, and API expenditure. The tested budgets maintain low TIMR with modest variation in accuracy; the default K=8 gives the shortest run span of 17.48 hours at an API cost of \$2.72.

**Figure 8.** Interface compatibility on RBAC. Normalized TIMR ($\downarrow$) across harness–checkpoint pairs; only the lower triangle is available during evolution. Rows index evolved harnesses and columns index model checkpoints, with TIMR globally min–max scaled to $[0, 1]$ across the complete matrix for comparison. Stars identify selected pairs and aliased checkpoints, and the side and bottom links record derivation, reuse, and historical design references. Low-TIMR off-diagonal pairings and checkpoint reuse show that interface compatibility depends on the particular harness–model pair, motivating inheritance beyond the latest generation.

Experimental Details

Details on benchmarks, data splits, harnesses, and hyperparameters for the experiments.

All domains run ten co‑evolution rounds with $K\!=\!8$ harness candidates per round; the only exception is the candidate‑sensitivity study (three rounds). The meta‑agent is DeepSeek‑V4.1‑Flash operating inside Codex, receiving validation rollouts of the incumbent model–harness pair each round.

Task models are Qwen3.5‑9B (high‑reasoning effort) served with vLLM, sampled at temperature 1.0, top‑p 0.95, top‑k 20. Training uses AdamW ($5\!\times\!10^{-6}$), cosine schedule with 3 % warm‑up, batch size 1 per device, 4 gradient‑accumulation steps, and runs on four H100 GPUs (DeepSpeed ZeRO‑3, bf16, gradient checkpointing). Global batch size is 8; long‑context domains also use sequence parallelism of size 2.

Failure Attribution requires the system to name the responsible agent (Who) and the decisive step (When) for a failed multi‑agent run. Training instances are drawn from TracerTraj, CORRECT‑Error, AFTraj, and a small self‑constructed set, totalling 3 400 instances; 200 TracerTraj instances are held out for validation.

Role‑Aware Text‑to‑SQL pairs a natural‑language question with a user role that defines column‑ and operation‑level access policies. The system must either produce a correct SQL query (if authorized) or refuse the request. Metrics include Safe‑EX, Viol., Safe‑Deny, Over‑ref., and AC‑F1, derived from six outcome sets ($S_c$, $S_w$, $S_{or}$, $S_{vc}$, $S_{vw}$, $S_{pr}$).

The table presents the distribution of data splits across different sources, detailing the number of instances (#Inst.) and databases (#DB) for each category.

Smart‑Home Instruction Following uses HomeBench queries that bundle 2–10 sub‑instructions. The system must emit a device command for each feasible sub‑instruction and an error for each infeasible one. Success is exact‑match on the command multiset; F1 is the micro‑averaged command‑level F1.

The table categorizes SQL query responses based on ground truth (Allow vs. Deny) and execution outcomes (correct, wrong, or refused). The sets $S_c$, $S_w$, $S_{or}$, $S_{vc}$, $S_{vw}$, and $S_{pr}$ represent correct, wrong, over-refused, violation-correct, violation-wrong, and properly refused predictions, respectively. An allowed request answered with policy-violating SQL also belongs to $S_{vc}$ or $S_{vw}$. SQL correctness is judged by execution equivalence on the sample database. Let $N_+$ and $N_-$ count allowed and denied requests, with total $N = N_+ + N_-$. Define $n_{ans} = |S_c| + |S_w|$, $n_{viol} = |S_{vc}| + |S_{vw}|$, and $n_{ref} = |S_{or}|$.

Baseline Configurations include Meta‑Harness and Self‑Harness, both initialized from the same task model and hand‑written harness, and evaluated on the same 200 held‑out TracerTraj validation instances. Model weights stay frozen during harness evolution; each baseline proposes eight candidates per round and evaluates each candidate twice on the validation set.

This table displays the distribution of instances across different data splits.

**Table 8.** Training-sample budget on failure attribution. CoEvo-RSI counts are summed over all ten rounds, with replayed trajectories included in the training count.

**Table 9.** Hyperparameters of the RL baselines.

Section B clarifies the diagnostic scope of TIMR (Equation 5): it counts observable interface violations (unavailable tool calls, contract breaches, malformed outputs) within a model–harness pair, yielding a value in [0, 1]. TIMR is inexpensive to compute and serves as a focused signal for interface compatibility during evolution.

Section C interprets the comparison with frontier models: despite a 9 B parameter budget, CoEvo‑RSI reaches 95.51 % Spider AC‑F1 (vs. 95.85 % for the strongest system) and 75.51 % HomeBench VM success (vs. 75.10 % for DeepSeek‑V4‑Pro). These gaps are modest given the large capability disparity (e.g., Qwen3.5‑9B scores 11 vs. 45 for GLM‑5.3 on the Artificial Analysis Index).

Section D compares six co‑evolution methods and two harness‑only methods (Table 10). CoEvo‑RSI uniquely combines explicit harness‑history selection with independent model‑checkpoint inheritance, expanding the candidate space and enabling bidirectional historical reuse.

Meta-Agent Prompts

Provides the meta‑agent prompt templates and a comparative table of evolution procedures.

The appendix begins with the meta‑agent prompt suite, which the meta‑agent receives each evolution round. The suite consists of a fixed shared skeleton (Prompt A) and a domain‑specific direction (Prompts B–D) that encode the task’s metrics, interface contract, and leakage constraints.

Prompt A defines the evidence discipline, workflow, and permission boundary that are identical across all domains. It requires the meta‑agent to modify only the candidate harness, to audit evidence, to produce a failure taxonomy, and to emit a concrete evolution report before terminating.

Prompt B supplies the failure‑attribution direction for multi‑agent scenarios. It asks the meta‑agent to stratify validation failures by trajectory length and agent count, to isolate the responsible agent and step, and to propose a targeted change that improves long‑trace handling without regressing short‑trace performance.

Prompt C targets a role‑aware Text‑to‑SQL domain. It enumerates the primary metrics (e.g., `safe_ex`, `ac_f1`, `llm_rate`), defines the LLM‑driven agent loop with `test_sql` and `final_answer` tools, and constrains the evolution space to rule routing, prompt engineering, and SQL generation improvements.

Prompt D describes the smart‑home instruction‑following domain. It preserves the `build_agent`, initialize, step, and `final_answer` APIs, and limits the evolution space to context selection, state grounding, and compound‑instruction coverage while forbidding hard‑coded validation data.

Table 10 compares published evolution procedures across dimensions such as harness update, model initialization, model update, historical weight usage, and model–harness co‑evolution. The rows list methods from prior work (e.g., HarnessForge, HarnessX) and the proposed CoEvo‑RSI approach, highlighting the latter’s persistent harness edits and archival reuse.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers