A buyer’s guide
Storage for agents
An agent’s sandbox is thrown away many times a day. Its workspace isn’t: the repository it cloned, the packages it installed, the database its tests write to, and the notes it leaves for its next step have to outlive every one of those machines.
This guide is for the engineer deciding whether to build that storage or buy it. It walks through the designs teams reach for first and where each one breaks, explains why the problem is harder than it looks, and ends with what Archil does and where it falls short. Read it in order; each chapter picks up where the last one stops.
Hunter LeathFounder & CEO, Archil
Checked November 2026The whole guide as Markdown
One workspace across a day of machines. Sandbox A clones a repository and installs its packages, and its auto-stop ends it. Sandbox B resumes on a second host until that host is retired. Sandbox C picks up on a third host. Three attempts then run at once on sandboxes D, E, and F, each on its own branch of the workspace, and the one that passes its tests is kept. Sandbox G picks up the next morning. Seven machines, one workspace.
Contents
- 01The work outlives the machineAn agent’s sandbox is disposable. Providers stop it when it sits idle, and its host can be retired with little warning. The workspace, meaning the repository, packages, databases, and notes, has to outlive every one of those machines, which sets six requirements that no classic storage design meets at once.
- 02The obvious ways to build it, and where each one breaksTeams that build storage for agents themselves tend to climb the same ladder, from the sandbox’s own disk to uploads to S3, a mounted bucket, a network volume, NFS, and JuiceFS. Each rung fixes the failure of the one before it and meets a new one. Each puts the authoritative copy of the workspace in one place, and that place decides what breaks.
- 03Why it’s hard: where the truth livesEvery storage system decides which machine may answer a read or a write without asking anyone. Speed wants that to be the machine doing the work, safety wants copies elsewhere before anything is acknowledged, and sharing wants a single authority. The design that satisfies all three keeps the truth remote and replicated and lends the right to answer to the working machine, and building it is a long list of hard problems.
- 04Copies versus referencesForking an attempt, handing a workspace to another machine, and leaving a vendor each cost either a copy of the data or a new pointer to it. A copy takes time and storage in proportion to the workspace, and a pointer doesn’t. On Archil-managed disks the first two are pointers, but leaving is a copy, because those disks use our internal format.
- 05What you pay forStorage bills for one of three things: capacity you reserve, the machine the files live on, or what you use. An agent’s workspace waits far more than it works, so which of those you pay for matters more than any rate. Billing by use needs storage that stands apart from both a reserved size and the machine.
- 06What Archil does, and where it falls shortArchil gives each agent workspace one disk that any machine can mount, replicated across availability zones before
fsync()returns, with checkpoints and branches in milliseconds at any size, billed for the data in use. It’s slower than Amazon EFS on large sequential writes, and shows other machines a new file only when their cache expires or they ask for it.
Elsewhere in the library
A buyer’s checklistEvaluating storageThe checklist for evaluating any vendor, including us: seven questions, a test for each, and a scorecard.Open the guide →A field guideHow file systems workThe mechanisms underneath, taught from the kernel up: inodes, fsync, caches, copy-on-write, and more.Open the guide →