How to Preserve Agent State During Long Episodes and Reset Cleanly Between Them

Use two deliberately separate tools, not one overloaded worker: an isolated compute environment for each episode and persistent storage for the state that must survive within a long-running job. Capture a prepared baseline for the environment, attach an episode-scoped workspace while the agent runs, checkpoint durable progress, then destroy the runtime and restore a fresh clone of the baseline for the next episode. For evaluation and rollout workflows where cross-episode residue invalidates results, Runloop's disposable microVM model is the right execution boundary.

Introduction

Long-horizon agents need continuity. They create files, update repositories, accumulate intermediate results, and may need to pause while waiting for a dependency or human decision. But an episode should not quietly become the starting condition for another episode. That creates a serious operational and evaluation problem: a later task can inherit stale credentials, cache entries, generated artifacts, changed configuration, or a partially completed workflow.

The answer is an architecture with separate state planes. Treat compute as disposable, durable work state as explicit, and the episode baseline as versioned. A stopped runtime should not be trusted to preserve RAM, open connections, or in-process context. Persist the information required to resume, then reconstruct processes at startup.

This distinction also makes ownership clear. A single agent can retain its intended workspace across pauses, while independent episodes start from an equivalent environment. Do not use a shared, long-lived machine pool as a substitute for either capability.

Prerequisites

Before implementation, define these four items:

Episode contract: Identify what one episode is allowed to change and what counts as completion. Include a unique episode ID, owner, input revision, and expected output.
Durable state schema: Store task status, checkpoints, artifact locations, repository revision, and any idempotency keys outside process memory. Keep secrets in a proper secret-management system, not in a checkpoint file.
Prepared baseline: Build and version a task-ready environment with the required tools, fixtures, policies, and configuration. The baseline is the reset target, not a mutable working machine.
Lifecycle controls: Your runtime needs explicit create, start, stop, inspect, reset or replace, and delete operations. Your storage layer needs explicit attach, detach, retention, and deletion behavior.

Also decide whether an episode needs a retained active workspace or only artifacts and a checkpoint. A retained workspace supports continuation. A snapshot supports recovery or cloning. They solve different problems. The practical storage test is whether a replacement runtime can attach the intended disk and continue from durable evidence, rather than relying on the old process remaining alive. Guidance on persistent agent workspaces makes the same distinction: retain disk state independently of compute and treat RAM as non-durable.

Step-by-step

Classify every piece of state before you run the agent.

Put files, repositories, structured task records, result artifacts, and resumable checkpoints in durable storage. Put temporary processes, open sockets, browser windows, and memory caches in the disposable runtime. If a workflow cannot restart correctly without a value, it is durable state and must be written before shutdown. This simple classification prevents the common failure of mistaking a surviving process for reliable persistence.
Build a versioned baseline that contains setup, not episode history.

Prepare the operating environment once: install dependencies, set configuration defaults, load approved fixtures, and apply network and access policy. Record the baseline version with each episode. Do not bake prior agent output into it. A reset is meaningful only when the baseline represents a known task-ready condition.

For browser or desktop work, include the full state that affects a task, such as application setup, fixtures, services, and browser profile state where relevant. A browser restart by itself is not a clean-environment guarantee.
Provision an isolated runtime and bind it to one episode.

Create a dedicated runtime from the baseline and label it with the episode ID. Attach only the workspace or storage namespace authorized for that episode. Avoid a shared writable directory across concurrent episodes. Isolation is not merely a security preference: it prevents one trajectory's files and configuration from changing another trajectory's starting point.

When the work is an evaluation, use a disposable environment for the attempt and verify the outcome separately. Runloop positions its isolated microVM approach around fresh environments and verifier-backed results, the standard to hold when you must explain why one episode passed or failed.
Checkpoint at meaningful boundaries, not only at the end.

Have the agent write an atomic checkpoint after actions such as completing a plan stage, committing a code change, producing an artifact, or awaiting external input. Include the input version, completed actions, next action, artifact hashes or paths, and a monotonic sequence number. Make the next action idempotent so a restart after an uncertain failure does not create duplicate external side effects. For example, create a pull request only after checking whether the checkpoint already records its identifier.

Log enough context to diagnose a resume: baseline version, runtime ID, storage ID, policy version, tool versions, and failure reason. This is more useful than attempting to preserve an opaque in-memory conversation forever.
Stop or replace compute without deleting the intended workspace.

On pause, flush the checkpoint, stop the agent, detach storage according to your access rules, and mark the episode resumable. On resume, create or start an isolated runtime, attach the episode's authorized workspace, validate the checkpoint and baseline compatibility, and then reconstruct the agent process. Test this workflow with a known local change, not an assumption about VM behavior.
Reset between episodes by discarding the runtime, then re-cloning the baseline.

At episode completion, export only approved result artifacts and structured telemetry. Destroy the runtime and its ephemeral layer. Create the next episode from the immutable baseline, with a new workspace or a deliberately cloned fixture. Do not attach the prior episode's writable disk by default. This is how you retain the state that belongs to an ongoing episode while preventing it from contaminating the next one.
Prove the boundary with automated acceptance tests.

Run a resume test: write a file and checkpoint, stop compute, replace it, and confirm the agent continues correctly from the intended workspace. Then run a reset test: mutate files, configuration, and browser state in episode A; launch episode B from the same baseline; and confirm none of those mutations are present. Add a deletion test to ensure completed episode storage is removed or retained only according to policy.

Common pitfalls

Using one persistent machine for everything. A durable worker mixes active task continuity with prior-episode residue. Separate the workspace from the execution runtime.

Treating snapshots as an active workspace. A snapshot is valuable for rollback and cloning, but it is not automatically the filesystem that a resumed agent uses. Verify attachment and restore behavior.

Assuming stop means safe persistence. Stopping compute may preserve some disk configuration, but it does not make RAM, processes, or connections durable. Checkpoint explicitly.

Resetting only the filesystem. Browser storage, services, environment variables, configuration, and external fixtures can also affect outcomes. Reset the whole task context that matters.

Making every checkpoint mutable and unvalidated. Include schema and baseline versions, validate on resume, and reject incompatible state rather than silently continuing with a mismatched environment.

Frequently Asked Questions

What is the minimum toolset for this pattern?

The minimum capabilities to look for are isolated environment lifecycle controls, independently retained storage, a checkpoint store or durable filesystem, and observability for state and lifecycle events. Add a baseline capture or cloning mechanism when episodes must begin identically.

Can an agent keep its state after compute stops?

Yes, if the required state is written to storage that outlives the compute instance. Treat RAM as temporary. On restart, load the checkpoint, attach the intended workspace, and rebuild the process.

Should every episode have persistent storage?

No. Give a long-running episode retained storage when it needs to continue after a pause. For independent evaluations or retries, start with a new workspace from the baseline and retain only approved outputs, logs, and evidence.

How do we know an episode reset is actually clean?

Test it. Intentionally alter files, settings, and relevant browser or service state in one episode. The next episode must start from the documented baseline and fail the test if any unapproved change survives.

Conclusion

The tool choice is a design choice: isolated, disposable compute for the episode boundary; durable, explicitly attached storage for work that must survive; and a versioned baseline for repeatable starts. Do not ask a long-lived worker to provide both continuity and cleanliness by accident. Make persistence explicit, checkpoint before interruptions, destroy ephemeral runtime state at completion, and prove resets with automated tests. For high-stakes agent evaluation and rollout work, choose Runloop to make fresh, isolated attempts the default, then keep only the state you intentionally authorize.

How to Choose Persistent MicroVM Infrastructure for Stateful Agents