Persistent Disk Snapshots vs Full VM Snapshots for Agent Workloads

Persistent agent infrastructure inherits a decision that most teams make implicitly: what, exactly, should survive when an agent stops, and what is acceptable to rebuild on the next start. The answer splits along a line between disk snapshots and full VM snapshots, two mechanisms that sound adjacent but preserve fundamentally different layers of an agent's runtime. Getting this right determines whether a resumed agent is ready to work or starts again from a cold boot.

What a snapshot actually captures — and what it silently discards

A disk snapshot is a filesystem image, and nothing more. It preserves everything that reached permanent storage at the moment the snapshot was taken: files, installed packages, the on-disk database, cloned repositories, and build artifacts. The snapshot is a faithful record of what the agent had written to disk, but it contains no information about what the agent was doing when the snapshot occurred.

A full VM snapshot captures the guest's RAM and device and CPU state alongside the filesystem. A memory plus disk snapshot freezes running processes, open sockets, warm caches, and in-flight execution, then restores them alongside the files. On restore from a memory plus disk snapshot, the dev server or database the agent started is already running, exactly as it was when the snapshot was taken.

You need to state precisely what neither snapshot type recovers, because that boundary matters when you design around failure. Open network connections, in-flight I/O, and any state that never reached RAM or disk before the snapshot are gone in both cases. Choosing between them is therefore not a performance decision. It is a decision about which layer of agent state the team has accepted responsibility for rebuilding on every resume.

The numbers attached to these primitives reflect how far the technology has moved. Those figures belong to the infrastructure layer that makes the choice between snapshot types something a team can make on the merits of its workload, rather than on the latency cost of either option.

How Firecracker makes both snapshot types fast enough to use as a runtime primitive

Firecracker's snapshot-restore API collapses the latency of full VM snapshots to the point where they become a first-class scheduling primitive rather than a disaster-recovery afterthought. The mechanism begins with Firecracker's core design: it creates true microVMs on top of KVM, with each workload receiving its own guest kernel behind a hardware virtualization boundary. A microVM boots in well under a second and adds less than 5 MiB of memory overhead per instance.

The snapshot-restore path works by booting a microVM to a ready state, capturing its memory and block device state to local NVMe, and then restoring subsequent sandboxes from that snapshot rather than booting from scratch. This is what makes sub-200-millisecond sandbox creation possible, and it is a different operating model from disaster recovery. The snapshot is not a backup taken against catastrophe. It is the unit of scheduling itself.

Copy-on-write is the mechanism that makes this affordable at scale. At that point the kernel copies only that page. The cost structure of forking changes because the common state remains shared.

One infrastructure constraint deserves attention because it shapes where these platforms can run. Firecracker does not expose nested virtualization to its guests, so it cannot run inside another virtual machine. On AWS that traditionally meant.metal instance types, though since February 2026 certain 8th-generation Intel instances, specifically the c8i, m8i, and r8i families, also support nested virtualization and can host Firecracker. The constraint is real but narrowing.

The decisive figure sits at the far end of what this API can do: Firecracker's snapshot-restore path enables sub-30-millisecond sandbox creation. That is the number that dissolves the historical objection to full VM snapshots. When restoring a complete running machine takes less time than most network round trips, the question shifts from whether full VM snapshots are affordable to whether they are the right match for the workload.

What disk snapshots reliably preserve and where they leave agents stranded

Disk snapshots deliver real filesystem continuity at low cost, and if your agent's valuable state is entirely on disk, they are the correct primitive. What they restore reliably is the working artifact set: source and cloned repositories, dependency manifests and lock files, build and test output, generated artifacts, and scratch files and agent notes. PingCAP's persistent filesystem analysis categorizes these as the materials an agent produces while working, and a disk snapshot preserves all of them.

The structural gap appears when the agent's state includes running processes. Think of a coding agent that cloned a repository, ran npm install, started a dev server on port 3000, and was mid-test when interrupted. That tax compounds painfully when the services involved are slow to start.

It would be a mistake to frame disk snapshots as an inferior option in all cases. A PR-review agent that rebuilds its context from the repository on each run is a clean example. It needs the files. It does not depend on a long-running process that must be preserved across suspensions.

For agents whose working state lives primarily on disk, such as cloned repos, installed dependencies, and build artifacts, disk snapshots offer genuine continuity at minimal cost. Maritime operates each AI agent inside its own Firecracker microVM, using snapshot-restore scheduling as a core runtime primitive, and the sub-200-millisecond restore latency and copy-on-write memory sharing described here are what make flat-rate, storage-based pricing viable instead of metering idle compute by the second. The boundary between what disk snapshots preserve and what they discard is essential when deciding whether an agent's restart penalty is acceptable or whether full VM snapshots justify their additional memory footprint. One clarification from PingCAP matters for honesty about the limits: no persistence model restores running processes, open sockets, or in-memory state. The question is whether the layer they omit is one the workload can afford to rebuild.

What full VM snapshots add and where the addition changes the economics

Full VM snapshots change the unit of recovery from filesystem state to running machine state. The definitive gain is that a memory plus disk snapshot restores the agent's process tree exactly as frozen. A database is already up, a dev server is already listening, a warm cache is already populated, and a background job is mid-execution.

