How to Coordinate Multiple AI Coding Agents Without Constant Merge Conflicts

A solo developer running one AI agent against a backlog.md file in their repo has a real, working setup. The agent reads the file, picks a task, does the work, updates the file. Nothing here breaks until you add a second agent, or a second person.

The moment there's more than one agent (or more than one developer plus an agent) working off the same task list, that file stops being a convenience and starts being the thing everyone is fighting over.

What happens when you actually run this at scale

This isn't theoretical. Anthropic ran exactly this experiment: 16 parallel Claude agents building a Rust-based C compiler from scratch, coordinating through a shared Git repository over roughly 2,000 Claude Code sessions and $20,000 in API costs.

Their coordination method was almost exactly the backlog.md pattern: each agent claimed a task by writing a lock file, worked on it, then merged its changes back. That worked, until the team hit a shared problem everyone converged on at once. As Anthropic describes it, when the agents all needed to get the Linux kernel compiling: "every agent would hit the same bug, fix that bug, and then overwrite each other's changes. Having 16 agents running didn't help because each was stuck solving the same task."

Their fix wasn't a bigger file or a smarter prompt. It was custom infrastructure: they built a "known-good compiler oracle" (using GCC as a reference), so most files got verified against a trusted baseline and only a rotating subset went to their own compiler, turning one shared bottleneck into many independent, parallelizable ones.

This isn't a one-off. A recent academic study of AI-agent pull requests on GitHub, the AgenticFlict dataset, found that across 142,652 AI-generated PRs from 59,412 repositories, merge conflicts showed up in 27.67% of them, with the rate varying by tool from 15.24% to 31.85%. Coordination failure between AI agents is a measured, common outcome, not an edge case.

Why this hits organizations differently than solo developers

A solo developer hitting a lock-file conflict just resolves it and moves on. It costs them a few minutes. For a team, or an agency running agents across multiple client projects, the same file-based pattern breaks in ways that have nothing to do with the conflict itself:

• Nobody outside the repo can see it. A product manager, a client lead, or a QA engineer has no way to check status on a task that lives in a markdown file on someone's feature branch. The board a stakeholder actually looks at and the file an agent actually reads are two different sources of truth.
• There's no access boundary. A shared task file gives every agent that can read the repo the same level of access as every other agent. There's no way to say "this agent can touch project A but not project B" without building that logic yourself.
• Handoffs lose everything that isn't in the file. When a new hire or a subcontractor picks up work, they get whatever's written down, not the reasoning behind it or the state of parallel work another agent already did.

That access gap isn't hypothetical either. IBM's Institute for Business Value found that 82% of organizations discovered at least one AI agent or workflow their security team didn't already know about, and only 13% believe their governance is actually adequate. A file sitting in a repo that any locally-run agent can read and write, under whatever broad credential it happened to inherit, is exactly the kind of ungoverned surface a real incident already showed the cost of.

There's a second cost that shows up slower: what O'Reilly calls "comprehension debt", the growing gap between how much code exists in a system and how much of it any human actually understands. Multiple agents producing code in parallel against a shared file accelerates that gap faster than one agent ever could, because no single person (and no single agent) is tracking the whole picture.

What teams that get this right are actually doing

Engineer Addy Osmani, writing about what separates working multi-agent setups from ones that collapse, lays out the pattern that holds up: decompose work into testable tasks with explicit boundaries, isolate each agent in its own Git worktree, split roles into coordinator, specialist, and verifier, and require automated quality gates before anything merges.

Notice what that list actually requires: task boundaries enforced by something other than a text file, isolation enforced by infrastructure rather than agent discipline, and verification that happens automatically rather than by someone remembering to run it. A markdown file can describe this system. It can't enforce any of it, and automated quality gates only close part of the gap on their own: a gate that only checks "did CI pass" inherits the same blind spot CI always had.

Most organizations haven't built that infrastructure yet. McKinsey's research found only 23% of organizations are actively scaling an agentic AI system in even one business function, with 39% still experimenting, and in any single function, no more than 10% report real scaled use. Gartner's read on where this is headed is blunter: it projects over 40% of agentic AI projects will be canceled by the end of 2027, largely because the operational and governance layer never caught up with how fast the agents themselves improved.

What git worktrees actually solve, and what breaks next

Osmani's pattern above names "isolate each agent in its own Git worktree" as one piece of a working setup, and it's worth being precise about what that isolation actually covers, because a widely-discussed Hacker News thread from mid-2026, built around Fletch's writeup comparing worktrees and clones for AI agents, makes the boundary explicit: a worktree gives each agent its own working directory and its own checked-out files, but every worktree attached to a repo shares one .git directory: hooks, config, and credentials included. One commenter on that thread put the blast radius plainly: "everything other than git credentials... now lives inside the blast radius." An agent with write access to its own worktree can still write into the shared .git/hooks directory and affect every other worktree pulling from the same repo, because that directory was never partitioned per worktree to begin with.

That's not a reason to skip worktrees, a first-person account on DEV.to covers real gains from running several agents this way. It's a reason to be precise about what kind of isolation you're actually getting: file-level isolation between agents' working copies, not an execution boundary around what an agent with shell access inside that worktree can still reach.

A concurrency framework for the files worktrees don't isolate

Worktrees solve the problem of two agents editing the same file in the same working directory at the same time. They don't solve what happens when two agents, in two different worktrees, both need to touch a shared "hotspot" file: a central route registry, package.json, a shared config or schema file that most features eventually touch. Each agent's local diff looks clean. The two diffs can still conflict, or worse, both merge cleanly and produce code that compiles but disagrees with itself at runtime, because neither agent's worktree ever saw the other's in-flight change.

A practical framework for how many agents to run in parallel against one codebase comes down to how many of those hotspot files exist and how often a given task actually needs to touch one: a codebase decomposed into genuinely independent modules with few shared entry points supports more concurrent agents safely than one where most features route through the same three files. Where a hotspot file can't be avoided, treating it as single-writer, one agent's change lands, gets reviewed, and merges before the next agent's touch on that same file starts, costs less than debugging a runtime disagreement two clean-looking diffs produced together.

What this looks like with a real task graph instead of a file

TAM replaces the lock-file-and-hope pattern with the same primitives Osmani describes, built into the platform instead of hand-rolled per project. Tasks live in a real graph with dependencies, not a flat markdown list, so two agents can't claim the same work by accident. Each connected agent gets its own scoped MCP token instead of blanket repo access, enforced server-side, so "this agent can touch project A but not project B" doesn't depend on the agent choosing to respect it. PR activity links to the matching ticket automatically, live today, the same context Anthropic's GCC oracle had to be hand-built to provide, and a task reaching Done is built to run on that same evidence, with full enforcement rolling out on top of it, the same role Anthropic's oracle played by hand, just running by default instead of something a team has to build from scratch.

If your team is already running more than one agent against the same codebase, or is about to, see how TAM's MCP setup handles task claiming and scoped access before you end up writing your own lock-file logic to work around it.