Blaxel Agent Drive
A shared filesystem for AI agents
98 followers
A shared filesystem for AI agents
98 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.
Free
Launch Team
Render: Get up to $100K in startup creditsCloud infrastructure for founders who want to move fast and NOT break things
Promoted
@thys_beesman right now, last write wins. We're working on session-based locks!
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 is the unsexy-but-right answer to agent collaboration — most teams end up reinventing it badly with object storage and copy-steps. The question that decides real-world use for me is concurrency semantics: when two agents write the same file, what happens? Last-writer-wins, POSIX-ish locking, or something CRDT-like? Multi-agent pipelines live or die on whether a half-written file can be read by the next agent. Congrats on the launch.
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.
Congrats on the launch. How do you handle version control? If the next write breaks it, can you easily undo it and go back to the last working version?
Exposing it as a normal filesystem path is the underrated decision. Agents are already very good at reading and writing files and very bad at learning a bespoke artifact API, so meeting them where they already are means most existing tooling just works.