The Improvement Loop: Autoresearch for Harnesses

Reading time ~12 min · Quiz at the end

Most teams "improving" an agent harness are doing something closer to fidgeting than experimenting. A prompt gets tweaked because a demo went badly last Tuesday. A retrieval parameter gets bumped because someone read a blog post. A new model version gets swapped in because it topped a leaderboard. Weeks later, nobody can say with confidence whether the system is actually better, because nobody wrote down what "better" meant before they started, and three other things changed in the meantime. This is not engineering. It's noise that occasionally happens to correlate with improvement, and the correlation is indistinguishable from luck until you can prove otherwise.

The discipline that fixes this is old — it's the scientific method with a deployment pipeline attached, and anyone who has run a rigorous A/B test already knows its first rule instinctively: you cannot change the thing you're measuring and the measurement at the same time and learn anything. Apply that rule to a harness and you get a loop with five steps, in order, none of them optional: freeze the measurement, isolate the variable, run the experiment, commit the win or revert the loss, log everything. Then repeat. This lesson works through the loop in detail, applies it to a real harness component end to end, and addresses the question every team eventually asks once they have a working loop: can the AI run this loop on itself, and how much do you let it?

Step one: freeze the measurement

Before you touch a prompt, a retrieval parameter, or a model version, the eval set that will judge the change has to be fixed and version-controlled. Not "roughly the same eval, we added a few cases" — genuinely frozen, the way a controlled experiment freezes everything except the treatment. The reason is not pedantry. If you change the eval and the harness component in the same cycle, any score movement is uninterpretable: you cannot tell whether the system got better or the test got easier. This is the single most common way improvement programs deceive themselves. A team adds a few new labeled examples that happen to be easier than the old ones, scores go up, everyone celebrates, and three weeks later production accuracy hasn't moved because the actual system never changed — the yardstick did.

Freezing the measurement also means deciding, before you start, what "win" means numerically — not just "accuracy went up" but a threshold that accounts for noise: is a 1.5-point gain on a 200-case eval set a real signal or within the set's natural variance? An eval set that's too small will show you phantom wins and phantom losses at a rate that makes the whole loop worthless. This is the same discipline as statistical power in A/B testing: know your sample size and your minimum detectable effect before you run anything, not after you see a number you like.

Step two: isolate the variable

One change per cycle. Not a prompt rewrite plus a retrieval reindex plus a model bump, run together because the team is in a hurry and wants to see if "the new version" is better. If the combined change improves the score, you know something in that bundle helped — you have no idea which part, whether the other parts hurt and got carried by the winner, or whether the winning part alone would have done even better without the baggage of the other two. If the combined change makes things worse, you've burned a cycle and learned nothing you can act on.

This is the step teams cut corners on most often, usually under time pressure, and it's the step that turns an improvement program into an improvement lottery. Isolating the variable doesn't mean changes have to be small — a full prompt rewrite is one variable if nothing else about the system moves in the same cycle. It means every cycle should let you write a single, defensible sentence: "we changed X, and the eval moved by Y." If you can't write that sentence, you didn't run an experiment.

Step three: run, and let the eval decide

Run the frozen eval against the isolated change. Not a vibe check on ten examples somebody likes, not "I skimmed the outputs and they look more thoughtful" — the actual frozen eval set, scored the same way it was scored for the baseline, ideally by the same grading mechanism (rubric, exact-match, or a separate grading model with a stable prompt, not the model being evaluated grading itself). The eval's verdict is the verdict. This is where teams's instincts betray them most often: a change that scores worse but "feels more sophisticated" gets kept anyway because someone likes it, and the loop quietly stops being empirical.

Step four: commit the win, revert the loss — no exceptions

If the isolated change clears the pre-agreed bar on the frozen eval, commit it and move the baseline forward. If it doesn't, revert it completely, without leaving "just this one part" in place because it seemed harmless. Partial reverts are how systems accumulate a graveyard of half-changes that nobody can account for six months later, each one individually justified as "probably fine," collectively responsible for a system nobody fully understands anymore. The discipline is symmetric: wins get kept, losses get fully undone, and the baseline after each cycle is a single, well-defined artifact — not a blend of the last five experiments in indeterminate proportions.

