Serverless bash execution on a persistent cloud filesystem gives AI agents a workspace without making every command an infrastructure project. The useful inversion is simple. Keep the agent’s state on a durable disk, then bring execution to that disk. A command becomes an operation on storage that leaves the durable workspace in place.
Why the serverless model breaks for AI agents
Traditional function-as-a-service assumes brief calls with no dependable local state between them. Agent workflows pull in the opposite direction. They create intermediate files, run validations, call several tools, and come back to unfinished tasks over long periods. Dependencies, caches, and test runners are parts of that work that need to stay in place.
Forcing this workflow into stateless invocations means rebuilding environments and reloading tooling. This adds time to warm up, and debugging has to span separate events. The standard workaround provisions a sandbox, moves data into it, and manages its eventual teardown. That trades one problem for another. The agent needs a workspace that already holds its state, so the architectural question is what that workspace should look like.
What compute-follows-storage actually means in practice
In the usual model, compute comes first. An environment gets provisioned, data gets wired into it, and someone owns the cleanup. Compute-follows-storage reverses that order by making the disk the lasting object, holding installed packages, intermediate files, and accumulated state. Execution runs in that workspace and sends back a result.
For example, searching logs means running a command against files already on the disk. A later validation can use artifacts written by an earlier command. Bash is a natural interface for this arrangement because models are heavily trained on command-line tools and filesystem operations. It also avoids expanding the agent’s context with a bespoke MCP tool for every task.
The persistent filesystem layer: POSIX access to object storage without copying
With Archil’s cloud filesystem, S3, GCS, R2, and Azure Blob buckets appear as real POSIX directory trees without copying or migration. The bucket remains in the customer’s account as the source of truth. Revoking access leaves the data where it is.
POSIX semantics include atomic rename, mmap, fsync, hard links, symlinks, and sparse files, so existing shell tools run unmodified. Reads served from the local SSD cache avoid another trip to object storage, benefiting repeated reads and small-file operations. Durability has a specific boundary, however. Writes are durable across multiple Availability Zones in the cache layer once fsync returns, with optional background synchronization to the customer’s S3 bucket. Plain sync does not provide that multi-AZ guarantee.
Mounting also removes the agent’s need to remember which objects it previously downloaded, a record that can disappear during context compaction. Disks remain accessible through an S3-compatible API for other parts of the stack. Capacity need not be guessed in advance. Storage is elastic and metered on active data.
Serverless execution: running one command against a disk in a fresh microVM
Archil implements the execution primitive through calls such as disk.exec("grep ERROR logs"). Each call starts a fresh Firecracker microVM with the filesystem already mounted, runs the command to completion, and returns stdout, stderr, and an exit code. The command ends, but the disk remains. Treating execution as an atomic disk operation removes the separate provisioning and teardown steps from the agent’s workflow.
The service launched in April 2026. Each command gets 2 vCPU and 4 GiB of memory and can run for up to five minutes. Heavier commands warrant evaluating persistent sandboxes instead.
Serverless execution is available in aws-us-east-1, aws-us-west-2, and aws-eu-west-1. GCP serverless execution is not yet available, but direct FUSE mounts work in any supported region. Execution is billed per call, at $0.05 per 1,000 calls on Developer and Team with the call’s CPU and memory included, and Free includes 1,000 calls a month. For frequent short commands, each invocation is priced as a call rather than as a separate compute reservation.
Isolation in practice: why microVMs are the right boundary for agent-generated code
Agent-generated bash needs more than a process boundary. Standard containers share the host kernel, so container escape is a risk when untrusted code reaches that kernel. Firecracker microVMs on KVM instead give workloads their own Linux kernels, and root inside a guest grants no host privileges. With a fresh microVM for each command, hardware enforces the boundary around each execution.
There is also a middle ground in gVisor. Its Sentry re-implements the Linux syscall ABI, exposing only a narrow, seccomp-filtered set of host syscalls. That can suit compute-heavy agents with limited I/O where full VM overhead is undesirable. The choice depends on the workload and required boundary.
Firecracker published its first escape-class CVEs in 2026. CVE-2026-5747 is an out-of-bounds write into the VMM heap, rated CVSS v4 8.7 high, whose path to host code execution requires additional preconditions such as a custom guest kernel or specific snapshot configurations. CVE-2026-1386 is an arbitrary host file overwrite through a jailer symlink, rated CVSS v4 6.0 medium. Both require non-trivial follow-on steps to weaponize. They make defense-in-depth essential rather than erase the distinction between microVMs and shared-kernel containers.
Egress policy and credential handling as part of the execution boundary
Isolation controls where code runs, but network policy controls what it can reach. For agent-written code, outbound access should stay blocked until it is explicitly allowed, and credentials should be injected at the network boundary so the program never receives them. These controls complete the execution boundary provided by the guest kernel.
On Archil’s Free plan, sandboxes can reach only a managed allowlist covering package registries, Git hosts, container registries, OS package mirrors, and model provider APIs, and all other egress is denied. On Developer and above, each sandbox can have its own policy with domain and CIDR rules, including deny-by-default, and deny rules take precedence over allow rules. A sandbox created on those plans without a policy has unrestricted egress.
Policies support dynamic updates without restarting the sandbox. Forwarded requests include headers identifying the original hostname, scheme, port, path, and sandbox ID, enabling per-request audit trails. Brokered credentials never enter the sandbox, so compromised code cannot steal secrets it never had. Ports also remain private until explicitly exposed.
Persistent sandboxes for long-running agent loops alongside serverless execution
An agent loop, a development server with a preview URL, or an expensive-to-start process held in memory fits a persistent sandbox better than a one-off command. Sessions can run for extended periods, pause with processes intact, and resume with the working environment preserved.
A persistent sandbox with durable storage, such as Archil’s Firecracker microVMs paired with forkable disks, preserves dependencies, caches, and intermediate files across repeated attempts. Its persistent sandboxes have been generally available since September 2026 and accept public or private OCI images with a broader range of vCPUs and memory than serverless execution. The two modes share the same storage substrate. An agent can use short serverless commands and a long-lived sandbox against the same filesystem without duplicating state.
Branching and checkpointing: parallel agent attempts without duplicating data
When storage comes first, an agent can try other approaches through disk branches without copying an entire dataset. Independent snapshots let separate runs work without overwriting one another, leaving their outputs available for comparison. Rollback becomes a normal storage operation. An unsuccessful attempt need not take the workspace down with it.
Archil-managed disks checkpoint and branch quickly regardless of disk size, with that speed claim limited to disk operations and separate from the time required to fork a full running sandbox with CPU and memory state. Persistent sandboxes separately support pausing with memory snapshots or forking to explore multiple approaches without rebuilding the environment.
There is an important ownership-related limit here. On Developer and Team, bring-your-own-bucket disks do not support checkpoints or branching; Enterprise offers bring-your-own-bucket disks that do. The fast checkpoint-and-branch behavior applies to Archil-managed disks on every plan, so workflows built around parallel attempts must distinguish the storage modes before assuming those operations are available.
Shared disks for multi-agent fan-out over large datasets
A shared disk lets a planner hand work to executor agents without replicating the dataset into every environment. Each executor accesses the same filesystem, and subagents can fan out over large datasets for full-text search or aggregation. Multiple disks can also be composed into one command. For example, a read-only customer disk and a read-write session disk separate source data from working output through filesystem permissions.
Archil’s flock and fcntl locks apply only per client. Concurrent cross-client writes to the same file may lose data, with the last write to reach the disk winning. Writers should therefore coordinate through checkout/checkin delegation, read-only or conditional mounts, and explicit ownership.
Cached directory listings can keep a reader that is already running from seeing new files until it runs archil invalidate-cache. That condition is especially relevant when one agent waits for another’s output.
Per-tenant storage for multi-tenant AI agent products
Each tenant’s code runs in a separate microVM, while its disk mounts only into its own execution environment. Secrets belong to each sandbox and stay separate across tenants. Programmable egress binds the tenant’s allowlist to the sandbox lifecycle, provisioning it at creation and removing it at destruction.
A connected S3, GCS, R2, or Azure Blob bucket stays in the customer’s account, so offboarding can revoke access without moving the data. Cache nodes run alongside compute, and moving data across regions must be explicitly configured. Residency remains the customer’s choice. Metering active data also avoids reserving storage capacity for every tenant despite widely varying usage.
Where this model fits and where it doesn't
Compute-follows-storage suits agents that revisit workspaces, process large unstructured datasets, or explore parallel attempts. It also fits multi-tenant products that need scoped storage and execution without pre-provisioning capacity for each customer. Documents, logs, code, and artifacts work well as inputs. Data with a clean schema may still belong in a database, because filesystems and databases solve complementary problems.
The limits are just as concrete. Commands needing more than 2 vCPU / 4 GiB exceed the current serverless shape, GCP lacks serverless execution, and tightly coordinated cross-machine writes cannot rely on distributed advisory locks. Those constraints can outweigh the convenience of running bash directly against stored state. Persistent sandboxes address some compute needs, but they do not make storage coordination rules disappear.
Amazon S3 Files, launched April 7, 2026, offers teams deep in AWS a competing native filesystem abstraction alongside Archil and other options. The meaningful comparisons concern POSIX semantics, branching, multi-attach behavior, and execution bundling. Production maturity deserves scrutiny too. Archil’s Firecracker runtime has run production workloads since 2025, but an evaluation should still examine failure modes, isolation boundaries, and operational limits.