Self-Improving AI Agent: Promote Changes, Don't Self-Edit Live

A self improving AI agent should not rewrite its live behavior and call the rewrite progress. The safer default is to treat every proposed prompt, memory, retrieval, tool policy, or code change as an untrusted release candidate. Freeze the candidate, compare it with its exact parent on evidence it cannot edit, check every protected metric, prove who may approve it, and keep a resolvable rollback target. Only then may a small, reversible change enter a bounded canary. That rule still permits improvement. It changes the unit of trust. Feedback can generate a candidate automatically; activation needs evidence. The distinction matters because “self improvement” covers more than model training. Reflexion stores verbal feedback in episodic memory so later trials behave differently without a weight update. Self Refine alternates feedback and refinement using the same model. A routing prompt, retrieved lesson, tool allowlist, or writable script can alter the next run just as surely as a new checkpoint. Your change ledger has to cover every one of those surfaces. Freeze the candidate before measuring it Start with two immutable identities: the active parent and the candidate. A useful change manifest records: The digest prevents a quiet edit between evaluation and canary. The parent identity prevents a candidate generated against agent v41 from being promoted over a now active agent v42 . The writable surface list reveals the real blast radius. A proposal described as a “memory lesson” is not that small if its process can also edit the evaluator or authority policy. Do not let the candidate write its holdout cases, scoring code, acceptance thresholds, approval policy, or rollback history. Those are the ruler, lock, and emergency exit. An agent that can change them can raise its score without improving the task. This is also why an append only learning file deserves versioning. A short lesson can redirect retrieval, suppress escalation, or bias tool choice across every later run. “Only memory changed” describes the storage mechanism, not the operational risk. Compare the exact parent and candidate on locked evidence An absolute candidate score is weak evidence. Run the parent and candidate against the same case IDs, environment version, tool fixtures, randomness policy, and outcome verifier. Store the paired results. The question is not “did the candidate score 0.86?” It is “what changed relative to the parent, on which cases, and at what cost?” The OpenAI self evolving agent cookbook demonstrates a practical loop with a baseline, human or model feedback, evals, a score threshold, a retry limit, and an updated baseline. That is useful machinery for generating and measuring candidates. A production promotion decision needs a stricter boundary than one aggregate threshold, because averages conceal which property paid for the gain. Suppose task success rises from 0.80 to 0.89 , while tool effect integrity falls from 0.99 to 0.96 . The average may rise. The change still fails if duplicate or missing external effects are unacceptable. Make the target metric and protected metrics explicit: Metric Direction Promotion rule Task success Higher Candidate must improve by at least 0.03 Tool effect integrity Higher No regression allowed Approval routing Higher Regression may not exceed 0.02 Cost per verified outcome Lower Increase may not exceed 0.05 Use metrics tied to observable outcomes. A command that exited zero is not proof that a deliverable exists. A tool call in a trace is not proof that the destination changed exactly once. A model judge can help with subjective quality, but it should not override a deterministic file, database, permission, or effect check. The locked set should include known failures and valid waits. Otherwise the agent can appear to improve by becoming more aggressive: fewer escalations, fewer questions, faster completion, and more wrong side effects. Include at least one out of band measure the candidate does not optimize directly. Separate proposal authority from activation authority Letting an agent propose a change does not imply authority to activate it. Define approval by surface and blast radius. A small prompt routing change might enter a 20 task canary under a preapproved policy. A retrieval policy or tool policy change may require a named human. Runtime code, evaluator logic, credential scope, and irreversible actions should remain outside automatic promotion. OWASP's Excessive Agency guidance recommends minimum permissions, downstream authorization, and human approval for high impact actions. Apply the same separation to self modification. The improvement process gets only the capability needed to write a candidate artifact. A different, smaller component owns evaluation and promotion. A useful authority receipt includes: Scope the receipt to the candidate digest in a real implementation. Expire it. Do not accept “the agent may improve itself” as an executable permission; it lacks a surface, limit, and time boundary. Waiting for approval is not failure. If the evidence passes but the change surface requires a person, return AWAITING APPROVAL with the candidate digest, measured deltas, requested surface, rollback target, and proposed canary size. The run is healthy when that wait has an owner and a resumable decision. Run the gates in a fixed order Order makes the result explainable. Reject structural problems before debating scores: 1. Identity: the digest is valid and the candidate's parent is still active. 2. Protected surface: the candidate cannot write tests, holdout data, authority, rollback history, or another forbidden surface. 3. Paired evidence: parent and candidate used the same locked evidence set. 4. Regression budget: every protected metric stays within its own limit. 5. Rollback: the named previous version still resolves. 6. Material gain: the target improvement clears the predeclared floor. 7. Authority: the receipt matches the surface and canary limit. The first five gates protect safety and auditability. Material gain prevents churn: a change that produces noise but no useful improvement should be held, not promoted merely because it passed safety checks. Authority decides between canary ready and human review. The companion fixture implements that precedence without a model call. Run it from the article artifact directory: The eight candidates deliberately share a plausible success story: most raise the target score. Their decisions differ: Candidate Decision Decisive evidence Safe prompt patch CANARY READY Paired gain, no protected regression, bounded auto authority Retrieval change AWAITING APPROVAL Evidence passes; surface requires a person Tiny memory lesson HOLD NO MATERIAL GAIN Safe, but target gain is only 0.01 Stale parent BLOCKED IDENTITY Candidate was generated from the wrong active baseline Evaluator writer BLOCKED PROTECTED SURFACE Candidate can change the ruler Fresh private cases BLOCKED EVIDENCE Candidate did not use the locked set Aggregate winner BLOCKED REGRESSION Tool effect integrity fell by 0.03 Missing old version BLOCKED ROLLBACK Named rollback artifact is unavailable The useful result is not a composite “safety score.” It is one state and one repair boundary. A stale parent needs regeneration. A protected regression needs diagnosis. A missing rollback target needs artifact restoration. Averaging those failures would hide ownership. Canary the change, not your confidence Passing offline gates makes a candidate eligible for a canary; it does not prove production health. Limit tasks, time, spend, tools, and side effects. Keep the parent available. Route the canary only work whose outcome can be independently verified. Compare its live receipts with a concurrent or recent parent baseline where the workload permits. Define rollback triggers before activation: protected metric breach, unknown outcome rate, duplicate effects, missing approvals, spend ceiling, or evidence freshness failure. Rollback means restoring the exact parent artifact and verifying that the intended task outcome returns. A rollback command that completed is activity, not recovery. Preserve three records after the canary: the immutable candidate and parent digests; paired offline and canary evidence, including unavailable signals; the promotion, hold, approval, or rollback decision with its authority receipt. If evidence disappears, return UNCERTAIN and stop promotion. Do not convert an absent metric into a healthy value. If the same proposal repeatedly fails, cap retries and route it to a person rather than letting the improvement loop consume unbounded time and tokens. Know what this gate cannot prove The supplied audit verifies manifest shape, precedence, paired metric deltas, authority scope, and rollback resolution. It does not prove that your holdout represents production, that a human rubric is correct, or that a rare failure will appear in 20 canary tasks. Tests can become stale. Evaluators can share the model's blind spots. External tools can change after the candidate passes. The practical default is therefore restrained: automate candidate generation freely, automate low risk evaluation carefully, and automate activation only inside an explicit authority envelope. Keep high impact and irreversible surfaces human approved. Continue monitoring after promotion because a self improving agent is healthy only when its useful outcomes remain healthy—not when its update pipeline is busy. Sidewisp is currently in private preview. Its direction is to add a health layer around existing agent runtimes, with evidence, approval boundaries, and outcome verification; production monitoring adapters and recovery systems are not generally shipped. If that boundary matches how you operate agents, you can join the private preview.