Disk Snapshot Formats and Incremental Snapshot Strategies

Snapshot-restore scheduling for idle AI agents replaces running compute between tasks with stored checkpoints, then restores execution when work arrives. Disk Snapshot Formats and Incremental Snapshot Strategies explains why this works only when the snapshot strategy keeps both retained state and restore-path retrieval small. The decisive choice is not the disk format alone, but how the system captures, indexes, and resumes agent state.

Why disk snapshot format is the wrong starting point for understanding agent wake speed

Comparing QCOW2, other disk image formats, and raw images starts with compatibility and portability. Those properties matter, but they do not establish how much state a restore must touch before the agent can handle a request. That depends on what the checkpoint contains and how successive checkpoints share unchanged data. Incremental strategy therefore governs both the data retrieved on wake and the storage accumulated while parked.

This distinction separates two roles that are easy to conflate. A stored checkpoint sets how much storage the agent needs while idle, while the restore target sets what the hypervisor needs to run it again. The same state must serve both purposes, but the cheapest representation to retain is not automatically the fastest to restore. Maritime’s approach follows this distinction by tracking changed blocks to limit checkpoint storage and the data retrieved during restore.

How disk-only and disk-plus-memory snapshots differ at the format level

A disk-only snapshot captures the contents of a virtual disk. QCOW2 can represent that state through internal snapshot tables or external copy-on-write overlay images. Those structures keep block-level state, but they do not keep CPU registers or the variables in RAM. Consequently, restoring the disk still leaves init and the agent’s in-memory context to be rebuilt. A persistent workspace is not, by itself, a persistent execution state.

A disk-plus-memory snapshot captures CPU registers, RAM contents, and device state together with the disk image. It can therefore resume at the instruction where execution stopped, without a kernel boot, init, or JIT warm-up. Firecracker supports this model by memory-mapping snapshot memory, loading CPU state, and resuming execution. For agent infrastructure such as Maritime, that resume-from-instruction behavior is the primitive that makes responsive wake-up possible without keeping each agent running.

Memory restoration preserves variables, credentials, and open file handles rather than asking the application to reconstruct them from disk. Even when local execution state is saved, external connections may be lost. That boundary becomes important when deciding when an agent is safe to park.

What incremental snapshots actually record and how chains are managed

After the initial image, an incremental snapshot records only data changed since the previous snapshot. Unchanged blocks remain in earlier snapshots, and later checkpoints refer back to the versions they need. Azure’s incremental snapshots for managed disks make this model concrete by billing for delta changes since the last snapshot.

Those savings depend on preserving the relationship between each delta and its predecessors. Microsoft Q&A explains that deleting a disk and creating another from its snapshot changes the UUID, making the next snapshot full. The disk’s contents may have come from an earlier checkpoint, but that does not preserve its identity for incremental tracking. A workflow that repeatedly recreates disks can therefore lose the savings it expected from a chain. Chain continuity is a property of the storage system.

Chain length creates a different constraint. Reconstructing current state may require looking through successive links to locate the latest version of each block. A long chain can save work when a checkpoint is written but add work when it is restored. Systems that enforce a maximum chain length take a new full image at that limit and start another chain. This bounds restore-path depth, at the cost of a larger checkpoint write.

How differential manifests cut restore-path data retrieval without changing the underlying chain

A chain needs an index that tells the restore process where its objects live. If every snapshot manifest lists the full object set, a restore that goes through several layers can fetch much of the same information again and again. A differential manifest instead lists only objects belonging to that incremental snapshot but not its parent. The chain still holds the same data, but the index stops re-enumerating unchanged objects at every layer. This makes manifest design a separate lever from the disk format.

Consider a first snapshot whose manifest is {A1, B1, C1}. If the next snapshot changes only block B, its differential manifest lists B2. The restore process reads that entry and fetches B2, while resolving A1 and C1 from the first manifest without re-fetching them at the second layer. A USPTO patent documents this design and reports nearly 75% less total data retrieved in a test environment than when retrieving full manifests for all snapshots. Reductions for other agent workloads may differ from that test result.

The savings grow as a chain gains layers because the full-manifest approach repeats more information that has stayed the same. Differential manifests reduce that repetition without rewriting the underlying snapshot data. They can thus work on top of existing QCOW2 or block-device chains. For persistent agent systems that accumulate many small checkpoints, the index helps prevent checkpoint history from becoming repeated retrieval work. It makes the resolution of inherited state less wasteful.

Why Firecracker's restore path makes incremental snapshot design a latency problem, not just a storage problem

Firecracker does not need the entire memory snapshot resident before execution resumes. Its lazy restore path serves memory pages as the agent touches them, so the relevant quantity is the working set between resume and useful work. Total snapshot size still matters for storage, but it is not the same as the amount that must arrive before the agent is ready. A snapshot restore can consequently take a fraction of the time required for a cold boot. The mechanism, rather than a single latency figure, explains the advantage.

