Every agent session starts from scratch. The artifacts it produces, the context it builds, and the intermediate work products vanish when the conversation ends. AgentDrive is a versioned file layer that gives agents persistent storage across sessions, exposed through the Model Context Protocol (MCP). It is not a vector database or a semantic memory system. It is a cloud filesystem with workspace-scoped authorization, version history, and a deliberately narrow tool surface.
The beta launched on Show HN with 140 points and active discussion. The core promise is simple: agents and humans share drives, files persist across sessions, and every change is versioned. The interesting part is how the team chose to expose storage primitives to agents and what that reveals about tool security boundaries.
Architecture: MCP as the Agent Interface
AgentDrive connects to coding agents through MCP, the same protocol that lets Claude Desktop and other clients call external tools. The connection is HTTP-based, not stdio, and uses OAuth for workspace-scoped authorization.
Setup for Claude Desktop:
claude mcp add --transport http --scope user agentdrive \
https://drive.mcp.tokencanopy.com/mcp
claude mcp login agentdriveFor Codex:
codex mcp add agentdrive --url https://drive.mcp.tokencanopy.com/mcp
codex mcp login agentdriveOnce connected, the agent sees a set of tools for reading, writing, and listing files. The MCP surface is intentionally narrow. Instead of exposing the full storage API (which likely includes admin operations, bulk transfers, and low-level blob management), AgentDrive exposes a curated set of tools that agents can safely call.
This is a deliberate security boundary. If an agent has access to the full storage API, it can delete workspaces, change permissions, or exhaust quotas. By limiting the MCP surface to file operations within a granted workspace, the blast radius of a confused or malicious agent is contained.
Workspace-Scoped Authorization
AgentDrive organizes storage into drives. Each drive is a namespace with its own access control list. Agents and human users are granted access to specific drives, not the entire workspace.
When an agent connects via MCP, the OAuth flow establishes which drives it can see. The agent cannot list drives it does not have access to. It cannot write to a drive unless explicitly granted write permissions. This is workspace-scoped authorization: the agent’s view of the filesystem is filtered by its grants.
What happens when multiple agents or users share the same drive? AgentDrive versions every change. If Agent A writes report.md and Agent B overwrites it, both versions are preserved. The version history is accessible through the web UI, but the MCP tools do not expose diff or rollback operations yet. Agents see the latest version by default.
This creates an interesting failure mode: if an agent retries a file write after a transient error, it may create a duplicate version instead of resuming the original write. The system does not expose transaction semantics or conditional writes through MCP. The agent has no way to say “write this file only if the current version matches this hash.”
Versioned Artifacts: What Does It Mean?
The term “versioned artifacts” suggests Git-style diffs or immutable snapshots. In practice, AgentDrive stores every version of every file as a separate object. When you overwrite data.json, the old version is not deleted. It is retained in the version history.
This is not Git. There are no branches, no merge conflicts, and no commit messages. It is closer to S3 versioning or Google Drive’s revision history: every write creates a new version, and the system keeps all of them.
For agents, this means:
- No merge conflicts: If two agents write to the same file concurrently, both writes succeed and both versions are saved. The last write wins for the “current” version, but the earlier write is not lost.
- No rollback tools: The MCP surface does not expose a rollback operation. If an agent writes bad data, a human must use the web UI to restore a previous version.
- No conditional writes: Agents cannot implement optimistic concurrency control. They cannot say “write this file only if no one else has changed it since I read it.”
This design is simple and safe, but it limits coordination between agents. If two agents are collaborating on the same file, they cannot detect conflicts or negotiate who writes first. They can only read the latest version and hope their writes do not clobber each other.
File Formats and Upload Sessions
AgentDrive supports Markdown, HTML, JSON, images, videos, and spreadsheets. For small files, agents write directly through MCP. For larger files, the system provides direct upload sessions.
A direct upload session is a temporary URL where the agent can POST a large file without streaming it through the MCP connection. This is a common pattern in cloud storage APIs: the client requests a signed upload URL, then uploads the file directly to blob storage. The MCP server does not see the file contents.
This matters for agents that generate large artifacts (videos, datasets, model checkpoints). Streaming a 500MB file through an MCP tool call would timeout or exhaust memory. Direct upload sessions let the agent handle large files without changing the MCP protocol.
The tradeoff is complexity. The agent must request an upload session, receive a signed URL, upload the file, then confirm completion. If any step fails, the agent must retry the entire sequence. The MCP tools do not expose resumable uploads, so a failed upload cannot be resumed from the last byte.
Share Links and Public Publishing
AgentDrive includes share links and controlled public publishing. A human can generate a share link for a file or folder, and anyone with the link can view it. The agent cannot generate share links through MCP. This is another security boundary: agents can write files, but they cannot make files public.
Public publishing is a separate operation. A human can mark a file or folder as publicly accessible, and AgentDrive generates a stable URL. This is useful for agents that generate documentation or reports that need to be shared outside the workspace.
The absence of share link generation in the MCP surface is intentional. If agents could generate share links, a confused agent could leak sensitive data by sharing the wrong file. By requiring human approval for public access, the system reduces the risk of accidental exposure.
Failure Modes and Observability
What happens when an agent tries to write a file and the operation fails? The MCP protocol returns an error, but the agent has no visibility into why the write failed. Was it a quota limit? A permission error? A transient network issue?
AgentDrive includes auditability features, but they are not exposed through MCP. The web UI shows a log of all file operations, including who wrote what and when. Agents do not see this log. They cannot query their own write history or check if a previous write succeeded.
This creates a blind spot for agent retry logic. If an agent writes a file and receives a timeout error, it does not know if the write succeeded or failed. It can retry the write, but that may create a duplicate version. It can read the file to check if the write succeeded, but that adds latency and does not distinguish between “write succeeded” and “someone else wrote the same content.”
The lack of observability tools in the MCP surface is a deliberate tradeoff. Exposing audit logs and write history would increase the attack surface and complicate the tool interface. The team chose simplicity and safety over agent autonomy.
Comparison: AgentDrive vs. Alternatives
| Feature | AgentDrive | Git + LFS | S3 + Versioning | Notion API |
|---|---|---|---|---|
| Agent interface | MCP tools | Shell commands | HTTP API | REST API |
| Version history | Automatic, all versions | Commit-based | Automatic, configurable | Page history |
| Authorization | Workspace-scoped OAuth | SSH keys, tokens | IAM policies | API keys, OAuth |
| Merge conflicts | No conflicts, last write wins | Manual merge required | No conflicts, versions preserved | No conflicts, blocks win |
| Large file handling | Direct upload sessions | LFS pointers | Multipart upload | File attachments |
| Observability | Web UI audit log | Git log, blame | CloudTrail, access logs | Activity log API |
AgentDrive sits between Git and S3. It is simpler than Git (no branches, no merges) but more structured than S3 (workspaces, drives, MCP tools). It is designed for agents that need persistent storage without the complexity of version control.
Roadmap: Public API and Self-Hosting
The beta does not include a public API or SDK. Agents can only access AgentDrive through MCP. This limits integration with custom agents or non-MCP clients.
The roadmap includes:
- Public API: REST or GraphQL endpoints for reading and writing files, managing drives, and querying version history.
- SDK: Client libraries for Python, TypeScript, and Go.
- Self-hosting: Open-source release so teams can run AgentDrive on their own infrastructure.
Self-hosting is critical for teams with strict data residency requirements or air-gapped environments. The current beta is cloud-only, which limits adoption in regulated industries.
Technical Verdict
Use AgentDrive when:
- You need agents to accumulate work products across sessions without building your own storage layer.
- Your agents produce structured artifacts (Markdown, JSON, HTML) that humans need to review or edit.
- You want workspace-scoped authorization without managing IAM policies or SSH keys.
- You are prototyping agent workflows and need persistent storage quickly.
Avoid AgentDrive when:
- You need transactional writes or optimistic concurrency control for multi-agent collaboration.
- Your agents require fine-grained observability into write history and failure modes.
- You need to self-host or integrate with existing storage infrastructure (wait for the open-source release).
- Your agents generate artifacts that require semantic search or vector embeddings (AgentDrive is a filesystem, not a vector database).
The narrow MCP surface is both a strength and a limitation. It reduces the blast radius of agent errors, but it also limits what agents can do. If your agents need to coordinate writes, detect conflicts, or query their own history, you will need to build additional orchestration on top of AgentDrive or use a different storage primitive.