# How to Give AI Agents Memory Without Giving Them Permanent Access One of the biggest practical objections to ephemeral agents is state. "If the agent only lives for an hour, how does it remember what it learned yesterday? How does it continue a long-running investigation or multi-step refactor?" The assumption hidden in that question is that memory and persistence require the agent process itself to stay alive. That assumption is wrong. ## Snapshots are not the same as long-running processes You can preserve state across agent runs without keeping an execution environment warm. The pattern looks like this: 1. Agent boots with a fresh container + previous state (if any). 2. It does work, writing to files, notes, or whatever persistence mechanism the recipe declared. 3. When the mission ends, the important state is captured (committed, uploaded to object storage, etc.). 4. The container is destroyed. 5. Next time someone triggers the same recipe, a new container is created and given the previous state plus fresh credentials. The memory lives in the state store. The execution environment does not. This is how the researcher recipe works in practice. It writes findings to `notes.md` inside its working directory. On the next run it receives that file again. The researcher agent does not need to have been running the whole time. ## Why this is safer A long-running agent that "remembers everything" also carries every credential and access right it ever accumulated. Its memory is mixed with its authority. When you separate the two: - Old state can be reviewed or filtered before giving it to the next agent. - Each run gets credentials scoped only to what it needs right now. - You can choose *not* to give a new run access to previous state if something looks suspicious. - The blast radius of any single compromise is limited to the duration of that mission. ## Concrete example A developer agent is working on a feature across multiple days. It has made several commits on a branch. With a persistent agent model, the same long-lived process keeps its Git credentials and its checkout for days. If it gets jailbroken on day three, the attacker gets whatever the agent currently has access to, plus whatever is in its context. With the snapshot model: - Day 1 run: fresh container, GitHub token scoped for this recipe, checks out the repo, makes changes, pushes a branch, snapshots the current state of the working directory + any notes. - Container dies. - Day 2: new container, new short-lived GitHub token, receives the previous working directory state. Continues from where it left off. The attacker who compromises the day 2 agent does not automatically get the day 1 token (it is already expired) or any other access that was not declared for this run. ## What "state" actually needs to be preserved Not everything an agent touches during a run should be treated as long-term memory. Good candidates for snapshots: - Notes and analysis the agent produced - Partial work (code on a branch, draft documents) - Structured memory files the persona is instructed to maintain Bad candidates (or things that should be explicitly re-granted): - Active authentication sessions - Broad or long-lived tokens - Access to systems unrelated to the current mission A well-designed recipe makes this distinction explicit through the `persist` flag and what actually gets written to the persisted paths. ## Implementation details matter less than the mental model Whether you use R2, a local directory, a database, or Git itself to store the snapshot is an implementation detail. The important thing is the separation between "what the agent knows from previous work" and "what authority this specific execution environment currently holds." Many teams conflate the two because their agent framework makes it easy to keep everything in one long-running process. That convenience has a cost. ## The resume button In practice, teams using this model often build a simple "resume" or "continue previous mission" flow. The control interface offers to launch the agent with the last known state attached. The agent itself does not need to be aware that it is "resuming." It just receives files and context that represent prior work, the same way a human engineer would open yesterday's branch and notes. This keeps the agent's own reasoning clean while still giving it continuity. ## Don't romanticize the always-on agent The dream of a single agent that lives forever, accumulates all knowledge, and slowly becomes more capable is seductive. It is also the security equivalent of a root shell that never gets logged out. You can have continuity without immortality. The recipes and the runtime just have to treat state and execution lifetime as separate concerns. That separation is what makes resumable agents compatible with real security boundaries instead of an excuse to weaken them.