If an AI keeps rewriting its own instructions and tools, how do you keep a history you can undo?

This is about giving a self-modifying system a history it can be held to: what changed, where it came from, and how to get back. The corpus's clearest answer is to stop treating prompts, tools, and memory as loose text the agent quietly rewrites, and to treat them as registered, versioned resources with a lifecycle. The Autogenesis Protocol does this, which makes each update measurable, attributable, and reversible, and separates *what* evolves from *how* evolution happens (How can agent self-evolution be made safe and auditable?). Ouroboros takes the software-engineering route: it rewrites its own tools, prompts, and core only through reviewed commits, and posts state-of-the-art benchmark scores (Does self-editing through reviewed commits improve agent performance?). Its paper has no ablations, so nobody can say how much of the score the evolution actually earned. That gap is what missing lineage looks like: without per-change attribution you can't tell which edits mattered.

A version number alone isn't lineage, though. An update's effect depends on the context it was born in: the parent model's state, the data, the training stage, and the evaluation criteria. So a record that says "this worked" is not permission to reapply it after the system has changed (Should past update success guide future model changes?). That paper also makes a subtle point about rollback. Promoting a child rewrites the parent that all future evidence is measured against. So rollback restores the old baseline as well as the old behavior, and lineage has to keep that baseline alive. Its remedy is to gate reuse with applicability checks and bounded trials.

The corpus also hints at which changes deserve the most scrutiny. Analysis of evolved harnesses finds that most edits are sensible but memorize task-specific fixes an agent could have rediscovered in one rollout, rather than distilling reusable strategies (Do harness edits learn reusable strategies or memorize task fixes?). A lineage that records which failure each edit was written for lets you separate cheap cached patches from real improvements. Whether an edit helps also depends on the model using it. The ability to write a useful harness edit is flat across model tiers, but the ability to benefit from one peaks in mid-tier models (Do stronger models always evolve harnesses better?). So an edit's lineage entry should say which model it helped, or it can't be trusted after a model swap. Keeping mechanisms outside the weights, as VOYAGER does with an executable skill library, keeps each one an inspectable unit that can be added or removed without the forgetting that weight updates cause (Can agents learn new skills without forgetting old ones?).

Where the history lives, and who checks it, matters as much as what it records. Per-action guardrails can't state constraints that depend on prior history, so catching a sequence of individually fine edits that add up to a violation takes a stateful monitor (Can stateless checks ever catch sequence-level constraint violations?). One persistent agent logged 889 governance events over 96 active days, with safeguards written into the memory layer it consulted while working. That worked better than an external policy document, because the agent actually read it (Can governance rules embedded in runtime memory actually protect autonomous agents?). Dr. Claw shows the complementary design: persistent state objects and skill libraries wrap a fixed executor, leaving a traceable, recoverable trail without touching the agent itself (Can orchestration layers make coding agents more auditable?).

The last piece is who judges the edits. Pure self-improvement stalls on the gap between generating and verifying, and the methods that work bring in outside anchors such as past model versions, third-party judges, user corrections, or tool feedback (Can models reliably improve themselves without external feedback?). Retained lineage supplies one of those anchors for free. Old versions stay available as reference points, and reviewed commits stay available as independent checks. A system that can only compare itself to its latest self has nothing to roll back to.