How do agents decide which created code should persist versus disappear?
This explores how autonomous agents manage the lifecycle of code they write themselves — what gets kept, reused, and shared versus discarded — which the corpus frames as memory management, skill curation, and an underexplored 'persistence' problem.
This explores how agents decide which of their own generated code should survive across tasks versus be thrown away — and it turns out the corpus treats this less as a coding question and more as a *memory and curation* question. The starting point is that agent-authored code that persists and gets shared is, frankly, the least-understood layer of the whole agentic stack What makes agent-created code artifacts so hard to manage?. The reason it matters is that code isn't just an output to be regenerated on demand — it's an executable, inspectable, stateful medium the agent reasons through Can code become the operational substrate for agent reasoning?. Once you see code as a substrate rather than a deliverable, 'should this persist?' becomes a real decision with consequences.
The clearest mechanism for keeping code is the skill library. VOYAGER stores working code as named, reusable skills in an embedding-indexed library and composes complex skills out of simpler ones, which lets it keep learning without the catastrophic forgetting that weight-updating methods suffer Can agents learn new skills without forgetting old ones?. So the first answer to 'what persists' is: code that *worked* — validated by environmental feedback — gets promoted into the library; everything else is scratch. But who does the promoting matters. SkillOS shows that handing curation to a *separately trained curator* (decoupled from the frozen executor that writes the code) shifts the library away from verbose generic additions toward sharp, actionable execution logic and cross-task meta-strategies Can a separate trained curator improve skill libraries better than frozen agents?. In other words, the keep/discard decision improves dramatically when it's a learned skill in its own right, not a side effect of generation.
Laterally, this is the same problem the memory-management literature is wrestling with under different vocabulary. One framing splits the decision into two paths: an explicit 'hot path' where the agent itself decides via tool calls what to store or delete, and an implicit background path triggered programmatically — trading context-sensitivity against reliability How should agents decide what memories to keep?. DeepAgent pushes the autonomous side further with 'memory folding,' compressing past interactions into structured episodic/working/tool schemas so the agent keeps what's strategically useful and sheds token overhead Can agents compress their own memory without losing critical details?. RAISE adds a useful nuance: memory (and by extension artifacts) decomposes by time scale and granularity, which predicts that different kinds of code should follow different retention policies rather than one global rule How should agent memory split across time scales?.
The quietly surprising thread is *economic*. In a 115-day persistent-agent study, 82.9% of tokens were cache reads, which flips the accounting: when context and code persist and get reused, the meaningful cost unit stops being the token and becomes the completed artifact Do persistent agents really cost less per token?. That reframes the persist-versus-disappear decision entirely — keeping code isn't just a capability play, it's how the whole economics of long-running agents works. And persistence cuts the other way too: the same long-lived environment logged 889 governance events with safeguards baked directly into the memory layer the agent consults while deciding, so what persists isn't only skills but the rules constraining what's allowed to persist Can governance rules embedded in runtime memory actually protect autonomous agents?.
One thing the corpus is honest about: the deletion and lifecycle side is genuinely under-researched. We have good stories for *promotion* (skills, folding, curators) but the open challenges still cluster around persistence, sharing, and lifecycle — which is exactly where the next gains in autonomy and coordination are expected to come from What makes agent-created code artifacts so hard to manage?. If you want a doorway into the trade-off itself, start with the two-path memory split and then read SkillOS to see what changes when curation becomes a trained skill rather than an afterthought.
Sources 9 notes
Of the three agentic code layers, agent-authored artifacts that persist and are shared across agents are underexplored in research. Open challenges cluster around persistence, sharing, and lifecycle management — exactly where future gains in autonomy and coordination may live.
Research shows code uniquely enables agents to externalize reasoning, execute policies, model environments, and verify progress through its simultaneous executability, inspectability, and statefulness across task steps.
VOYAGER demonstrates that storing executable skills in an embedding-indexed library and composing complex skills from simpler ones allows agents to learn continuously while avoiding the forgetting that occurs with weight-update-based methods. Environmental feedback refines skills while an automatic curriculum drives continual exploration.
SkillOS shows that separating a trainable curator from a frozen executor, grouped by task streams, causes skill repositories to shift from generic verbose additions toward actionable execution logic and cross-task meta-strategies. The trained curator generalizes across different executor backbones and domains.
Memory management decomposes into explicit hot-path (agent decides via tool calling) and implicit background (programmatically triggered) paths. Each approach trades context-sensitivity for reliability differently across generation, storage, retrieval, and deletion.
DeepAgent's autonomous memory folding consolidates interaction history into episodic, working, and tool memory schemas. This reduces token overhead while letting agents pause to reconsider strategies—the autonomy and structure together avoid degradation that plagues poorly designed consolidation.
RAISE shows that agent memory consists of four components organized by two design axes: dialogue-level (conversation history, scratchpad) versus turn-level (examples, task trajectory). This granularity distinction predicts different failure modes and update policies for each component.
A 115-day case study found 82.9% of tokens were cache reads. When context persists and reuses, the meaningful cost denominator becomes completed artifacts, not individual tokens.
A persistent agent recorded 889 governance events across 96 active days, with safeguards encoded directly into the memory layer the agent consulted during operation. Runtime-resident governance proved more effective than external policies because the agent actually accessed it during decision-making.