Launching today
Blaxel Agent Drive
A shared filesystem for AI agents
60 followers
A shared filesystem for AI agents
60 followers
Mount one distributed filesystem across multiple sandboxes with concurrent read-write access. Agents can share files, tool outputs, datasets, and context through a normal filesystem path.
Blaxel Agent Drive
Hey everyone! Nico here, one of the founders of Blaxel.
Agents do real work in files. The awkward part starts when two sandboxes need to share that work. Teams often end up moving artifacts through an object store, rebuilding context between runs, or creating another handoff layer.
We built Agent Drive to give agents a shared place to work.
Agent Drive is a distributed filesystem that multiple sandboxes can mount at the same time with concurrent read-write access. A coding agent can write an artifact, a review agent can read it from another sandbox, and both see the drive as a normal path in the filesystem.
The demo shows the core workflow:
1. Create a drive.
2. Mount it into two sandboxes.
3. Write a file in one sandbox.
4. Read it from the other.
Under the hood, Agent Drive uses an optimized FUSE client and includes built-in replication. You can attach a drive to a sandbox that is already running, and the files remain available independently of any individual sandbox session.
Agent Drive is currently in private preview. For Product Hunt, we are opening a limited preview cohort. Tell us what your agents need to share when you request access. We will review applications throughout launch day and prioritize teams with an active multi-agent workflow that sign up with a business email.
We would especially like feedback from teams sharing tool outputs, datasets, code artifacts, dependency caches, or context histories across agents. What are your agents trying to hand off today?
Write conflicts are covered above, so here's the one that got us. Coding agents make an absurd number of tiny stat and readdir calls, and when we moved an agent workspace onto a network mount a ripgrep across a mid-size repo went from well under a second to something you feel every cycle. Is there a per-sandbox read cache in front of the drive, or does every open go to the distributed layer?
A shared filesystem that multiple agents can read/write concurrently is the part that's usually hand-rolled with S3 + locking hacks, so nice to see it as a primitive — how do you handle write conflicts when two agents touch the same file at once, optimistic locking or last-write-wins? Also curious what the latency overhead looks like versus just mounting a local volume for single-agent setups.