The latest version is often worse than the best one
An automated improvement loop looks sensible: diagnose an error, change data or instructions, train a candidate, evaluate it, and begin the next iteration. The final report usually points to the last version. That convention is dangerous because improvement is not monotonic.
RSIBench-Data makes agents execute the full data-centric cycle: diagnose failures, design training examples, produce a checkpoint, evaluate it, and choose the next intervention. Only 58.33% of tested configurations beat their first valid attempt.
The runs that continued after reaching a peak are more revealing. Of those runs, 78.26% ended with a checkpoint below their own best score. The rest only returned to the previous maximum. A persuasive explanation of the next data strategy did not predict a better model.
If the system retains only the final iteration, it can discard a working result it already found. The minimum defense is simple: store the best verified artifact separately and never overwrite it with an unevaluated candidate.
A defective skill contaminates its descendants
The same failure appears when an agent accumulates instructions in SKILL.md. A new rule can solve one case, occupy context, conflict with an older rule, and damage many later tasks.
VaG studies long-running skill evolution. The authors observed substantial degradation after peak performance. A defective rule became the parent of later revisions and contaminated its descendants. Removing the initial defect much later recovered little of the lost quality because dependent rules had already formed around it.
VaG responds with several critics and an estimate of each revision's marginal gain. On Terminal-Bench 2, it reached 72% pass@1 with a skill pool roughly five times smaller than the comparison system. The authors also report transfer across four model backbones and another benchmark.
These are fresh author-reported results, not proof that three critics are a universal solution. The mechanism is the durable part: a skill library stores the history of mistaken explanations as well as useful experience.
Most of a skill file may contribute nothing
Deleting every suspicious paragraph is not safe either. Skill blocks depend on each other: an example may rely on a definition above, and a script may assume a stated constraint. Naive leave-one-out ablation can break the dependency and assign the resulting damage to the wrong block.
SkillSV decomposes skills into rules, examples, scripts, and heuristics while preserving their dependency structure. Verified rollouts then estimate a block's useful contribution, context cost, and the effect of removing a valid dependency closure.
After one guided refinement pass, skills retained an average of 69% of their original tokens with no statistically significant loss across four benchmarks. Some retained only 42% to 57%. The most valuable 10% of blocks accounted for 21% to 100% of measured value.
The method is expensive because every large skill needs many executable holdout runs. It nevertheless tests an assumption that is usually left unexamined. File growth is not capability growth.
The holdout must survive the optimization loop
A self-improving system can overfit its own evaluator. If the agent sees every task and detailed failure reason, it can learn narrow patches that do not transfer. The final holdout must remain hidden from the component proposing changes. It should decide whether a candidate replaces the incumbent, not guide the next idea.
A practical setup uses three sets. Development cases supply failures and candidate changes. A validation set chooses among candidates. A separate sealed set determines whether the best-so-far artifact moves. New production failures enter the development pool, while old critical regressions remain permanently represented.
Acceptance should require more than a higher mean. The improvement must exceed measurement noise. No critical slice should regress materially. Prohibited actions and execution cost need independent checks. A candidate that solves easy tasks faster by becoming dangerous on a rare branch is not better.
A stopping rule is more useful than another hypothesis
An autonomous researcher can always propose one more experiment. That does not make the experiment worth running. After several iterations without verified gain, the loop should stop or change the intervention type: inspect labels, the environment, the evaluator, or the execution harness instead of generating more training data.
Every iteration should preserve data provenance, training code, random seeds, metrics, and its parent. The best artifact remains available for immediate rollback. The latest version is a candidate, not the winner by default.
Self-improvement without a best-so-far optimizes activity rather than quality. The system keeps producing versions after it has stopped getting better.