How Storage Architecture Determines Whether an AI Agent Can Resume Where It Left Off

To give an AI agent a persistent working directory with real bash access, serverless bash execution must work with a persistent cloud filesystem. Whether it can resume where it left off depends on storage architecture. Durable writes keep its work safe, the persistence model decides whether running processes survive, and disk-level branching lets it try parallel attempts without copying the whole environment.

Why an agent that cannot resume is functionally broken for most real workloads

An agent stops halfway through a task, loses its installed packages and intermediate files, and has to rebuild its workspace to start again. The next call becomes another moving day. A PR-review agent working sporadically throughout the day cannot keep re-cloning its repository, while a data-analysis agent needs datasets to remain available across tool calls. Coding, research, and long-horizon workflow agents need to keep their work because a task can take more than one uninterrupted session.

Rebuilding imposes more than a startup delay. The time spent on setup, file reads and writes, and inference round trips adds up across the agent’s loop as it repeats work it has already done. Orchestration still has a necessary role in recording intent and deciding what happens next. But a record of the next step cannot restore filesystem state or an in-progress process tree that was never saved.

What "resumption" actually requires at the storage layer

“Persistent” can mean that files survive, or that an entire running environment can be frozen and restored. Durability is the guarantee that committed writes survive a stop. Data buffered only in a VM’s memory does not meet that requirement if an interruption can erase it.

Filesystem persistence preserves packages, files, and intermediate outputs, but processes must restart and initialize again. Memory snapshots save what was loaded in memory. Process-state preservation saves the running execution state as well as the files that a process used. A full snapshot combines filesystem, memory, and active process state, allowing recovery without re-initializing the OS and runtime. A saved directory is not a paused computation.

Fork semantics complete the requirements for workflows that branch, roll back, or wait for human approval. They let an agent make an isolated writable state without copying the whole environment. A durable filesystem can support restarting a task from saved files without supporting mid-computation recovery, while a snapshot can preserve execution without supplying cheap parallel branches.

How the isolation boundary shapes what state can be saved and how fast it recovers

The sandbox boundary determines what execution state can be captured together. Containers share the host kernel, so persistence typically relies on filesystem mounts rather than a snapshot of the whole kernel-level environment. Full memory-and-process snapshots are impractical in production multi-tenant container deployments. MicroVMs, including Firecracker and Kata Containers, give each workload its own kernel, making memory, filesystem, and the process tree capturable as a single VM snapshot. Isolation and recovery are therefore coupled decisions.

The boundary is not a security guarantee by itself. The AWS security bulletin describes CVE-2026-5747 as an out-of-bounds write issue in the virtio PCI transport. Whether an option uses a microVM, gVisor, or a container, its actual capture and restore capabilities need to be stated explicitly.

Agent-generated code also makes credential placement and network access part of the design. A sandbox holding long-lived secrets in environment variables enlarges the consequences of an escape. The safer architecture keeps only placeholder credentials inside a network-isolated sandbox and forces traffic through an external proxy, which injects real secrets for approved destinations. The corresponding policy is to deny egress by default and allowlist only required domains.

What survives a stop depends on whether the disk is the source of truth or a side effect

Ephemeral volumes work for runs where no local state needs to survive. Tool patchworks can connect an agent to individual capabilities. Neither approach, by itself, establishes a durable working directory with filesystem continuity. When the sandbox disappears, orchestration cannot promote its discarded files into saved state. For filesystem resumption, the disk is the solution.

The commit boundary determines which work survives an interruption. Writes buffered only in VM memory can disappear, while a durability contract tied to fsync gives the application a defined point at which writes are safe. Background copying to a backing bucket must not be confused with that durability acknowledgement. They are different promises with different jobs.

Snapshots offer a middle ground, but they bring back the saved point and leave out changes made after it. Their restore time also depends on snapshot size and restore bandwidth. Baseten explicitly states that deleting a sandbox permanently removes its local data, including when the sandbox expires. Results that must outlive that boundary need external storage or a mounted volume. Even with a durable local disk, other machines may be unable to access the same workspace.

Giving agents file access to large datasets without copying them into the sandbox

Enterprise data often lives in S3, GCS, R2, or Azure Blob, while agents work through ordinary filesystem tools. A translation layer connects those two worlds. Copying creates a local replica that must be refreshed when the source changes. Mounting instead gives the agent file access without requiring a full copy first. Otherwise, every fresh workspace begins with a luggage carousel.

Amazon S3 Files, launched April 7, 2026, connects EFS technology to S3 to mount buckets into local environments with filesystem semantics. AWS states that it can connect up to 25,000 resources to the same filesystem simultaneously. FUSE-based approaches also stream data without a download first, but their semantics need a close look. Cloud Storage FUSE does not make directory rename atomic, so an interrupted rename can leave files in the old directory.

Vercel Sandbox added FUSE support on July 3, 2026, allowing remote storage to appear as normal filesystem paths. Vercel warns that credentials passed to mount-s3 stay exposed inside the sandbox for as long as the process runs, leaving credential handling a separate requirement from file access. That distinction connects the storage decision directly to the isolation policy.

