Undisk versions every file write at the MCP protocol layer, producing an immutable SHA-256 snapshot in under 50ms. No VM checkpoint, no full-environment rollback — surgical, per-file undo that preserves every other change your agent made.

This article explains the architecture that makes sub-50ms restores possible, why content-addressing matters for AI agent safety, and how to integrate Undisk into your MCP workflow.

Why Per-File Versioning Matters for AI Agents

Per-file versioning solves the core problem of AI agent file safety: recovering from a single bad write without losing everything else. AI agents write files constantly. They generate code, update configurations, produce reports, and modify data. When an agent makes a mistake — and they do, frequently — the standard recovery options are painful:

  • VM-level rollback destroys all progress since the last snapshot, not just the bad write
  • Git-based recovery requires the agent to have committed before the error
  • Manual intervention breaks the autonomous workflow entirely

Undisk solves this by versioning at the individual file level. Every write_file, create_file, or delete_file operation through MCP creates a new immutable version. Restoring a single file to any prior state takes under 50ms and leaves every other file untouched.

The Architecture: Durable Objects + R2

Undisk achieves sub-50ms versioning by combining Cloudflare Durable Objects for metadata with R2 for content storage, with an inline optimization that keeps most files in SQLite. Undisk runs on Cloudflare’s global edge network using two storage primitives:

Durable Objects (DO) handle metadata and coordination. Each workspace gets its own DO instance with an embedded SQLite database. This database stores version pointers, file metadata, timestamps, and content hashes. With less than 1GB of metadata per workspace, the DO stays well within Cloudflare’s 10GB limit per object.

R2 Object Storage holds the actual file content. R2 provides unlimited capacity with zero egress fees — a critical property when agents read files far more often than they write them.

The Inline Optimization

Files smaller than 128KB skip R2 entirely. They’re stored directly in the DO’s SQLite database, eliminating the network round-trip to R2. Since most source code files, configuration files, and small documents fall under this threshold, the majority of agent operations never leave the DO.

This tiered approach means the storage layer adapts to file size rather than treating every file the same way.

How a Write Operation Works

A write operation goes through six steps — from MCP request to versioned response — in under 50ms at the 95th percentile. Here is the step-by-step flow when an AI agent writes a file through Undisk:

Step 1: Receive the MCP Request

The agent sends a write_file tool call through the MCP Streamable HTTP transport. The request arrives at the nearest Cloudflare edge location — one of 300+ data centers globally.

Step 2: Route to the Workspace Durable Object

The gateway routes the request to the correct workspace DO based on the workspace ID. If the DO is hibernated (no recent activity), Cloudflare wakes it in single-digit milliseconds.

Step 3: Hash the Content

The DO computes a SHA-256 hash of the file content. This hash serves as the content address — if two files have identical content, they share the same hash and the same stored blob. This is the same content-addressing pattern used by Git and IPFS, and it is patent-free.

Step 4: Store the Blob

If this content hash is new (no existing blob matches), the file content is written to storage. Files under 128KB go into SQLite inline. Larger files go to R2.

If the hash already exists, no write is needed — the content is already stored. This deduplication happens automatically and saves both storage space and write latency.

Step 5: Create the Version Record

The DO inserts a new version record into its SQLite database. This record contains:

  • The file path
  • The content hash (pointer to the blob)
  • A monotonically increasing version number
  • The timestamp
  • The file size
  • The acting agent’s identity

This version record is immutable. It cannot be modified or deleted through the API. The audit trail is tamper-evident by design.

Step 6: Return the Response

The DO returns the version metadata to the agent: the new version number, content hash, file size, and timestamp. Total elapsed time from request to response is typically under 50ms at the 95th percentile.

How a Restore Operation Works

Restoring a file creates a new version pointer to existing content — no data copying — making it faster than a write. Restoring a file is even simpler than writing one:

Step 1: Look Up the Target Version

The agent calls restore_version with a file path and version ID. The DO looks up the target version record in SQLite — a single indexed query.

Step 2: Create a New Version from the Old Content

The DO creates a new version record pointing to the same content hash as the target version. The file’s current state now matches the restored version, but the restore itself is versioned. You can undo an undo.

Step 3: Return the Result

The agent receives confirmation with the new version metadata. The restore did not touch any other file in the workspace. No content was copied — only a new version pointer was created.

Content-Addressing and Deduplication

SHA-256 content-addressing gives Undisk automatic deduplication, integrity verification, and efficient diffing — all without extra configuration. The SHA-256 content-addressing scheme provides several properties that matter for AI agent workflows:

Deduplication: Agents frequently write the same content to the same file (idempotent operations, retries, regeneration). Content-addressing means these redundant writes consume zero additional storage.

Integrity verification: Any consumer of a file can verify its content against the stored hash. If the content does not match the hash, the file has been tampered with or corrupted.

Efficient diffing: The version history stores content hashes, not full copies. Comparing two versions starts with a hash comparison — if the hashes match, the versions are identical, and no byte-level diff is needed.

Concurrency and Scale

Each workspace DO handles approximately 1,000 requests per second. Cloudflare Durable Objects provide single-threaded consistency within a workspace, which simplifies concurrency guarantees for version ordering and content-addressing.

WebSocket hibernation eliminates duration charges during idle agent sessions. An agent can maintain a persistent connection to its workspace without incurring compute costs when no operations are in flight.

The Cost Structure

Infrastructure cost per workspace is under $0.05 per month at scale, yielding gross margins above 99% at a $10/workspace price point. The tiered storage architecture keeps infrastructure costs remarkably low:

At launch scale — 100 workspaces processing 500,000 operations per month — total infrastructure cost is approximately $6.34 per month. At 10x scale (1,000 workspaces, 5 million operations), the cost rises to roughly $41.44 per month, or about $0.04 per workspace.

At a price point of $10 per workspace per month, gross margins exceed 99%. The per-operation cost is dominated by Durable Object request charges ($0.15 per million requests), which remain negligible at any reasonable scale.

Why This Matters for Compliance

Undisk’s version history is the audit trail — every operation creates an immutable record that satisfies EU AI Act Article 12 requirements by design. The EU AI Act (effective December 2, 2027 for deployers of high-risk systems) requires tamper-evident audit trails under Article 12. Every file operation recorded by Undisk — writes, deletes, restores, moves — creates an immutable version record that satisfies this requirement.

The version history is not a bolt-on feature. It is the storage model itself. You cannot write a file without creating a version. You cannot delete a version through the API. The audit trail is structural, not optional.

Getting Started

Any MCP client can use Undisk’s versioning tools without special integration — connect and start writing. Undisk exposes its versioning through standard MCP tools. Any MCP client — Claude, Cursor, Windsurf, custom agents — can use these tools without special integration:

  • write_file / create_file — create content with automatic versioning
  • read_file — read current content with version metadata
  • list_versions — retrieve the complete version history for any file
  • restore_version — restore to any prior version in under 50ms
  • get_diff — compare any two versions line by line

Every tool call returns the version number and content hash, giving agents full visibility into the state of their workspace.

Summary

Undisk versions every agent write by combining Cloudflare Durable Objects (metadata + small files) with R2 (large file storage) and SHA-256 content-addressing (deduplication + integrity). The result is sub-50ms restores, surgical per-file undo, and a tamper-evident audit trail — all at infrastructure costs under $0.05 per workspace per month at scale.

The versioning is not a feature you enable. It is how the storage works.