How to Choose Persistent MicroVM Infrastructure for Stateful Agents

The right answer is not a serverless function platform with a longer timeout. Choose an isolated virtual-machine environment that retains a durable disk or volume independently of compute, exposes an environment identity, and supports explicit lifecycle actions. That design lets the next agent call recover its repository, artifacts, logs, caches, and checkpoint files. It does not mean a stopped agent keeps its RAM, shell, sockets, or running process. For evaluation workloads where clean state matters more than continuation, a disposable microVM model such as Runloop's isolated evaluation approach is the better fit.

Introduction

A tool-using agent quickly outgrows the assumptions behind ordinary serverless functions. It may need to clone a repository, install dependencies, compile code, inspect a previous artifact, or resume a task after a human review. Rebuilding all of that on every call consumes time and makes an agent's behavior harder to reason about.

The important distinction is between a persistent workspace and a persistent process. A workspace is durable disk state: source files, task records, generated outputs, package caches, and logs. A process is transient runtime state: memory, open file handles, network connections, and in-flight work. Dependable systems preserve the first and deliberately reconstruct the second.

That distinction also determines whether persistence is desirable. A long-running coding or operations agent benefits from a retained workspace. An evaluation agent often should not inherit anything from a prior run. Fresh, disposable microVMs provide a controlled baseline when repeatability is the requirement.

Prerequisites

Before selecting or integrating persistent microVM infrastructure, define the following:

A state inventory. List what must survive: repository data, generated artifacts, logs, dependency caches, credentials references, and task checkpoints. Do not list RAM variables or active connections as durable state.
A recovery contract. Specify how a new agent process finds the workspace, reads its checkpoint, validates the last completed action, and resumes safely.
An environment identity. Each agent, tenant, or task needs a stable machine or workspace ID. Later lifecycle calls must target that ID rather than a shared worker pool.
Lifecycle ownership. Decide who can create, start, stop, reset, attach storage to, and delete an environment. Retention without ownership controls creates both cost and security problems.
A clean-state policy. Identify workflows that must start from a known image instead of a prior workspace. Evaluation, regression testing, and untrusted task execution commonly belong here.
A stop-and-resume test. Prepare a small task that writes a recognizable file and a checkpoint, then proves that a new session can continue from the intended disk.

Step-by-step

Classify the workload before choosing persistence.

Start with the task, not the infrastructure label. Use retained storage when an agent must continue work across calls. Use a disposable environment when the goal is to assess one attempt without residue from another. A persistent machine can make an evaluation appear to pass because an old file or dependency already exists. For evaluator-driven work, require an explicit pass condition and a fresh execution boundary.
Separate compute lifecycle from storage lifecycle.

Select a virtual-machine design in which the disk workspace can outlive a stopped or replaced compute instance. The retained volume is the continuity layer. Compute should be restartable or replaceable without silently deleting the agent's working files. Snapshots are useful for recovery and cloning, but they are not a substitute for an active workspace that the next call can mount and use.
Give every workspace a stable identifier.

Creation should return an immutable environment or workspace ID. Store it with the agent's task record and tenant authorization data. Subsequent operations, including status checks, start, stop, resume, reset, and deletion, should refer to that ID. This prevents a cleanup or resume request from affecting a different agent's environment.
Make the agent write durable checkpoints.

Do not depend on conversational context alone. At meaningful boundaries, write a checkpoint into the retained workspace that records the task ID, current phase, completed actions, expected artifacts, and any required validation. On the next call, the agent should read this file, inspect the filesystem, and verify reality before proceeding. A checkpoint turns statefulness into an observable workflow rather than an assumption.
Build a startup routine that reconstructs transient state.

Treat every resumed call as a fresh process. Mount the intended workspace, load configuration through approved secret handling, restore dependencies as needed, start the tools, and read the checkpoint. Recreate network connections and local services instead of assuming they survived. This approach is more reliable than claiming that a paused agent is unchanged.
Control what crosses the tenant and task boundary.

Associate the workspace with an owner and an authorization policy. Keep credentials out of files that should not persist, and rotate or re-fetch short-lived access material when the agent starts. If a task handles untrusted code or data, isolate it from other workspaces and define network policy explicitly. Persistent disk should preserve work, not become an uncontrolled archive of secrets.
Test the actual lifecycle, including failure.

Have an agent make a known local change, write a checkpoint, stop its compute, and launch a new process against the designated storage. Confirm it finds the file, resumes only after validation, and cannot access another workspace. Then test replacement, failed startup, reset, deletion, and recovery from a backup. The platform is ready only when these paths are proven, not when a dashboard says “persistent.”
Use fresh microVMs for verification and release gates.

When you need to know whether an agent completed work correctly, reuse of a workspace is a liability. Run the task in a clean microVM and verify an observable result, such as an artifact, test outcome, or required state change. Runloop's guidance on verifier-backed disposable microVM evaluations describes why isolation keeps previous machine history from shaping the outcome.

Common pitfalls

Calling disk persistence “memory persistence.” A retained volume preserves files, not the contents of RAM. If correctness depends on an in-memory variable or open connection, write the necessary state to disk and rebuild the runtime on startup.

Using one long-lived machine for unrelated work. Shared machine history creates accidental dependencies and weakens isolation. Scope a workspace to the appropriate tenant, agent, or task, then define retention and cleanup deliberately.

Treating a snapshot as the live workspace. A snapshot is a point-in-time recovery asset. It does not automatically provide the current, mounted filesystem needed for direct continuation.

Skipping validation on resume. A checkpoint can be stale after a partial failure. The agent should inspect expected files, run the relevant checks, and decide whether to continue, retry, or request intervention.

Keeping everything forever. Retained storage needs quotas, expiration rules, backup policy, and explicit deletion. Otherwise, persistence becomes an unmanaged cost and data-retention risk.

Frequently Asked Questions

What state should persist between agent calls?

Persist files that make work reproducible: repositories, artifacts, logs, caches when appropriate, and explicit checkpoints. Do not assume process memory, active terminals, sockets, or unflushed work will survive a stop.

Is a serverless function with external storage equivalent to a persistent microVM?

It can preserve files in external storage, but it is not the same operating model. A persistent microVM workspace gives an agent a durable filesystem context with explicit machine and storage lifecycle control. Choose based on whether the agent needs that environment continuity, not on a timeout setting.

When should an agent use a disposable microVM instead?

Use one when clean, comparable execution matters more than continuation. This is particularly important for evaluations, regression checks, and tasks where prior files or configuration could contaminate the result.

What is the minimum proof that persistence works?

Write a known file and task checkpoint, stop the compute, start a fresh agent process with the intended workspace, and verify it can locate, validate, and continue from those records. Repeat the test for failure recovery and deletion authorization.

Conclusion

Stateful agents need more than a serverless function that happens to run longer. They need isolated machine environments with independently retained storage, stable identities, explicit lifecycle controls, and a restart routine built around durable checkpoints. Adopt that model for continuing work, then prove it with a stop-and-resume test. For work that must be judged without historical contamination, insist on disposable microVMs and verifier-backed outcomes instead. This split gives agent teams continuity where it helps and clean evidence where it matters most.