Step five: log everything

Every cycle gets a record: what changed, what the hypothesis was, what the eval scored before and after, whether it was committed or reverted, and why. This log is not busywork for auditors. It is the organizational memory of the harness — the thing that lets a new engineer joining the team in month eight avoid re-running an experiment that failed in month two for reasons that are still true. Module 2 covered context graphs as a way of encoding organizational judgment for the agent; the experiment log is the parallel structure for the team building the agent. Without it, institutional knowledge about what doesn't work lives only in the memory of whoever happened to run that experiment, and leaves the building when they do.

Letting the AI research itself

Once the loop exists, a natural next question is whether a model can run parts of it — propose the hypothesis, draft the isolated change, even suggest what to try next based on where prior cycles landed. It can, and this is legitimately useful: a model with access to the experiment log can propose changes that account for what's already been tried, which is exactly the kind of pattern-matching over a long history that models are good at and humans get tired of doing carefully. The autoresearch loop — a model proposing harness modifications, an eval scoring them, the loop deciding what survives — is a real productivity multiplier for the "iterate on a well-defined component" phase of harness work.

But letting the AI propose changes does not relax any of the five steps — it makes them more important, because a model generating its own next experiments has every incentive (statistically, not intentionally) to propose changes that look plausible rather than changes that are genuinely novel, and it will happily propose three changes at once if not explicitly constrained to one. The loop's rules are what keep an AI-driven research process honest: the eval is frozen regardless of who proposes the change, exactly one variable moves per cycle regardless of how many the model suggests, the eval's score is the decision criterion regardless of how confident the model sounds about the change being an improvement, and every cycle gets logged regardless of whether a human or a model initiated it. Autoresearch is the loop with a faster, tirelesser hypothesis generator attached — it is not a reason to skip the loop.

A cautionary result belongs here, because it draws the boundary of what an autoresearch loop can safely do. The Self-Taught Optimizer (STOP; Zelikman et al., 2023) had a model recursively improve its own improver program, and it discovered real, recognizable strategies on its own — genetic algorithms, beam search, simulated annealing, decompose-and-improve. But the outcome that matters is downstream, and it split by model strength: task performance improved across iterations with GPT-4 yet actively degraded with weaker models like GPT-3.5 and Mixtral. Recursive structure alone is not enough; the base model has to be capable enough to improve the mechanism, or the mechanism gets worse each time it touches itself. The practical implication is sharper than "weak models help less" — an autoresearch loop on an underpowered model does not merely plateau, it can walk the harness steadily downhill while every individual step looks locally plausible, because marginal-looking noise accepted over and over is just a slow regression. This is the strongest argument for making the frozen eval and the commit/revert discipline non-negotiable in an AI-driven loop.

The same discipline is what makes automated harness improvement work at industrial scale. Self-Harness (Zhang et al., 2026) runs exactly this propose-evaluate-accept loop, with two refinements worth stealing. First, it mines failure patterns from execution traces with an insistence on causal precision: two failures that share the same surface verifier outcome — both timed out, say — can have entirely different underlying mechanisms, so a failure record captures the verifier-level cause, the causal agent behavior that led there, and the mechanism the trace exposes, not just the symptom. Second, its acceptance criterion is the part most teams get wrong: a bounded, narrow candidate edit is accepted only if it shows no regression on both a held-in split (did it fix the weakness it targeted?) and a held-out split (did it break anything else?), and rejected candidates are logged without ever touching the active harness — the graveyard-of-half-changes problem solved by construction. Run this way, the loop even learned model-specific harness instructions, discovering automatically that different base models have different weaknesses and need different scaffolding.

Two failure modes make the "let the eval decide" rule load-bearing rather than procedural. The first is over-optimism: Bubeck et al. (2025) call it "p-hacking and eureka-ing" — a model introduces what they memorably term "numerical duct tape" and declares victory while the signal is still noise. This is the automated cousin of the p-hacking pitfall flagged in step three, and it is exactly why the frozen eval and the pre-agreed stopping rule have to be enforced mechanically, by the loop's structure, and never delegated to the model's own judgment about whether it has succeeded. The second is reward hacking: whatever signal the loop is given, it will optimize — and it optimizes the measure, not the thing the measure was a proxy for, so unit tests get overfit, judge models get gamed, and benchmark artifacts get exploited. The defense, as Weng (2026) stresses, is architectural: the evaluator and the permission control must sit outside the loop that evolves the harness, so the thing being optimized cannot reach in and edit the thing doing the grading.

