INQUIRING LINE

Teams keep tuning the code around their AI, then upgrade the model, and those hard-won fixes quietly stop mattering.

Why do useful harness updates often disappear during model evolution?

This explores why improvements engineered into the scaffolding around a model (prompts, tools, control flow) so often fail to carry over when the underlying model is swapped or upgraded.


This explores why improvements built into the scaffolding around a model (prompts, tools, control flow) so often fail to carry over when the underlying model is swapped or upgraded. The corpus has no direct measurement of how often updates disappear. Several notes do converge on one explanation: most harness edits answer one model's particular failures, so they lose their reason to exist when the model changes.

The first cause is that many edits are memorized fixes, not general strategies. An analysis of evolved harnesses found the edits were well-motivated, but most just persist fixes an agent could have rediscovered in a single attempt. They cache what was already within reach Do harness edits learn reusable strategies or memorize task fixes?. A cache keyed to one model's blind spots breaks in one of two ways. A better model doesn't share those blind spots, so the edit becomes redundant. A different model has different blind spots, so the edit misses them. A related note says an update's effect depends on the context that produced it: the parent model's state, the data, the training stage and the evaluation criteria. Promoting a new model also rewrites the baseline that later evidence is measured against, so past success shouldn't count as permission to reuse an update. It suggests checking applicability and running bounded trials first Should past update success guide future model changes?.

The second cause is that the payoff from a harness depends on where the model sits, even when the edit itself is fine. Models of every tier are about equally good at producing useful harness edits. The ability to benefit from them follows an inverted U, peaking in mid-tier models. Weak models often fail to invoke the harness at all, and strong models struggle to follow its instructions faithfully Do stronger models always evolve harnesses better?. Safety harnesses show the same fit problem: one strict enough for one model over-blocks another Should safety harnesses be customized for each deployment?. One note goes further and says adaptation isn't a property of a model snapshot. It lives in the versioned loop that links model, harness and an external contract, so swapping the model changes the loop itself Where does model adaptation actually happen?.

Not every update disappears, and the survivors share a pattern. Edits that fix the plumbing tend to last, and edits that patch a model's reasoning quirks tend not to. Four mechanisms found by scaling harness search across many environments (action execution, context compaction, observation handling and delegated reading) cut token traffic by about 45–49% at comparable performance, and the note calls these gains orthogonal to model improvements Can agent harnesses be automatically optimized across many environments?. One execution runbook transferred to newer models without modification Can execution harnesses lift model performance without retuning weights?. Evolving modules separately, on data disjoint from the benchmark and aggregating evidence across tasks before each update, is another way to keep mechanism-level gains apart from task-specific ones Can harness modules improve separately from benchmark data?. Some systems also guard against loss directly: DarwinX evolves harness variants under a 'preserve-and-extend' contract, an explicit rule for keeping earlier gains while adding new ones Can frozen models improve by evolving their harnesses?.

The practical upshot is to treat a harness edit as a hypothesis tied to the model that produced it, and re-test it on the new model instead of assuming it transfers. Some edits deserve to disappear. Harness gains should be compared against plain test-time search run with the same feedback and compute budget, and only the margin beyond that is attributable to the harness design How should we measure gains from automatic harness evolution?. An edit that was only buying extra computation, or patching a weakness the new model no longer has, was never a durable improvement.


Sources 10 notes

Do harness edits learn reusable strategies or memorize task fixes?

Analysis of evolved harness trajectories shows rational, well-motivated edits across prompt and tool layers, but most persist fixes an agent could rediscover in a single rollout. Gains remain limited because memorized shortcuts cache what's already within reach rather than converting hard failures into successes.

Should past update success guide future model changes?

An update's effect depends on its source context—parent model state, data, training stage, and evaluation criteria. Autonomous systems should gate reuse with applicability checks and bounded trials rather than treat prior success as permission, because promoting a child rewrites the parent against which future evidence is measured.

Do stronger models always evolve harnesses better?

Model capability to produce useful harness edits stays constant across tiers, but capacity to actually benefit from those edits follows an inverted U-shape, peaking in mid-tier models. Weak models fail to invoke harnesses; strong models struggle with faithful instruction-following.

Should safety harnesses be customized for each deployment?

A harness strict enough for one model over-blocks another, while policies general enough to transfer across domains miss application-specific safety relations. Domain semantics and model characteristics jointly determine which harness is effective.

Where does model adaptation actually happen?

Macaron-V1 argues adaptation is a property of the recursive cycle linking model, harness, and external contract—not individual model snapshots. Weight updates are gated by audit and evaluation against an external contract, making the loop the unit of improvement and release.

Show all 10 sources
Can agent harnesses be automatically optimized across many environments?

Cross-environment harness optimization yielded four mechanisms (action execution, context compaction, observation handling, delegated reading) that reduced token traffic by 44.7–49.0% while maintaining comparable performance on a 51-task benchmark, suggesting harness-level gains are orthogonal to model improvements.

Can execution harnesses lift model performance without retuning weights?

StateM improves Terminal-Bench 2.1 accuracy across multiple models by optimizing execution systems around frozen weights. The same runbook transfers to newer models without modification, achieving 95.3% on GPT-5.6 and lifting DeepSeek-V4 Flash by 5.4 points.

Can harness modules improve separately from benchmark data?

ModularRSI evolves harness modules independently using contrastive trajectories on benchmark-disjoint data, showing consistent gains across unseen tasks and domains. The approach isolates mechanism-level improvements from task-specific adaptation by aggregating evidence across tasks before updating components.

Can frozen models improve by evolving their harnesses?

DarwinX achieves average 17-point gains across benchmarks by evolving harness variants (prompts, tools, skills, control flow) under a preserve-and-extend contract while keeping the model frozen. Key evidence includes Terminal-Bench 2.1 rising to 84.7% and WebArena-Infinity reaching 93.0% audit-clean pass@1.

How should we measure gains from automatic harness evolution?

Automatic harness evolution must be compared against task-level test-time search under equal feedback and inference budgets. Only gains beyond what matched search achieves are attributable to the harness design itself, not just more computation.

Papers this line draws on 8

The research behind the notes this line reads — ranked by how closely each paper relates.