If the sandbox is disposable, where does an agent's state live?

If an agent's tool calls run on short-lived compute, a fresh machine for every command, then the only thing that carries the agent's work from one call to the next is storage. That turns storage into the part of serverless tool calling that decides whether it works. The disk has to mount fast enough to do it on every call, commit writes before the call returns, behave like a normal POSIX file system for tools like git and npm, and allow parallel calls against the same files.

Why storage carries the whole state

In a session sandbox, state is spread across the machine: files on its local disk, packages installed into its root file system, environment variables, a shell's working directory, processes left running. Serverless tool calling throws the machine away after each command, so all of that disappears except what was written to storage that outlives it.

For coding and data agents, that is less of a loss than it sounds. Their real state is files: the repository, node_modules or a virtual environment, build output, datasets, scratch notes. Shell state can be passed on the command line, and the working directory can be the same on every call. Processes and memory are the exceptions, which is why long-running servers and stateful interpreters stay on long-lived machines.

Five requirements for the disk behind serverless tool calls

1. Mounting has to be cheap. The disk is mounted on every call. If attaching storage takes seconds, every ls takes seconds. Mount time belongs in the same budget as machine start time: tens of milliseconds, not a provisioning step.

2. Writes must be committed before the call returns. The next tool call may run on a different machine a few hundred milliseconds later. If writes are still in a local buffer when the first machine shuts down, the next call reads stale files or loses them. The storage has to guarantee that a call's writes are durable and visible when its result comes back.

3. It has to be a real POSIX file system. Agents use the same tools developers do. git relies on atomic renames, package managers create thousands of small files and symlinks, and test runners open files by path. Storage that only offers object reads and writes forces every tool to be rewritten.

4. Parallel calls need clear rules. An agent that fans out runs several calls at once against the same workspace. The storage has to say what happens when two of them write: locks, per-path ownership, or last write wins. Read-only mounts are the easy case and should be cheap to request.

5. The workspace should be readable without a machine. The application that runs the agent usually wants the results: show a file to the user, archive a report, hand the workspace to the next task. If reading a file means starting a sandbox, the storage is still tied to compute.

What a cold cache costs

One tradeoff comes with the territory. A fresh machine has an empty page cache, so the first read of every file in a call goes to the storage system. For tools that touch a few files, that cost disappears into the call's startup. For tools that walk a large tree, such as a recursive search or a full type-check, it is paid again on every call.

There are three ways to handle it:

• Search on the storage side. A search API that runs next to the data avoids pulling every file into a short-lived machine.
• Keep big trees warm where it matters. A long-lived machine with the same disk mounted keeps its cache between commands, which suits a heavy build or type-check loop.
• Keep the working set small. Scope searches to the directories the task is about, and ignore generated and vendored files.

Where this is implemented today

Most sandbox platforms attach storage to the sandbox: a local disk, a provider volume, or a snapshot taken when the sandbox stops. That keeps state with one machine at a time.

Archil takes the other route. Its disks are POSIX file systems that mount on Linux machines and sandboxes, and its serverless execution runs each command in its own microVM with a disk mounted. According to its documentation, a command's writes to the mounted disk are committed before the response returns, and only files written to the disk outlive the call. Disks can be mounted read-only or with a subdirectory for a single call, and in a conditional mode that lets several clients write to the same disk, with the last write to the same bytes winning.

Whichever storage you pick, check it against the five requirements above before you move an agent's tools off a long-lived machine. The machine is easy to replace. The disk is where the agent's work actually lives.