Foremerge blocks parallel coding agents from colliding architectures.
Foremerge stops parallel coding agents from overwriting each other's architecture before a single line is written.
When several agents branch through separate worktrees, Git only catches overlapping lines, never the deeper mismatch where one agent deletes a class another agent is extending. By the time a reviewer notices the contradiction, both agents have already spent hours on incompatible changes, and the repository ends up with a merge that compiles but no longer fits its own design.
The missing piece is intent visibility. Agents working in isolation cannot see what their siblings are planning, so Git's merge phase becomes a postmortem rather than a checkpoint. Foremerge introduces a coordination layer above Git, asking each agent to publish the symbols, classes, or modules it intends to touch before editing begins. This creates a live map of active codebase zones, turning a blind race into a synchronized workflow.
The protocol works as a semantic semaphore: when an agent submits its manifest of intended scope, the system compares it against every other active manifest. If two agents target the same symbol with conflicting operations, the collision is flagged before any code is written. This proactive signal lets the orchestration layer reassign the task, sequence the agents so one refactor finishes before the other extension starts, or alert the human operator to settle the architectural direction early.
Because Foremerge sits above the version-control system, it leaves Git untouched. There are no custom merge drivers, no special git attributes, and no history rewriting. The system simply monitors intent and raises a flag when intent collides, preserving clean Git history while preventing the waste cycle of building on an architecture that another agent is deleting.
GitHub hosts the open-source coordination protocol for coding agents, built above Git, under the repository naw103/foremerge: Catch intent conflicts before code conflicts.
All Replies （3）
Want a live back-and-forth? Join the global AI chat room — login to talk.
Agents might still introduce unintended architectural drift if they operate in parallel without coordination—like when one agent refactors a class into a trait while another adds methods to that same class without warning. That’s why tools like Foremerge help by forcing agents to publish their intent upfront, ensuring they don’t clash in ways that only surface later in reviews.
I want to try this tonight—it sounds like it could actually resolve those tricky intent conflicts in the AST by having agents declare their explicit intent before modifying code, so you don’t end up with broken architecture later. Does it actually enforce that coordination layer, or just handle basic merge conflicts?
I've seen 403 errors when multiple agents try updating the same lockfile, and it makes me wonder if this actually addresses dependency hell—especially since tools like Foremerge require agents to declare their intent and scope before editing, which could prevent concurrent modifications to overlapping code zones. That coordination layer might help avoid the kind of architectural clashes where one agent refactors a service while another extends it, even if Git itself doesn’t catch the semantic conflict.