An agent can modify a prompt, add a memory, or rewrite a function. Calling that self-improvement skips the most important step: demonstrating that the change improved the intended behavior.
A system can become better at the examples it has already seen while becoming worse elsewhere.
Define the thing that changes
Prompt revision, tool configuration, source-code modification, retrieval updates, and neural training are different operations.
Record the exact artifact changed and its previous version. Keep the authority to make that change separate from the ability to propose it.
A system that can suggest a patch does not need automatic permission to deploy it.
Keep evaluation data separate
Use development examples to find problems. Use a held-out set to judge whether the proposed fix generalizes.
If the agent sees the expected answers or repeated feedback from the final test, that test becomes part of development. Create a new independent evaluation before claiming general improvement.
Preserve task identities and data provenance so contamination can be investigated.
Compare against a stable baseline
Run the old and new versions under comparable conditions. Report budget differences rather than quietly giving the candidate more attempts or tools.
Evaluate both quality and regressions. A change may improve mathematical tasks while making error handling worse.
The aggregate score should not hide the operations that matter most to the application.
Prevent the evaluator from becoming the target
An agent can learn to satisfy a weak scoring rule without solving the underlying task. Keyword matching is an obvious example, but more sophisticated evaluators can also reward the wrong behavior.
Use independent checks where possible and inspect failures. Treat a sudden score increase as a reason to understand the mechanism.
A system that rewrites its own acceptance rule has not demonstrated improvement merely because it now passes.
Keep changes reversible
Store versions, evidence, and a rollback path. Limit the scope of each experiment and isolate it from production data and external side effects.
Require stronger evidence for changes that affect permissions, spending, or live operations. The evaluation should reflect the consequences of being wrong.
Compare optimization methods under the same boundary
The February 2026 revision of GEPA describes reflective prompt evolution using feedback from execution trajectories. The August 2026 Open-Ended Optimization preprint asks whether a capable optimizer can choose the improvement procedure itself while essential constraints remain externally fixed.
Neither result means an application should let an optimizer rewrite its permissions or final evaluator. The OEO authors also report a capability boundary: weaker optimizers did not show the same advantage.
A useful local study compares a manual baseline, a fixed optimization procedure, and the adaptive method. Count every candidate evaluation and tool interaction against the budget. Preserve the exact artifact selected at the end of development.
Use two gates for promotion
First, run a development gate that checks the targeted improvement and required regressions. The optimizer may see this feedback. Second, evaluate the selected artifact on a held-out set that was not used to choose it.
Define the promotion rule in advance. It can require an improvement in the intended task while limiting regressions in important operations, latency, and cost. A higher average score should not hide a newly unreliable save operation or a broken authorization boundary.
Keep unsuccessful candidates and the reason for rejection. If a final test exposes a defect, fix it through a new development cycle and label the old test as observed data. A fresh claim of generalization then needs independent evidence.
After promotion, retain the previous version and monitor the actual workload for drift. The defensible claim is a measured improvement for a defined distribution, not an assumption that every subsequent self-edit will help.
Report a bounded result
A credible statement says which version improved on which tasks, under which budget, with which limitations.
It does not turn a prompt adjustment into proof of recursive intelligence growth.
Self-improvement becomes an engineering claim when another person can reproduce the comparison and see that the system did not simply move the goalposts.
Keep a good idea close.
Follow Signal Tower
