Giving an AI Agent a Home Directory That Survives Across Serverless Invocations

An AI agent needs persistent storage and isolated compute built as one unit to have a home directory that survives serverless invocations. A durable, forkable filesystem preserves files, while a microVM that pauses and resumes preserves the working environment. Attaching a volume alone preserves only the file state of the agent’s work.

Why stateless serverless breaks when an agent needs a home directory

An agent installs packages, writes intermediate files, caches context, and stops when it is halfway through a task. The next invocation starts without that environment. Before it can go on, it must rebuild the workspace and recover whatever task state is still stored elsewhere. The files were part of the work, and losing them turns each invocation into moving day.

Serverless functions were built for stateless request/response patterns, so this failure comes from how they were designed, even outside an unusual edge case. Zhang et al.’s “From Chatbot to Digital Colleague” paper frames persistent workspaces as the shift that enables task closure and experience reuse. Returning a result is no longer enough if the next run cannot continue from it. Attaching a cloud volume and pausing a sandbox both address this mismatch, but they preserve different things.

What a home directory actually needs to preserve across invocations

Filesystem state is the first requirement, including installed packages and written files. Process and memory state is the second, covering in-flight work that should resume. These are separate promises. A mounted volume can retain everything written to disk while losing the process that was using it. The agent has its paperwork back, but not necessarily its train of thought.

Credential continuity is the third requirement, meaning access can continue without keys and tokens being repeatedly injected into the sandbox or exposed again. Isolation integrity is the fourth requirement, which keeps the agent’s environment apart from host infrastructure and other tenants. A container snapshot can keep process state without enough isolation, and sandbox processes can still read environment-variable credentials that survive a restart.

The Zhang et al. paper describes the workspace as an “execution substrate for agentic work,” connecting state persistence, reusable procedures, and task closure. That description is broader than a directory of saved documents. The directory belongs to an execution environment with memory, permissions, and boundaries. Meeting all four requirements together is where the real architecture begins.

Why isolation and persistence must be solved together, not separately

Attaching persistent storage to a shared-kernel function fixes file retention but leaves its compute boundary unchanged. A compromised workload still runs against a kernel shared with other workloads. The reverse fails differently. A strongly isolated sandbox that discards its environment on every cold start protects the host while forcing the agent to rebuild. Neither design, on its own, supplies a persistent workspace.

Firecracker and gVisor address the execution boundary differently. Firecracker gives each workload a dedicated kernel in a microVM, while gVisor intercepts system calls through a hardened user-space kernel without full VM overhead. Neither is universally correct. For multi-tenant or high-risk agent workloads, however, the dedicated kernel provides the stronger boundary, particularly when the code is hostile or supplied by users.

That boundary becomes a persistent workspace when it is paired with durable storage, pause-and-resume support, and credentials brokered outside the sandbox. Archil pairs persistent Firecracker microVMs with its own POSIX-compatible cloud file system, whose disks checkpoint and branch in milliseconds regardless of size.

How egress policy and credential handling determine whether isolation actually holds

A microVM can protect its host perfectly and still let an agent send a leaked API key over the network. Compute isolation does not fence outbound traffic. For agent-generated code, the recommended default is outbound access off until explicitly allowed, with a managed allowlist for the registries, git hosts, and model APIs it needs. In Archil’s Developer plan, that boundary restricts outbound access to a managed allowlist.

Environment-variable injection is the weakest option because every process in the sandbox can read the secret, which can also appear in logs. Runtime vault retrieval improves on this with short-lived credentials fetched during execution, but those credentials still enter sandbox memory. Proxy-based injection keeps them outside altogether. The proxy adds credentials at the network layer, so code written by the agent never gets the keys directly.

Sharing one API key couples rate limits and billing, and revoking it after one tenant’s incident interrupts another tenant’s work. The correct fix is per-tenant key partitioning at the network boundary. A credential proxy therefore does more than deliver secrets safely. It makes access continuity across restarts possible without repeatedly exposing those secrets inside the sandbox.

What “surviving a restart” means in practice: pause-and-resume versus volume remount

Pause-and-resume preserves filesystem and memory state together. The sandbox pauses when idle, retains its environment, and wakes so the agent can continue in-flight work. This suits long-lived agents with partial task state or packages that would be expensive to reinstall.

Volume remount separates storage from compute. The agent writes to a durable disk, then mounts that disk on the next invocation to recover cloned repos, downloaded datasets, and cached artifacts. This is a legitimate fit when tasks are stateless between runs but files are expensive to recreate. Process state does not survive the remount. Of the four requirements, it meets file persistence but lacks process continuity, and it still needs ways to handle isolation and credentials.

