Your team just adopted Claude Code, Cursor, and Copilot. Three AI agents, one monorepo. And now your pull requests look like a war zone.
Two agents edited the same config file. One rewrote a function the other was refactoring. A third added tests for code that no longer exists. The merge conflicts are brutal, and nobody knows which agent did what.
This is the coordination problem, and it gets worse as you add more agents.
Why git alone does not solve this
Git catches conflicts after they happen. By the time you see a merge conflict, both agents have already done the work. One of them wasted time, tokens, and compute.
What you need is prevention, not detection:
- Before an agent edits a file, it should claim that file
- Other agents should see the claim and work elsewhere
- When the work is done, the claim is released
- If an agent crashes, the claim expires automatically
This is file-level locking, and it is the missing primitive for multi-agent codebases.
How file-level locking works
The concept is simple:
Agent A: "I need to edit src/config.ts"
Lock server: "Granted. Lock expires in 30 minutes."
Agent B: "I need to edit src/config.ts"
Lock server: "Denied. Agent A holds the lock until 14:30."
Agent B: "OK, I will work on src/utils.ts instead."
The lock server maintains a registry of which agent owns which files. Locks have TTLs so crashed agents do not block everyone forever.
What else you need beyond locks
File locking solves conflicts, but coordination needs more:
Sprint management
Organize agent work into reviewable batches. Instead of 3 agents making 30 random changes, assign them to sprints with clear goals: "Agent A: refactor auth module. Agent B: add tests for payments. Agent C: update API docs."
Agent-to-agent messaging
Agents need to communicate. "I am about to change the database schema -- hold off on migration scripts." Without messaging, agents work in isolation and create incompatible changes.
Session and cost tracking
Each agent session should track:
- Which files were touched
- How many tokens were consumed
- How long the session ran
- What the outcome was (PR created, tests passed, etc.)
Without this, you have no idea which agent is productive and which is burning money.
A practical setup
Here is what a multi-agent workflow looks like with coordination:
1. Engineering lead creates a sprint:
"Fix authentication bugs -- deadline Friday"
2. Claude Code claims: src/auth/*.ts
Cursor claims: src/middleware/auth.ts
Copilot claims: tests/auth/*.test.ts
3. Each agent works in its locked scope
Messages flow: "Auth module API changed -- update your tests"
4. Sprint completes:
3 PRs, no conflicts, $4.20 in total LLM costs
Engineering lead reviews one coherent changeset
Compare that to the alternative: 3 agents, no coordination, 12 merge conflicts, 6 hours of manual resolution, and a $15 LLM bill for work that was partially thrown away.
The cost of not coordinating
Teams underestimate the cost of agent conflicts:
- Wasted compute: An agent spends 10 minutes and 50K tokens on changes that get thrown away in a merge conflict
- Developer time: Someone has to resolve the conflicts manually
- Delayed delivery: The sprint that should have taken 2 hours takes a day
- Lost context: After a conflict, the "losing" agent does not know its work was discarded
At scale (5+ agents, 10+ developers), this becomes the dominant cost of AI-assisted development.
Getting started
If your team runs multiple AI coding agents:
- Audit your conflict rate -- how many merge conflicts per week are agent-caused?
- Separate agent scopes -- even without tooling, assign different directories to different agents
- Track agent costs -- know which agent is productive vs. wasteful
- Consider a coordination layer -- tools like AgentSync provide file locking, sprints, messaging, and cost tracking purpose-built for this problem
The teams that figure out multi-agent coordination early will ship faster than teams that let their agents fight.
-- Authora team
This post was created with AI assistance.
Top comments (0)