Running two or more coding agents against the same codebase can work well when their tasks are clearly separated.
It gets harder when agents run for longer periods, humans are mostly out of the loop, and multiple agents frequently read or edit the same large modules.
At that point, the problem is not only Git merge conflicts. It is also that each agent may be reasoning about a different version of the same file while they are still working. And about spending time and tokens to resolve merge conflicts.
I built agent sync layer (ASL) to experiment with this.
ASL lets coding agents work independently while synchronizing file changes through CRDTs. Compatible edits can converge, while stale or ambiguous overlapping edits are rejected instead of silently overwriting newer changes.
It supports Claude Code and Codex directly, and can isolate agents in separate worktrees while keeping their file state synchronized.
Example:
asl claude --name agent-a
asl codex --name agent-b
It launches like normal CC or codex, visually nothing is changed.
I think the most relevant use cases are:
- 2+ agents working concurrently
- long-running or human-out-of-loop agentic workflows
- large shared source files
- agents frequently reading and editing the same modules
- orchestrators launching multiple agents against one codebase
This does not solve semantic conflicts. Two changes can synchronize perfectly and still produce broken code. Tests, type checking, and review are still necessary.
I tested ASL on my own setup and it worked for the workflows I was experimenting with. I'm not sure yet whether this is something developers actually need in real-world workflows, or whether task separation and normal Git workflows are already enough for most cases.
I published it anyway in case someone working with concurrent coding agents wants to experiment with it, and also as a project for my portfolio.
GitHub:
Top comments (6)
"Each agent may be reasoning about a different version of the same file" is the real problem here, more than the merge conflicts. Rejecting stale overlapping edits instead of silently converging them is the right default.
What does the rejected agent see? In my experience, if it gets the current file plus a short "your edit to lines X to Y was rejected because agent-b changed them", it redoes the edit correctly in one step. If it only sees a generic failure, it tends to retry the same stale edit until something else stops it.
That’s close to how it behaves today.
The rejected agent gets a normal tool failure EAGAIN naming the affected file and saying the expected text no longer matches, with an explicit instruction to re-read before retrying.
For the Codex/Claude hooks, ASL also restores that file on disk to the latest shared CRDT state before returning the failure, so the next read starts from the current state rather than the rejected local edit.
It doesn’t currently include the exact conflicting lines or the identity of the other agent in the error itself, so there’s still an extra read step. Your suggestion about giving more precise conflict context is a good though, could reduce retries further in longer runs.
Restoring the file to the latest shared state before returning the failure is the part most setups skip, so the extra read is a small price. If you add conflict context later, even just the line range plus which agent changed it would let the agent re-read only that part on large files. Do retries still collide often in longer runs?
I don’t have enough long-run data yet to claim a reliable collision rate. In controlled two-agent runs, disjoint edits merge without retries, and same-span edits reject as intended. A retry should collide again only if another agent changes the same anchor during the re-read→write window, so hot files or both agents working on the same function can still thrash. So the honest answer is: repeated collisions are possible, but I can’t yet say they’re rare in sustained workloads.
And yes, localized context would help. Line ranges are feasible; reliable agent attribution needs some added change-provenance tracking, since presence alone doesn’t prove who changed a particular span.
Hard agree, and I'd push it further: the moment two agents share a working directory, it stops working entirely — they stomp each other's files mid-edit and one agent's half-done refactor becomes another's broken import.
The thing that made parallel agents actually shippable for me was one git worktree + one branch per agent, so they never see each other's uncommitted state until I merge. At that point I become the bottleneck (the review queue), not the agents.
Did you find a coordination approach that scales past 2-3, or does the merge/review cost cap it the way it did for me?
Exactly, that review bottleneck is what ASL is trying to shrink. It keeps one worktree per agent, but synchronizes accepted edits continuously, so mechanical conflicts are handled during the work instead of piling up at merge time. Early three-agent tests are promising; next I’m validating how far that holds as agent count and contention increase.