An in-sandbox FUSE daemon holds a live kernel-to-userspace connection and a live network session to the object store, neither of which serializes cleanly through a VM memory snapshot. After resume, the mount is dead. A dedicated mount process with a lifecycle outside the snapshot is required to avoid that failure. A saved directory name is not much comfort when the filesystem behind it has left the building.

Giving an agent file access to large object-storage datasets without copying them into the sandbox

Copying a full dataset into every sandbox repeats work at every invocation. For large datasets, that is slow, expensive, and unnecessary when the storage layer can expose the existing bucket as a filesystem path. With FUSE mounting, the agent can use ordinary paths inside the sandbox to access S3, GCS, R2, and compatible object stores. The agent can read and write without first copying the whole dataset. The bucket need not move just because the compute does.

These mounts fall short of local-disk performance and full POSIX semantics, and they fit dataset, model, and shared-asset reads better than high-throughput writes. Google reports meaningfully higher training throughput from Cloud Storage FUSE’s built-in caching compared with direct reads.

The same snapshot hazard applies here. A bucket mount backed by an in-sandbox FUSE daemon needs a lifecycle that will not leave it dead after resume. More broadly, the storage-agnostic goal is for S3, GCS, R2, and Azure Blob to mount the same way, without migration, an ETL pipeline, or dataset copies. In that model, the bucket stays the source of truth and the agent’s disk syncs writes back in the background.

How millisecond-level checkpointing makes parallel attempts and rollbacks a normal part of agent work

Cheap checkpoints change more than restart behavior. An agent can branch its environment, try candidate actions in parallel, and discard failed branches instead of treating every attempt as an irreversible commitment. Persistence becomes a tool for exploration. A forkable filesystem supplies part of that capability, but complete rollback also needs the corresponding process state. Otherwise, the files and the running task can return to different points in the work.

DeltaBox demonstrates this at the OS level through DeltaState, which treats filesystem and process memory as a transactional, change-based state pair. DeltaBox reports checkpoint latency reaching 14 milliseconds and a fork primitive that scales sub-linearly as the number of children grows. That enables tree-search fan-outs without duplicating the entire state. Its key insight is simple. Consecutive checkpoints differ only slightly, so copying the changes avoids copying everything the sandbox has accumulated.

AgentRewind addresses a complementary layer by coordinating restoration of agent context and the controlled environment with rewind memory. The agent can return to an earlier checkpoint while retaining information from previous attempts. This aligns the agent’s knowledge with recoverable execution. The production gap remains substantial, however, because most current sandbox platforms lack checkpoint and fork primitives, and the research does not establish DeltaBox as production-ready.

Per-tenant storage isolation in multi-tenant agent products

Agents retain persistent memory, hold access to authenticated tools, and accumulate files across requests, so separating database rows is not enough. Each dimension needs a tenant boundary. Otherwise, a product can isolate the visible records while leaving the workspace that produced them shared.

Storage becomes a weak point when all tenants’ files sit in one bucket and application logic alone decides who can access them. A single application bug can then cause a cross-tenant breach. The recommended model is a workspace per tenant. Every file operation is tied to a specific workspace ID, and storage policies enforce that boundary so it does not depend on application code alone. Envelope encryption adds tenant-specific key separation, with each tenant’s data key wrapped by a tenant-specific KMS key.

Compute separation complements this storage model but does not replace it. A dedicated microVM kernel separates one tenant’s execution from another’s, while storage policies prevent that workload from reaching another tenant’s files. When network access, credentials, compute, and storage are partitioned together, revoking one tenant’s access need not disrupt everyone else.

Choosing the right unit of composition: what to look for in a persistent sandbox

The evaluation starts with what the platform calls persistent. An assessment should check whether compute and storage give the agent a workspace it can keep using or whether the platform attaches saved files to a new run. For Archil, the persistent microVM and forkable file system provide a concrete answer to that distinction. Other designs can fit tasks that need less continuity. The test is whether their mechanism matches the state the agent actually needs to retain.

The security questions should be equally specific. What is the named isolation boundary, whether a container, gVisor, or a microVM with a dedicated kernel? What is the default egress policy, and can each sandbox have its own firewall rules? Credential handling also needs to be checked for how secrets arrive, whether through environment variables, runtime vault retrieval, or a network-boundary proxy. “Secure” is an adjective that leaves these architectural questions unanswered.

Does the environment resume, or rebuild from an image after each cold start? Can the disk checkpoint and fork, and at what latency and disk size? Production history should be judged by how long the infrastructure has handled production load, with the date a product page appeared kept separate. A research primitive and an operating service are different promises.

Storage access completes the assessment. A disk reachable over an S3-compatible API lets the rest of the stack read the agent’s work without special tooling. Mounting an existing bucket without migration, then syncing writes back in the background, keeps that bucket as the source of truth. The buying decision is therefore not simply where files survive. It is which unit of compute, storage, and access control lets the agent safely continue its work.