LayerFS 1.0: Give Every AI Agent Its Own Workspace in 20ms

Ephemeral AI Lab shipped LayerFS 1.0 on October 21, a copy-on-write filesystem that gives each AI agent a complete, isolated, writable workspace in 5 to 20 milliseconds instead of the roughly five minutes a traditional clone-plus-install cycle takes — about 15,000x faster on workspace setup. LayerFS mounts a writable FUSE overlay over a shared, content-addressed Store that already contains node_modules, caches and ignored files, so nothing is copied and the first test run starts immediately; commits store only deltas via content-defined chunking and delta encoding. The 1.0 release is Linux only, requires ext4, xfs or btrfs plus Docker, and its DSH integration supports up to eight concurrent subagents each on its own branch.

Running five parallel AI agents against the same codebase? Each one currently waits roughly five minutes to clone the repository and reinstall dependencies before it writes a single line. LayerFS 1.0, shipped October 21 by Ephemeral AI Lab, eliminates that wait entirely — it gives each agent a complete, isolated, writable workspace in 5 to 20 milliseconds, with no files copied and node modules already present. This is not a marginal improvement. At the scale where parallel agents become useful — evaluation runs, MCTS-style strategy rollouts, parallel feature branches — the workspace setup cost dominates. Cutting it from minutes to milliseconds changes the economic case for parallel agent workflows entirely. Why the Existing Solutions Are Bad The options before LayerFS are a familiar set of trade-offs, all of which fail in at least one important dimension. Shared filesystem: Zero setup cost, but agents writing to the same files produce race conditions and silent state corruption. This is not a theoretical concern — it is what happens when two agents touch the same hotspot. Git worktrees: The incumbent solution. They provide real isolation and share the underlying object store, which is efficient. The problem is that git does not store ignored files. Every worktree starts without node modules, .venv, or build caches. An agent still waits for npm install or pip install before the first test runs. Docker container per agent: Full isolation, full copy. Spinning up a container, copying the image, and installing dependencies takes minutes. Memory and disk costs compound with concurrency. What LayerFS Actually Does LayerFS uses copy-on-write over a shared, content-addressed Store. The Store contains the full committed filesystem — including .git/index, ignored files, node modules, caches, and symlinks — as immutable objects. When an agent needs a workspace, LayerFS mounts a writable view over the shared base via a FUSE overlay. The agent sees a complete, isolated filesystem immediately. Nothing was copied. Three primitives drive the model. The Store is the shared, immutable history — a SQLite-backed, content-addressed time machine for workspaces. The Workspace is the per-agent writable view mounted over that history. The Branch is the project timeline: fork it, work in a Workspace, commit what changed, and either promote the result or discard it. When an agent commits, only the delta is stored. Content-defined chunking and delta encoding mean a commit costs what changed, not what exists. Two branches sharing objects with identical canonical IDs get automatic deduplication. The Numbers Mount time is 5 to 20 milliseconds. A traditional clone-plus-install cycle runs around five minutes. The difference is roughly 15,000x on workspace setup alone. The first test run starts immediately because node modules are inside the committed state — the agent does not wait for a package manager. The DSH integration supports up to eight concurrent subagents, each on its own branch, visible in a live LayerFS tab as they work in parallel. Getting Started: The DSH Integration The intended on-ramp is through the LayerFS x DSH plugin https://layerfs.ai/docs/integrations/dsh/ . Install the dsh-layerfs bundle, point your coding agent at the setup guide on layerfs.ai/docs https://layerfs.ai/docs/ , and the agent configures itself — forking a branch, working in an isolated sandbox, and committing changes. Setup is itself a task you delegate to the agent rather than a manual configuration process. The JavaScript SDK handles the low-level fork, commit, and merge operations via short Node scripts. The full source and documentation live at github.com/Ephemeral-AI-Lab/layerfs https://github.com/Ephemeral-AI-Lab/layerfs . What 1.0 Does Not Give You LayerFS 1.0 ships with real constraints worth knowing before you commit to it. Linux only. The FUSE overlay requires ext4, xfs, or btrfs, plus Docker and Node 20+. There is no native macOS path. Windows is out. If your agent infrastructure runs on macOS laptops or Windows CI workers, LayerFS is not yet an option. No crash durability. The Store uses journal mode=MEMORY and synchronous=OFF. A process crash, OS crash, or power loss means lost data. The Durable Commit profile — with proper fsync and recovery guarantees — is planned but not in this release. This is explicitly a Developer Preview. Do not use it as your only copy of data you cannot rebuild. These are not small caveats. They are the reason this ships as 1.0 with a “Developer Preview” label rather than as production infrastructure. For local evaluation runs on Linux CI, it is entirely reasonable. For anything where durability matters, wait for the Durable profile. When to Reach for It LayerFS is the right tool when you are running parallel agents that need isolated, dependency-complete workspaces and the workspace setup time is a real cost. MCTS-style evaluation runs, parallel feature development, environment upgrade experiments — these are the cases where 5-20ms mount times change what is practical. It complements rather than replaces container-level sandboxing: LayerFS handles the filesystem isolation layer while tools like Harbor’s Docker Sandboxes https://byteiota.com/harbor-docker-sandboxes-ai-agent-eval-isolation/ handle container-level security. Use both if your threat model requires it. If you are running a single agent on a MacBook, git worktrees still work fine. The workspace tax only bites when parallelism is the architecture — and that is exactly where LayerFS is built to operate.