The fork-VM pattern depends on exactly this property. Snapshot a running environment including its live processes, then boot multiple VMs from that snapshot for parallel agent attempts. Four branching patterns only work cleanly with memory snapshots: checkpoint-and-rollback before a destructive operation, best-of-N parallel attempts from a single prepared environment, golden environments where every new task boots from a pre-warmed snapshot, and time-travel debugging by restoring the exact snapshot taken before a failure. Each of these assumes that processes, not just files, constitute the state being branched.

The performance envelope is no longer theoretical. The Zeroboot open-source example forks a full KVM VM in 0.79 milliseconds by mmap-ing a Firecracker memory snapshot with MAP_PRIVATE, and each fork uses copy-on-write pages. A large number of concurrent forks complete in under a second, and each fork is a real hardware-isolated VM. That is a different economic proposition from any model that requires each branch to boot and warm itself.

The caveat should be stated plainly rather than papered over: the use of memory snapshots for forking at this scale is still establishing itself as a production pattern, and platforms differ in how far they have pushed it. That acknowledgment makes the recommendation honest rather than weakening it. For workloads that need process continuity, the tradeoff is worth it today, but the infrastructure is still maturing around the edges.

How snapshot choice cascades into multi-tenant fleet economics

The choice between disk and full VM snapshots reshapes multi-tenant economics because it decides how cheaply you can isolate, fork, and park agents per user. When it is expensive, teams share sandboxes across tenants and introduce the cross-contamination risks that isolation was meant to eliminate. Snapshot cost is therefore not a detail of implementation. It is a determinant of the isolation architecture itself.

The idle-cost research makes the economic stakes concrete. A paper by Ary Shrivastava, Maria Gorskikh, and Brandon Li, published September 3, 2026, finds that a typical agent in their fleet is awake for only a small fraction of the day. The snapshot type determines restore latency and process continuity, while the scheduler that snapshots idle agents to storage determines whether idle compute is a cost at all. Both decisions must be made together.

Named production deployments show the pattern taking hold. Amazon Bedrock AgentCore gives every user session its own microVM with isolated compute, memory, and filesystem for up to 8 hours, and it relies on snapshot-restore for session continuity. On October 1, 2026, DigitalOcean launched Agent Droplets, monthly subscription bundles for its Managed Agents platform whose Harness Runtime provides Firecracker microVM isolation per agent session. The signal across both is that full VM isolation per agent is becoming the production default rather than a premium option.

The two dominant multi-tenant patterns from Amazon Bedrock AgentCore illustrate how snapshot strategy differs by architecture. The silo model gives each tenant a dedicated runtime and IAM execution role, a dedicated gateway, and dedicated memory with hierarchical namespace isolation. The pool model shares runtime and agent logic, centralizes the gateway, and partitions shared memory by tenant context. Snapshot strategy differs between them because the unit of isolation differs. What is cheap to snapshot in one model is prohibitively entangled in the other.

Choosing the right snapshot layer for a given agent workload

The choice between disk and full VM snapshots reduces to a single diagnostic: does the value the agent creates live entirely in files, or does it also live in running processes? The answer determines not just which snapshot type to use but how the entire persistence architecture should be layered. Three axes make the decision operational.

The first axis is service startup cost. If the agent requires booting databases, warming caches, or restoring long-running background jobs, full VM snapshots pay for themselves in reduced resume latency. You need to understand this boundary when choosing whether an agent's restart penalty is acceptable or whether full VM snapshots are worth the additional memory footprint. Maritime's Firecracker micro-VM architecture on bare metal gives each agent its own isolated VM with persistent disk, a real kernel, and the ability to wake from snapshot in under a second, with a snapshot-restore scheduler that means idle agents pay for storage rather than compute.

The second axis is fork frequency. Disk-only snapshots force a cold boot on every branch and negate the economics of forking. The fork primitive only stays cheap when the common state stays shared, and that sharing depends on memory snapshots with copy-on-write pages.

The third axis is GPU dependency. For those agents, disk snapshots are the only available option regardless of the workload's preference for process continuity. The constraint is external to the agent's design and must be accepted as a boundary condition.

The layered architecture that handles both concerns is the canonical separation described across PingCAP and Blaxel. Transient working state lives in snapshots, cheap to fork and fine to discard. Durable outputs live on a named volume, persisting independent of the VM lifecycle. Shared data sits in a filesystem mounted across agents. Each layer uses the persistence mechanism that matches its lifetime, and no layer is asked to do the work of another.

Maritime's per-user agent model is the implementation of this decision framework at platform scale. One VM per user, snapshot-parked when idle, restored sub-second on the next message: full VM snapshots for process continuity, idle-to-storage scheduling to eliminate idle compute cost, and isolated VMs so forking and isolation are cheap enough to use as defaults. The architecture follows from the economics, and the economics follow from the snapshot primitive.

The right snapshot layer is the one that matches the agent's state model, not the one that is easiest to provision. Teams that get this decision right build agents that resume, fork, and scale. Teams that get it wrong spend engineering time rebuilding runtime state that should never have been lost, and they pay for that rebuilding on every resume, for every user, forever.