Zed Industries' DeltaDB Links Every Agent Code Edit to Its Conversation

Zed Industries has introduced DeltaDB, a version control system that records human and agent edits in a shared causal graph. Each change remains linked to the conversation that produced it, preserving the prompts, responses, and decisions behind the code.

DeltaDB is available through a command-line interface that works with Claude Code. It also powers Delta, Zed’s first-party harness for agent-driven coding workflows.

The missing record behind a diff

Conventional repositories retain source snapshots, diffs, authors, and commit messages. Agent sessions produce another layer of evidence: prompts, responses, intermediate edits, and work delegated to subagents. Those records often remain inside a specific harness, disappear into chat systems, or get compressed into a brief commit summary.

DeltaDB lets developers trace a passage of code back to its originating conversation and identify the agent or person responsible for it. Its per-character provenance resembles a finer-grained git blame, following text across files and versions instead of stopping at the latest line-level commit.

A causal graph under the hood

DeltaDB stores a collection of conflict-free replicated data types, or CRDTs, in a local SQLite database. CRDTs allow clients to make changes independently and merge them without requiring every participant to remain online. A directed acyclic graph connects those changes, with each node representing a delta, the smallest unit of change the system can express.

The replicated state covers the complete agent thread, including its conversation, files, and related metadata. Three design choices shape how that state is stored and synchronized:

• Compact DAG frontiers. Version vectors retain a counter for every actor that has contributed changes. That metadata keeps growing as short-lived agents, subagents, and sandbox processes appear. A DAG frontier tracks the current heads while remaining compact as participants come and go.
• Copy-on-write B+ trees. Storing a complete CRDT copy for every cached version would consume substantial space. DeltaDB represents state with copy-on-write B+ trees, reusing existing nodes and allocating new ones only along paths touched by replayed deltas.
• Local-first updates. Clients apply changes immediately on the local machine, continue working through network failures, and synchronize when a connection becomes available.

To reconstruct historical state, DeltaDB finds the nearest ancestor with a cached snapshot and replays the intervening deltas. Cached snapshots limit the amount of replay required when browsing a thread’s timeline.

One thread, one sync process

Each thread synchronizes through its own Cloudflare Durable Object. A Durable Object gives a named thread a single transactional process with persistent storage. The object activates when its first client connects, so creating a thread requires no pre-provisioned server process.

A client opens one WebSocket for every thread it follows. During synchronization, the protocol sends a logarithmically spaced sequence of versions, using progressively wider intervals to locate a recent common ancestor efficiently. It then streams the newer deltas, which the server persists and broadcasts to other subscribed clients.

Clients returning after offline work use the same catch-up process. Authentication remains shared, while thread state and synchronization stay isolated. Activity within one thread is confined to its Durable Object, and additional threads distribute work across additional objects.

Four primitives shape the API

DeltaDB exposes four replicated primitives that Rust applications can combine with a derive macro:

#[derive(Clone, Replicate)]
struct Thread {
    #[field(0)] transcript: Buffer,
    #[field(1)] name: Register<String>,
    #[field(2)] worktree: Worktree,
    #[field(3)] comments: Map<u64, Comment>,
}

The example combines conversation text, thread metadata, a Git-backed file tree, and comments into one replicated object. Because commits also become deltas, applications can connect Git history to the agent thread that produced each change.

Launch support and deployment options

DeltaDB targets teams building agent harnesses, coordinating short-lived subagents, or handing work between developers and agents. The Worktree primitive preserves existing Git workflows while adding thread-level provenance and offline synchronization.

• Current integration: The DeltaDB CLI supports Claude Code.
• Planned integrations: Codex and Pi support are next on Zed’s roadmap.
• Hosted deployment: Zed operates a multi-tenant version on Cloudflare.
• Single-tenant deployment: Teams can use their own Cloudflare infrastructure.
• Portability requirements: Other platforms need object storage, PostgreSQL, and addressable single-threaded processes with transactional storage.