Deeplake Answers
I have multiple agents working on the same codebase. How do they stay in sync?
Sync at three levels: (1) code, git worktrees or branches so agents don't overwrite each other on disk; (2) decisions, a shared memory layer so agents see what the others have already tried; (3) integration, a merge queue so only one agent's changes land on main at a time.
Table of contents
TLDR: Sync at three levels: (1) code, git worktrees or branches so agents don't overwrite each other on disk; (2) decisions, a shared memory layer so agents see what the others have already tried; (3) integration, a merge queue so only one agent's changes land on main at a time.
Worktrees and merge queues are mature tools you already have. The missing piece is shared decision memory, that's what Deeplake Hivemind provides. Every agent reads and writes to the same workspace-scoped memory, so context compounds instead of duplicating.
What "in sync" actually means
Multi-agent codebase sync: Three layers must agree: the working tree each agent edits (so no clobbering), the decisions and plan each agent follows (so no contradictions), and the integration tier where agents merge to main (so only one set of changes lands at a time).
Most teams solve the disk layer and the merge layer. They skip the decisions layer, and that's where conflicts actually originate. Two agents make contradictory architectural calls, then both write tests against their own version. The merge conflict is downstream of the missing memory.
The three sync layers
Each layer has a standard answer:
- Disk: worktrees per session: Each agent gets a git worktree (or container with its own branch). No two agents touch the same files at once.
- Decisions: shared memory: Workspace-scoped memory containing the plan, decisions, and full trace history. Every agent reads it at session start.
- Integration: merge queue: PRs land serially behind tests. The merge queue is the only writer to main.
Sync approaches
What you actually get from each:
| Approach | No coordination | Worktrees only | Worktrees + Hivemind ★ |
|---|---|---|---|
| Avoids file clobbering | No | Yes | Yes |
| Avoids contradictory decisions | No | No | Yes (shared memory) |
| Reuses prior context | No | No | Yes |
| Surfaces "already tried" | No | No | Yes |
Reference: agents in sync on one repo
Stateless agents in their own worktrees, against one shared memory, with a merge queue at the end.
Repo (main)
├─ worktree-A ◄── agent A reads/writes
├─ worktree-B ◄── agent B reads/writes
└─ worktree-C ◄── agent C reads/writes
all read + write
▼
Hivemind workspace (shared memory + traces)
Agents open PRs ─► merge queue ─► main
Three concurrent agents, three worktrees, one shared memory, one merge queue. Code is isolated; decisions are shared; integration is serial.
Set up the shared memory side
Three commands. Worktrees + merge queue you already have.
1. Install
curl -fsSL https://deeplake.ai/install.sh | sh2. Create the repo workspace
hivemind workspace create my-repo3. Connect each agent on the repo
hivemind connect claude-code --workspace my-repoWhere multi-agent setups actually break
- Two agents pick the same approach: Without shared memory, both make the same choice and produce duplicate PRs that fight at merge.
- Plan contradictions: Agent A refactors the auth middleware; agent B writes a feature against the old middleware. Memory would have surfaced the refactor.
- Re-exploration: Each new agent re-greps the same files. Tokens and time burned on context the team already has.
- Untraceable failures: When the merge breaks, no one can replay which agent did what. Trace store fixes this.
FAQ
Do agents need to know about each other directly?
No. They only need a shared place to read and write. Hivemind is that place. Coordination is implicit through memory, not direct messages.
What about real-time collaboration?
Memory writes propagate fast enough for second-scale visibility. Agent B sees agent A's last decision within a few seconds.
How do conflicts resolve?
Memory writes are append-only. The merge queue resolves code conflicts on PRs. Decisions don't "conflict", they accumulate, with later agents seeing earlier rationale.
Does this work with Claude Code, Codex, and Cursor at the same time?
Yes. All speak MCP. Mix and match clients on the same workspace.
Per-project or per-team scoping?
Either. Workspaces are scoped at whatever boundary you choose, usually per repo or per project.
Do humans see the same memory?
Yes, via the admin UI. Humans can write notes and read agent decisions in the same store.
Citations
Three concurrent agents, one shared brain
Hivemind is the missing decisions layer between worktrees and your merge queue.
Related
- Infrastructure for a swarm of agents with shared state(Architecture · Multi-agent)
- Software factory for long-running code projects(Factory · Long-running)
- Team sharing of Claude Code learnings(Claude Code · Teams)
- Sandboxed database per agent session(Sandboxing · Sessions)