dkod

Session Isolation

dkod lets 20+ AI agents work simultaneously on the same codebase, the same branch, even the same file — without merge conflicts, without worktrees, and without cloning the repo multiple times.

The Problem Today

When you use AI coding agents with Git, every agent needs its own copy of the repository:

  • Claude Code needs a worktree or a full clone
  • Devin clones the entire repo into its own environment
  • Cursor works on your local checkout — only one agent at a time

Want 5 agents working in parallel? You need 5 clones. Want 20? You need 20 copies of the entire repository, 20 separate branch contexts, and you'll spend more time resolving merge conflicts between them than the agents spent writing code.

This doesn't scale. A 10GB monorepo cloned 20 times is 200GB of disk and seconds to minutes of clone time per agent. And when two agents edit different functions in the same file, Git gives you a merge conflict — even though the changes are completely independent.

How dkod Solves This

Every agent that connects to dkod gets an isolated session workspace. This is a lightweight, copy-on-write overlay on top of the current codebase state.

Loading diagram...

How It Works

  1. Agent connects — CONNECT creates a session with a copy-on-write overlay over the current codebase snapshot
  2. Agent reads files — reads come from the overlay first, then fall through to the shared base. Zero copy cost for unmodified files.
  3. Agent writes files — writes go into the overlay only. Changes are invisible to every other session and to the main branch.
  4. Agent submits — SUBMIT records the overlay's changes as a changeset. The agent then calls VERIFY to run the verification pipeline (lint, test, type-check). The platform auto-rebases onto the current HEAD if the base moved.
  5. Integrate or conflict — the platform runs a three-way AST merge internally. If changes target different symbols: auto-resolved. If the same symbol was modified compatibly: auto-resolved with deduplication. If the same symbol was modified with incompatible changes: the agent receives a ConflictBlock with resolution options (proceed, keep_yours, keep_theirs, manual). Once integrated, dkod pushes to a feature branch on GitHub and creates a PR. See Conflict Types for details.

Why This Is Different from Git Branches

Git branchesdkod sessions
Setup costClone entire repo (seconds to minutes, GBs)Connect in < 50ms (zero disk)
IsolationFull copy of all filesCopy-on-write — only changed files consume space
Parallel agentsNeed N clones for N agentsN sessions share one codebase, each with a thin overlay
Same-file editsMerge conflict (text-level)Auto-merge if different functions (AST-level)
CoordinationManual — check if branches conflictReal-time WATCH notifications
Land changesgit merge + conflict resolutionSemantic integration in < 50ms, push to feature branch + PR

Concrete Example: 20 Agents, One Repo

Imagine you have a large codebase and you want to:

  • Agent 1–5: Add input validation to 50 API endpoints
  • Agent 6–10: Update database queries to use prepared statements
  • Agent 11–15: Add unit tests for uncovered functions
  • Agent 16–20: Migrate logging from println to structured logger

With Git, you'd need 20 clones, 20 branches, and spend hours resolving merge conflicts when agents touch the same files.

With dkod:

  1. All 20 agents CONNECT simultaneously — each gets a session in < 50ms
  2. Each agent queries only the context it needs via CONTEXT — no cloning
  3. Agents work in parallel on their overlays — completely isolated
  4. When Agent 1 finishes validation for user_handler.rs and Agent 11 finishes tests for user_handler.rs, both submit
  5. The platform detects the changes are structurally independent (different functions) and merges both automatically
  6. Agent 16 modifies logging in user_handler.rs too — the platform auto-merges because the changes don't overlap at the symbol level
  7. If Agent 1 and Agent 6 both modify the same function, the platform detects a true semantic conflict and routes it to resolution

Total time: minutes. Total disk: one copy of the codebase. Merge conflicts: only real ones.

Auto-Rebase

When the main branch moves while an agent is working (because another agent's changes were merged), dkod handles it automatically:

  1. Agent A starts working at version v1847
  2. Agent B merges a change — main moves to v1848
  3. Agent A submits — dkod detects the base moved
  4. If Agent A's changes don't conflict with v1848, dkod auto-rebases and merges
  5. If there's a hard conflict, Agent A receives a ConflictBlock with the conflicting symbols, what each side changed, and available resolution actions (proceed, keep_yours, keep_theirs, manual). The agent pauses and either adapts automatically or directs the user to the dashboard.

No manual git rebase. No merge conflict resolution. No "please pull before pushing."

Copy-on-Write Efficiency

Session overlays use copy-on-write semantics:

  • Unmodified files — zero storage cost, read directly from the shared base
  • Modified files — only the changed files are stored in the overlay
  • Ephemeral sessions — overlay is cleaned up automatically when the agent disconnects
  • Persistent sessions — overlay survives disconnection for agents that need to pause and resume

A typical agent session that modifies 10 files in a 100,000-file codebase uses only the storage for those 10 files — not a full copy.

Real-Time Coordination via WATCH

Agents don't work in total isolation — they stay aware of relevant changes through the WATCH operation:

Agent A watches: ["UserSession", "auth/*"]

Agent B merges a change to UserSession → Agent A receives:
  event: "modified"
  symbol: "UserSession"
  modified_by: "agent-b"
  impact: "Field list changed. Your changeset references this type."

This lets agents adapt in real time rather than discovering conflicts at merge time.

Next Steps