Source: layerfs.ai
Each agent mounts a complete writable workspace on top of shared committed history, does its work, commits what it changed, and then goes away. According to the site, compute exists only while a command runs, each Bash tool call mounts an ephemeral workspace and commits when it ends, and each file tool call is a single atomic store operation.
Agents on different machines write to one serverless store with no database server. Branches can be forked from any commit at any depth, and the site says a fork is metadata that copies no files. A same-file clash is refused with a conflict, and blame reports which step wrote each line.
Files listed in a root .lww file, which uses gitignore-style patterns, resolve conflicts in favor of the newer edit; the site suggests this for lockfiles, build output and caches. The site also claims that ignored files stay in every commit so dependencies come with each mount, and that an edit costs only the size of the edit. Its compression figures come from a demo and are not independently verified.
Why it matters if you build agents
If you run many coding agents in parallel, LayerFS would let each one work in an isolated copy and merge through commits rather than sharing one working directory. The fork speed, mount time and storage claims are the vendor's own figures, so measure them on your repository before relying on them. Shared lockfiles and caches are where a newer-wins rule could quietly replace another agent's changes, so check your .lww patterns first.
Get stories like this every weekday
One short email with the day's agent tooling news.