Who Changed What: Source Control for Multi-Agent Repos
Three agents walk into a repo. Claude Code opens a PR refactoring the auth module. Codex CLI, running in the next terminal, rewrites the same router file to add a new endpoint. Cursor, in another window, deletes the test file that both of them depend on. All three commit. Two of three merge cleanly. The build breaks at 2 AM and nobody — human or machine — can explain which agent did what, or why.
📖 Read the full version with charts and embedded sources on AgentConn →
This isn't a hypothetical. The AgenticFlict dataset, published at ACM AIware '26, analyzed 142,000+ agent-authored pull requests across 59,000+ repositories and found a 27.67% merge conflict rate — with 336,000+ fine-grained conflict regions. Cross-agent pairs (Claude Code touching the same repo as Codex) conflict at 41.7%, more than double the 19.8% rate when the same agent runs parallel tasks. The multi-agent repo isn't an edge case anymore. It's the default configuration for any team running more than one coding tool, and git was never designed for it.
That's why Atlas — a desktop app that bills itself as "source control for agents" — hit 8,100 stars on GitHub this week, gaining 490 new stars per day. It's not alone. Oak launched a git alternative built from scratch for agents, hitting the Hacker News front page with 216 points and 189 comments. Diversion is pitching a scalable VCS designed for thousands of concurrent agent branches. Three independent bets, all shipping in 2026, all answering the same question: what happens to version control when most commits come from machines?
The Problem: Git Assumed One Driver Per Seat
Git's mental model is a human developer switching branches, staging changes, writing commit messages, and resolving conflicts by reading diffs. Every one of those assumptions breaks when agents are the committers.
No awareness of parallel work. Each agent starts from a frozen snapshot and has no visibility into what other agents are building. Two agents can spend 20 minutes writing overlapping changes to the same file, and neither knows until merge time. The Daniel Vaughan analysis of 33,596 agent-authored PRs breaks down where it hurts most: 57.6% content conflicts (overlapping line edits), 26.8% modify/delete conflicts (one agent refactored what another deleted), and 15.1% add/add conflicts (both agents independently created the same file).
Read the full AgenticFlict analysis →
No provenance trail. Git records who committed and what changed, but not why or how the decision was made. When a human commits, the reasoning lives in their head and in the PR description. When an agent commits, the reasoning lived in a prompt and a chain of tool calls that vanished when the session ended. Six months later, someone reads refactor: simplify auth flow and has no way to know whether that was a human's architectural judgment or an agent hallucinating a simpler approach — the problem we've covered as comprehension debt.
No coordination primitive. Git gives you branches for isolation and merges for integration. It doesn't give you a way to tell Agent B "don't touch src/routes/ because Agent A is rewriting it right now." The coordination has to happen above git — in the orchestrator, in the task decomposition, in the file-boundary scoping. As Autonoma's analysis found, the 42% structural conflict rate drops to near-zero when agents simply can't touch the same files. The fix isn't in the VCS. It's in the instructions.
⚠️ Contrarian corner: The VCS layer might be a distraction. The 41.7% cross-agent conflict rate doesn't mean git is broken — it means prompts are broken. If you scope each agent's task to non-overlapping files (via AGENTS.md manifests, directory-level ownership, or an orchestrator that assigns file locks), merge conflicts functionally disappear. The real investment should be in task decomposition, not version control migration.
Hugging Face CEO Clement Delangue captured the underlying tension in a post that resonated across the developer community:
That's a fair argument — and it's the argument you'll hear from teams that run multi-agent setups today using nothing more than git worktrees and discipline. But it breaks down at scale. When you have 5 agents running overnight maintenance — vulnerability remediation, dependency updates, test generation, documentation — scoping non-overlapping files becomes its own coordination problem. Someone has to know the full dependency graph to avoid semantic conflicts that merge cleanly but break behavior. That "someone" is increasingly a tool, not a person.
The Landscape: Extend Git or Replace It
The market is splitting into two camps, and understanding which one you're buying into matters more than which specific tool you pick.
Camp 1: Extend Git — Atlas and the Checkpoint Model
Atlas from pacifio is a Tauri desktop app built in Rust and TypeScript that treats git as the storage layer but adds an agent-native control plane on top. The core primitive is the checkpoint: every agent run produces a commit that's linked back to the session that created it, including the original prompt, every tool call, and the agent's reasoning chain. All of it stored locally in .atlas/sessions.db, with secrets scrubbed before anything touches disk.
This solves the provenance problem directly. When you're debugging a breaking change six weeks later, you don't just see refactor: simplify auth flow — you see the prompt that triggered it, the files the agent read before making its decision, and the intermediate states it considered. Session links survive rebases and amends through patch-id reconciliation.
But Atlas does more than checkpointing. It runs Claude Code, Codex, and any agent in the ACP registry (Cursor, OpenCode, Kilo Code, and more) side-by-side in tabs, with a shared semantic memory index that all agents can query. This means Agent B can ask "what did Agent A change in the auth module?" before touching the same files. The @ mention system lets agents reference files, folders, symbols, branches, commits, notes, and past sessions — a context layer that git never provided.
The technical architecture: Vue/React frontend on CodeMirror, Rust backend via Tauri, SQLite for session storage, Bun as the package manager. Apache-2.0 licensed. The 8,100 stars and 490/day growth rate put it in the top tier of developer tools trending on GitHub — and our GitHub digest confirms it's part of a broader pattern where 5 of the top 8 trending repos are agent-adjacent infrastructure.
The Augment Code guide to multi-agent workspaces recommends a similar architecture: Conductor enables 3–8 parallel agents on the same repo, each in its own git worktree, with a visual dashboard for monitoring. VS Code positioned itself as "your home for multi-agent development" where Claude and Codex agents run alongside GitHub Copilot. The pattern is converging: git as the base layer, worktrees for isolation, a coordination app for visibility.
Camp 2: Replace Git — Oak and Diversion
Oak takes the radical position that git itself is the bottleneck. Built in Rust around BLAKE3 hashing and content-defined chunking, Oak redesigns version control around one insight: the unit of work for an agent is a session, not a commit.
The performance numbers back the thesis. Oak's published benchmarks show snapshots in many-small-files repos dropping from 29,723ms on git to 1,412ms on Oak (95% faster). Task snapshots of large binaries go from 443ms to 23.2ms (also 95%). Full diffs over multi-GB binaries from 3,945ms to 271ms (93%). These aren't synthetic benchmarks — they're the exact operations agents hit dozens of times per task when checkpointing, branching, and diffing.
Oak's design addresses three git pain points for agents specifically:
-
No lock contention. Git's shared
.git/index.lockcorrupts when two parallel agents touch the same repo. Oak eliminates the shared lock. - Lazy mounting. Cloning a repo in Oak streams the manifest first, then fetches file contents on first read — agents start editing within a second instead of waiting for a full clone.
- Machine-readable output. Git's status output is designed for human eyes. Oak's API returns structured data that agents can parse without regex hacks.
The broader "git for agents" thesis has generated sustained Hacker News debate — a separate Show HN thread on the same topic drew additional community engagement:
The Hacker News reception was mixed but substantive. The top criticism: agents already know git from training data, so introducing a new VCS means agents have to learn unfamiliar tooling. The creator's response: Oak isn't about syntax familiarity but optimizing runtime workflows — parallel sandboxing, large repos, non-interactive execution, and token efficiency. Oak is at v0.99.0 public beta, Apache-2.0, with no Windows build yet and an export command that replays branches into standard git history for compatibility.
Diversion takes a different approach: a centralized VCS (not distributed like git) designed for massive repositories and thousands of concurrent branches. Already recommended by Epic for Unreal Engine workflows, Diversion's pitch is partial clones (only the paths you need from a 50M-file repo), native large-file support without LFS, and prompt provenance metadata baked into the commit model.
Read the Diversion blog post →
ℹ️ The numbers that matter: AgenticFlict found content conflicts at 57.6%, modify/delete at 26.8%, and add/add at 15.1%. The cross-agent conflict rate (41.7%) is more than double the intra-agent rate (19.8%). This means mixing agent vendors on the same repo is measurably riskier than running one agent type — a finding that should inform your multi-agent strategy.
The Git Worktree Baseline: What Works Today
Before evaluating new tools, there's a zero-cost baseline that every multi-agent team should already be running: git worktrees.
Claude Code shipped worktree support in v2.1.49 (February 2026). Run claude --worktree <name> and you get an isolated session on its own branch under .claude/worktrees/, so you can build a feature in one terminal while fixing a bug in another. The VS Code blog describes VS Code as "your home for multi-agent development" where Claude and Codex agents run alongside GitHub Copilot — each in its own worktree.
The Developers Digest playbook puts it simply: worktrees convert silent runtime file corruption into visible merge-time conflicts. That's not a perfect solution — you still get conflicts — but at least you know about them, and you know which agent's branch caused them.
The practical workflow:
- One worktree per agent session, one branch per task
- Each agent gets a file-boundary scope via its instruction file (CLAUDE.md, AGENTS.md, or project-level rules)
- Merge sequentially, not concurrently — the agent that finishes first merges first
- Run
git merge-treein pre-merge hooks for early conflict detection - Review agent PRs with the same rigor as human PRs — the 10x PRs, 1x reviewers bottleneck is real
This is the setup that most production teams are running today, and it works. The question Atlas, Oak, and Diversion are answering is: what's missing from this baseline?
What's Missing: The Provenance Gap
The answer is provenance — knowing not just what changed, but why, how, and by which agent's reasoning process.
Git blame shows you which commit touched a line. It doesn't show you the prompt that triggered the change, the files the agent read before deciding to make the change, the alternative approaches the agent considered and rejected, or whether the change was the agent's own initiative or a response to a human instruction.
Atlas's checkpoint model addresses this directly. Oak's session-as-unit-of-work design encodes it into the VCS primitive itself. And the Entire.io analysis predicts that provenance metadata will become standard: future version control needs to capture prompt provenance, decisions, reasoning traces, implementation context, and metadata.
This isn't academic. When your fleet of agents is producing the majority of commits — Stripe already merges 1,000+ agent-authored PRs per week — you need a way to audit the reasoning behind those commits at scale. The Hacker News community keeps returning to this problem:
The teams building Atlas and Oak are betting that git's commit message field isn't enough.
What This Means for You
💡 The three-move playbook:
1. Today: Adopt git worktrees as baseline isolation for every agent session. This is free and immediate.
2. This quarter: Evaluate Atlas if you need checkpoint provenance and session tracking across multiple agent types. At 8.1k stars and growing 490/day, the community is large enough that you won't be alone.
3. Watch, don't migrate: Oak and Diversion are solving real problems but lack ecosystem maturity. Monitor their adoption curves — when your CI provider and code review tool support them natively, that's the migration signal.
The version control layer is becoming agent infrastructure. Git will remain the foundation for most teams through 2027, but the coordination layer on top of it — checkpoints, shared memory, session tracking, conflict prediction — is where the real competition is happening. Atlas's 8,100 stars aren't about a better git GUI. They're a demand signal that operators are tired of debugging agent commits with git blame and a prayer.
The question for every team running multiple coding agents: can you tell, right now, which agent changed what, and why? If you can't, the next merge conflict at 2 AM is going to hurt worse than the last one.
Originally published at AgentConn
Top comments (1)
Max, "three agents walk into a repo" is the precondition assertion wearing a
source-control coat, and reading it through my own lens makes your whole
thesis click into place. In my golden set a negative test that passes because
the retriever never surfaced the trap is a green result whose precondition was
never asserted — the test ran, the verdict came back, and the path that was
supposed to be exercised was never touched. Your 2 AM build break is the same
shape one layer up: three agents committed, two merged cleanly, the build
broke, and the precondition that should have asserted no overlapping work was
never exercised. That is not a merge conflict; it is a green lie that looks
like a functioning repository.
What strikes me is how cleanly your three problems map onto my own failure
modes. "No awareness of parallel work" is the precondition that was never
asserted — each agent starts from a frozen snapshot and has no visibility into
what other agents are building, so overlapping work proceeds without the
assertion that the file is free. "No provenance trail" is the vendor tag that
was never attached — git records who committed and what changed, but not why
or how the decision was made, so six months later a commit message that says
"refactor: simplify auth flow" carries no context about whether that was a
human's architectural judgment or an agent hallucinating a simpler approach.
"No coordination primitive" is the gate that was never built — git gives you
branches for isolation and merges for integration, but no way to assert the
precondition before the commit happens. Your three problems are my three
verdicts in source-control form: test did not run, pass with no route tag,
and the gate that never existed.
The bridge I could not resist building from my side is this: every verdict in
my eval carries the embedder tag that earned it, because a swap makes
old-tagged results describe a retrieval that no longer exists. Your provenance
trail is the same mechanism in the source-control layer — every commit should
carry a stamp that asserts what had to be true for it to be safe: what task
prompted it, what reasoning chain led to it, what other agents were working
on the same files. A commit without that stamp is a pass with no route tag:
you can see the diff, you cannot see which branch of reasoning earned it, and
the branch may have been a default the orchestrator never chose. Your
observation that "the reasoning lived in a prompt and a chain of tool calls
that vanished when the session ended" is exactly the green lie I write about —
the context that makes the assertion meaningful must travel with the result,
instead of being assumed.
And here is the part I underlined twice: your "cross-agent pairs conflict at
41.7%, more than double the 19.8% rate when the same agent runs parallel
tasks" is exactly the honest tranche next to the marketing aggregate. The
headline says "multi-agent repo," the tranche says "cross-agent conflict rate
is double same-agent," and the two tell different stories. Your 27.67%
overall conflict rate is the aggregate; the 41.7% cross-agent rate is the
tranche that actually matters for teams running Claude Code and Codex in the
same repo. That is the same work my CI summary does when it shows the
unverified section prominently instead of letting the green count carry the
story — the aggregate hides the failure mode that actually breaks the build.
So the question I genuinely want your read on, continuing your own metric
rather than proposing a new one: you built cost per task as the number that
asserts the precondition of the bill — tokens burned, not price promised. Is
there an equivalent for the source-control layer? Not "merge conflict rate" or
"number of agents" but something like the share of commits that actually
asserted the parallel-work precondition — no overlapping files, provenance
trail attached, coordination primitive checked — before counting the repo as
safe. Because if the 2 AM build break is what just blinked, then the metric
that catches the blink first is the one that asserts the source-control
precondition before counting the commit. Without that stamp, "our repo is
multi-agent ready" is a green lie wearing a git-worktree sticker.
I suspect you are closer to that metric than the post lets on, the same way
you were closer to the router-as-harness idea than the September 3 piece
admitted. The pattern with you is that you build the mechanic first and name
it two posts later, so I am watching for the naming.