When your AI agent writes code to finish a job, how does it decide what's worth keeping for next time?

This explores how an agent should judge which code it writes is worth keeping for later, versus discarding once the task is done. The corpus has no single rule, but it does suggest that the decision is really about curation, not storage. The evidence points to three separate questions an agent has to ask.

First, is keeping it a net benefit? The corpus is blunt that memory's real constraint is What makes agent memory quality better than storage capacity?: piling up material without curation produces staleness, contamination, and over-generalization, and makes performance worse. Code is no different. A saved script that was tuned to one situation can quietly mislead the agent later. The persistence question is also less about cost than it looks. In a 115-day case study, Do persistent agents really cost less per token? found that most tokens were cheap cache reads, so the meaningful unit was the finished artifact, not the token. That reframes the decision. What matters is whether a piece of code helps complete future artifacts.

Second, who makes the call, and when? How should agents decide what memories to keep? splits this into two routes. In the hot path, the agent decides mid-task, through a tool call, that something is worth saving. That is sensitive to context but easy to get wrong. In the background path, a programmatic trigger decides, which is more reliable but blind to what the agent was actually thinking. A more radical option is to separate the roles entirely. Can a separate trained curator improve skill libraries better than frozen agents? trains a dedicated curator, apart from the agent that does the work. Over training, its skill libraries moved away from verbose, generic additions and toward actionable execution logic and cross-task strategies. The curator learned what is worth keeping by seeing what helped across many tasks, which a single task in progress can't reveal.

Third, what does good, persistent code look like? The best-known model is Can agents learn new skills without forgetting old ones?, where VOYAGER keeps executable skills in an embedding-indexed library. Environmental feedback refines them, and complex skills are built from simpler ones. Code earns its place by having been shown to work and by being reusable as a building block. This works because, as Can code serve as the operational substrate for agent reasoning? argues, code can be run, inspected, and carry state, so it can be checked in a way prose can't. Where running it is impractical, Can structured reasoning replace code execution for RL rewards? shows that structured reasoning can verify patches at about 93% accuracy. That may be enough of a signal to gate what gets saved.

The hardest part is when saved code is shared. What happens to code that agents create and then share? calls this an underexplored frontier, with open problems in verification, regression prevention, shared-state consistency, and safety oversight. Shared infrastructure also becomes memory whether or not anyone plans it: Can ordinary infrastructure become unplanned agent memory? describes agents using a package repository to pass exploit findings to later agents. So an agent that persists code should assume something else will find it and reuse it. Governance also matters: Can governance rules embedded in runtime memory actually protect autonomous agents? found that safeguards work better when they live in the memory the agent actually consults. The corpus doesn't yet offer a tested rule for deciding what to persist. What it does offer is a set of criteria: verified to work, reusable as a building block, judged by something with cross-task view, and kept under rules the agent will actually see.