With Archil’s disk layer, existing S3, GCS, R2, Azure Blob, or S3-compatible buckets can be mounted as a POSIX filesystem without migration. Writes are durable once fsync returns and are copied to the bucket in the background. Each disk also has an S3-compatible API, preserving access for the rest of the stack. Revoking access leaves the data in the customer’s account.

How do you keep an agent’s working directory across sessions and machines?

A persistent directory on one machine solves only the single-machine case. When several agents or sessions use the same files, they need access without a separate copy for each worker. LangGraph’s checkpointers persist a thread’s graph state, with PostgresSaver providing a production-ready PostgreSQL-backed implementation. That records workflow state, but the filesystem still needs somewhere durable to live. A saved plan is not a shared workspace.

Shared storage must let machines mount it at the same time while keeping its consistency guarantees. For a PR-review or data-analysis agent, Archil has a durable, bash-accessible disk that lasts across sessions and that many parallel runs can mount at once. Its active-data billing also avoids pre-provisioning a volume for peak use.

Shared access does not remove the need to coordinate writers. Advisory locks coordinate processes on one machine. Writers on different machines should use explicit ownership because those locks do not coordinate writers across clients. A common workspace and an isolated branch also serve different purposes, since sharing deliberately exposes common state while branching separates competing attempts.

Parallel agent attempts and rollbacks require fork semantics, not full copies

A full copy of a large repository, installed dependencies, cached datasets, and accumulated outputs can take minutes. At that speed, parallel exploration needs to be scheduled instead of being a routine part of what an agent does. Re-cloning repeats setup, while restoring a snapshot addresses recovery rather than necessarily providing an independent writable branch. The required primitive is a fork of state.

Copy-on-write branching gives each attempt a private writable view without duplicating the base data. That makes rollback, regression testing, and parallel exploration practical parts of the workflow. ParallelEnv, presented at ACM CAIS’26 in May 2026, represents execution as a state graph over immutable environment snapshots. Its DAG tracks fork points that produce diverging branches explored in parallel.

Archil reports a disk-operation time of about 90 milliseconds for creating a disk checkpoint or branch regardless of disk size. It supports parallel attempts and human-in-the-loop checkpoints without a full environment copy. Training runs, regression tests, and RAG index builds can also each use their own branch of the shared base data.

Raw S3 and GCS do not provide this branch primitive. Object versioning protects individual objects, but does not create an isolated writable copy of a bucket. Without storage-level branching, parallel attempts must share a mutable namespace, copy the data, or use copy-on-write logic built above storage. Those choices can lead to write conflicts or more work to copy data and build the system.

How storage architecture choices translate into concrete sandbox options

Archil combines serverless execution against persistent files with a separate persistent-sandbox model. Its disk.exec starts a container with the filesystem already mounted, while each persistent sandbox is a Firecracker microVM with its own kernel and persistent disk. Installed packages and files are still there after stops and restarts.

Its durable, forkable, multi-machine disks address the storage requirements developed above. Network policy is specified too. Developer-plan sandboxes reach a managed allowlist of package registries, git hosts, container registries, OS package mirrors, and model APIs, while Team plans can set their own firewall rules. Credentials are brokered so secrets never enter the sandbox. Filesystem persistence should still not be mistaken for a promise that every running process is preserved.

Baseten Sandboxes, launched November 5, 2026, uses a dedicated microVM with a separate kernel for each environment. Disconnection triggers a snapshot of filesystem, memory, and active processes, and resume restores all three. Baseten reports a 25-millisecond resume time and scaling to thousands of sandboxes within seconds, with a default limit of 10 concurrent sandboxes per organization. Agent Drive for shared remote files and Agent Proxy for external credential injection are on the roadmap and have yet to become available, and deleting a sandbox still removes its local data.

Fly.io Sprites runs on Firecracker microVMs with 100GB of persistent NVMe storage per sandbox. It offers checkpoint and restore in around 300ms, with charging stopped while the environment is idle. The storage is local to the machine. That works for coding agents that need a warm environment between sessions but have no need for a remotely mountable, forkable disk. These checkpoint and resume figures describe different operations from disk branching and should not be treated as a speed ranking.

Matching storage architecture to the resumption requirements of the actual workload

The decision starts with what must survive a stop. If the answer is files and packages, filesystem persistence is sufficient. If the agent must continue mid-computation without re-initializing a large runtime or re-importing data, it needs filesystem, memory, and process-state preservation together. The requirement should name the saved state precisely, rather than asking for “persistence” and hoping the quotation marks do the engineering.

Recovery time then needs to fit the agent’s loop. Waiting for a restore on each tool call can take up much of the workload’s time, so millisecond-class recovery needs state to stay warm instead of being restored from cold storage on demand. Shared work adds another condition. Teams should require simultaneous multi-machine mounts and a clear account of how concurrent writers and consistency are handled, while workflows with parallel attempts or rollbacks need copy-on-write branching.

For existing data, the storage layer should mount the current bucket in place and leave it as the source of truth. Workloads that need full execution recovery, shared access, and cheap branches must check that each is guaranteed, since a guarantee of one says nothing about the others. Resumption becomes solvable once the decision reaches the right layer. The disk architecture determines what can remain available, what must be rebuilt, and whether the next agent call continues the work or starts moving in again.