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.
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?
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.
Report
Interesting, Concurrent read write access across multiple sandboxes is exactly the kind of feature that sounds simple until two agents touch the same file at the same time. If a coding agent is mid write on an artifact and a review agent opens that same file a moment too early, what does the review agent actually see, a partial write, a lock that makes it wait, or does Agent Drive guarantee some kind of atomic visibility so nobody ever reads a half finished file.
Also curious about the failure case where a sandbox mounting the drive crashes or gets killed mid write. Does the FUSE layer roll that write back cleanly, or is there a chance of a corrupted or partially flushed file sitting there for the next sandbox that mounts it.
@thys_beesman right now, last write wins. We're working on session-based locks!
Report
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?
Report
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.
Report
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?
Report
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.
Replies
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?
Besimple AI
We use blaxel for our coding agent - great product!
Blaxel Agent Drive
@yi_zhong3 thanks for the kind words @yi_zhong3
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.
Blaxel Agent Drive
@thys_beesman right now, last write wins. We're working on session-based locks!
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.
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.