With userfaultfd-based restore, a memory service handles page faults from the snapshot. The service prepares a userfaultfd source and Unix socket, and Firecracker passes it the userfaultfd and memory-region mappings. Device state is loaded while the VM remains paused, and vCPUs resume after the handler is ready. As a result, the first page fault has a service waiting to supply its data. Execution and memory retrieval can then proceed together.

Incremental design affects how much changed state is stored and how efficiently the restore path finds it. Dirty-page-only snapshots avoid copying unchanged memory into each new checkpoint, while differential manifests reduce redundant index retrieval. However, a smaller delta does not by itself mean the agent will touch fewer pages. Its working set still sets which pages it needs, including those it inherits from earlier checkpoints.

Firecracker’s snapshot/restore API also supports branching from a shared starting state. A running sandbox can be snapshotted once and restored into N children, with copy-on-write storage and MAP_PRIVATE memory mappings.

How to stop paying for compute when agents are idle through snapshot chain design

With snapshot-restore scheduling, a VM can stop running between agent turns. Compute demand then follows active concurrency rather than requiring a running VM for every persistent agent. Storage remains, however, and its cost depends on the state retained for each parked agent. To save money, checkpoints must be small and the restore path must be fast enough to make parking work.

Maritime’s research on snapshot-restore scheduling gives this model as C(T) = c_s · S · T + c_v · ∫a(t)dt. The storage term depends on snapshot size S and how long it is kept, T, while the compute term depends on how much the agent is active over time. When an agent is awake for only a short fraction of each day, the compute integral is small. Reducing S then becomes the main lever for reducing the cost of its parked state.

The ADR-022 controller notes that, with many idle threads, snapshots risk using more disk space at roughly one guest-RAM per snapshot. Its mitigations include Firecracker diff snapshots, thin-pool storage with TTL/idle eviction, and right-sized guest RAM. Chain policy matters too, because storage must also hold earlier links that the current checkpoint still needs. Starting a new full-image chain limits the depth of the new chain, but the storage model must still count the history that is kept.

A warm pool makes the opposite trade. It keeps compute instances running even when no request arrives, paying for compute all the time so they stay ready. For bursty agents that spend most of their time inactive, snapshot-restore scheduling instead concentrates spending on active work and parked state.

Where snapshot timing and chain integrity can break agent state

The ability to capture execution at an exact instruction does not make every instruction a safe checkpoint boundary. An agent paused mid-model-call or mid-MCP-call may resume waiting for a response that can no longer arrive. The result can be a deadlocked or confused agent. Snapshot timing must therefore reflect both the agent’s in-flight work and its recent activity.

The controller pattern uses an in-microVM wrapper to detect both inactivity and quiescence. The wrapper signals that parking is safe only when no model or MCP call is in flight. Connections must also be re-established by the application on resume, because Firecracker closes vsock connections and does not guarantee surviving network connection state. This is the operational limit of the disk-plus-memory model. It preserves the agent’s local context.

Identity continuity presents a separate failure mode. Under the disk identity rules described earlier, destroying and recreating storage can force full snapshots even when the application sees the agent as unchanged. A stable thread ID keeps baseSnapshotRef and later checkpoints tied to the same agent across hosts, even as its microVM instances change. That application-level identity does not override a storage provider’s disk identity rules. Both layers must agree about which checkpoint lineage is being continued.

Durable external task state provides the backstop when that lineage is corrupted or a restore fails. With committed task state in a database, the agent can be rebuilt without depending only on the failed checkpoint. A snapshot then serves as a fast continuation mechanism rather than the only surviving account of the agent’s work.

What good incremental snapshot design looks like for a persistent agent system

A sound design separates three roles, namely the base image, the incremental state checkpoint, and the thin-clone block device. The base image is booted and warmed once with the agent harness initialized, then used as the starting point for new agents. The incremental checkpoint captures dirty pages at quiescent boundaries. The thin-clone block device supplies copy-on-write disk state from the parked volume at restore. Treating these as distinct roles allows each to be optimized for the work it performs.

The design uses right-sized guest RAM, dirty-page-only checkpoints, and a maximum chain length with automatic full-image resets. Differential manifests limit repeated object retrieval across the retained chain, while lazy memory restore supplies the working set on demand. Safe idle detection sets when checkpoints are taken, and stable thread identity keeps track of which agent they belong to across microVM instances. Durable task state is still there if continuation fails. These choices address different failure modes and cannot substitute for one another.

Maritime implements this architecture with each agent in its own Firecracker micro-VM on bare metal, a persistent disk, and a scheduler that parks idle agents at storage cost. It restores agents in about a second on the next inbound message, and its flat per-agent pricing reflects that underlying cost model. In this concrete implementation of the broader design, formats must work with the storage and execution environment, but the full snapshot strategy must keep state cheap to store, useful when restored, and quick to wake.