Worked example: improving a PII and privacy filter

Consider a component almost every enterprise harness needs: a filter that catches personally identifiable information before it leaves the system — in outbound customer communications, in logs, in anything a downstream system or a human outside the authorized boundary might see. Getting this wrong in either direction is expensive: too loose and you leak data; too aggressive and you redact the customer's own account number out of a letter addressed to them.

Baseline. The team assembles a labeled eval set of 300 real (anonymized, reviewed) production cases spanning the categories that matter: names, account numbers, SSNs, addresses, medical codes, and a deliberately tricky category of near-misses — numbers that look like SSNs but aren't, names that are also common words. Each case is labeled with the exact spans that should and shouldn't be redacted. The current filter, a rule-plus-model hybrid, scores 91% F1 on this frozen set. That 91%, on this exact 300-case set, is the number every subsequent change is measured against. Nothing about the eval set changes from here forward without a separate, explicitly logged decision to refresh it.

Notice cycle 1: a plausible-sounding change — clearer prompt instructions — made things very slightly worse, and it was reverted in full, not kept "because it reads better." Notice cycle 3: fine-tuning produced the largest gain, and it was the right tool here for a specific reason worth generalizing.

The PII filter is narrow and stable in exactly the way that makes fine-tuning pay off: the definition of "this is an SSN" doesn't drift with quarterly strategy changes the way "this is a good discount justification" might. A team that fine-tuned a model for discount-approval reasoning instead, hoping for the same kind of gain, would find the fine-tuned model quietly stale the next time the CRM's discount policy changed — because the model learned last quarter's policy as if it were physics, and nobody remembered to retrain it when the policy did what business policies do.

Telemetry as the flywheel

The PII example assumed a 300-case labeled eval set existed. In practice, that set has to come from somewhere, and the somewhere that matters is production telemetry: real traces of the system running on real (properly governed) inputs, with real near-misses and real edge cases that no one would have thought to write by hand. The flywheel runs: production traces get triaged and curated into eval cases (the genuinely hard or surprising ones, not every trace); those eval cases power the frozen measurement the improvement loop runs against; targeted improvements get committed against that measurement; the improved system produces new traces, some of which surface the next generation of hard cases; and the eval set gets refreshed, deliberately and on a schedule, not accidentally mid-cycle.

This flywheel is part of the moat this course keeps returning to. The eval set built from three years of a specific insurer's actual claims edge cases, or a specific utility's actual dispatch near-misses, is not something a competitor can buy or a vendor can hand you off the shelf — it's accumulated organizational knowledge about exactly where your systems and your customers get weird. Handing your telemetry pipeline wholesale to a platform vendor, so that the vendor's model improves on your production data while you retain only the resulting API call, gives away the flywheel and keeps the pipe. Own the curation step, even if you rent the model underneath it.

Guarding against eval overfitting

A frozen eval set that never changes has its own failure mode: after enough cycles, the harness is optimized for that specific 300 cases in a way that doesn't generalize, the same way a model can overfit a training set. Two disciplines guard against this. First, maintain a hold-out set — a portion of labeled cases never used for cycle-by-cycle decisions, checked only periodically, as a sanity check that gains on the working eval are showing up on unseen cases too. Second, refresh the working eval from fresh production telemetry on a deliberate schedule (quarterly is reasonable for most components), logged as its own event, with a fresh baseline re-established before the next round of cycles begins. Refreshing the eval mid-cycle to chase a number is the sin from step one; refreshing it on a planned schedule between cycles is healthy hygiene.

Everything in this lesson has treated the harness as something a disciplined loop improves one committed variable at a time. Lesson 15 takes this further and asks what happens when the harness itself, as code, becomes the object of automated search — when the loop no longer just tunes parameters but evolves the structure of the scaffolding, and the guardrails above stop being good practice and become the only thing keeping the search from consuming its own foundations.