Posted by naw103 1 day ago
Foremerge is a local "git like" coordination layer that sits above git (ie. does not interact with or change the way git and worktrees function), Before editing each agent publishes an intent and the scopes it will change, with the operation it plans to complete on each one.
foremerge intent publish --agent "$A" \
--summary "Replace PaymentService with StripePaymentService" \
--scope symbol:PaymentService=replace
foremerge intent publish --agent "$B" \
--summary "Add PayPal support to PaymentService" \
--scope symbol:PaymentService=extend
It ships as one Rust binary with a CLI and MCP server with 18 tools and `foremerge setup all` wires it into Claude Code, Codex and Cursor. Because the protocol has nothing provider specific, a Claude agent and a Codex agent coordinate through the same store. Before any work is accepted, Foremerge runs a named check that you configured against the exact git state of the change. An agent that says tests pass is recorded but it dosnt satisfy the acceptance gate without running the check itself.
Detection is deterministic, no judge model reading your code. HIGH conflicts are only asserted for declared operations, ie. matches inferred from prose cap out below high. Claims are advisory leases, not locks so two agents can still hold the same scope without deadlock. The open source version is single matching and so not a distributed consensus.
We have tested this up to 98 parallel agents all working on the same repo with zero conflicts (was supposed to be 100 but 2 agents failed to run due to resource limitations)
I replayed 76 intents on my own agents from a build last week in the order they happened. The sample had exactly 1 conflict (which was flagged) and the review found a blind spot where one agent claimed scope by class name and the other claimed it by an internal method. We are working on fixing that for the next release.
Setup is a 30s install by pasting the quickstart instructions from the readme.md into your agent or manually: `curl -fsSL https://foremerge.com/install.sh | sh` or `cargo install --locked foremerge`, then `foremerge init && foremerge setup all` in a repo. Apache-2.0.
The feedback I want most is which conflicts between your agents plans would you actually want flagged and which would you tollerate as noise?
Repo here: https://github.com/naw103/foremerge Website: https://foremerge.com
More information on the problems this solves: https://foremerge.com/blog/
What does an agent do with it? The agents publish intents and scopes of what they are about to change (at the start and right before they make the change if its something different). Foremerge returns a signal of related work already in progress on different worktrees (even across different branches or in the same worktree) and the agents/humans who are working on it. Agents can then negotiate on the solution prior to writing any code or generating any conflicts and Foremerge runs an acceptance check (defined by a human) prior to commit.
Why advisory claims instead of locks? Once a repo gets busy locks turn into a queue and deadlocks. A lock that the agent cant see the reason for is the worse case scenario so the hard gate is at the acceptance not the start.
What are the gaps? Ultimately Foremerge is deterministic (does not use any judge model) so it can detect some false positives and negatives though we see that very infrequently and worst case it would have likely of been missed anyway without Foremerge. Acceptance also dosnt currently compare the actual diff by default and there are no push notificiations so the earlier agent only learns about the conflict on its next status check (both of these are on the roadmap for the next version)
There are more questions and answers here: https://foremerge.com/blog/31-questions-coordinating-paralle...
It was already a problem for me before agentic AI coding : multiple developers can work on overlapping code and you always need someone to merge everything properly. Even if the overlap is very small it does add a burden to development. Not an issue anymore in 95% of cases if that person uses AI to solve conflicts, but now that "others developers" are swarm of AI agents, this problem isn't trivial to solve.
We find giving the agents independent remits makes them significantly better at challenging problematic requirements, because they aren’t all automatically aligned on the same goals.
The agents from each area then having queues and messaging subsystems to coordinate their work when there are multiple streams happening, although concurrency is less of an issue than we expected. Generally will detect and flag competing requirements, which has saved us from some subtle issues. We don’t always require code owners to review every PR in their area, but they do at least always have a log of what work was done and why, which is separate from the noise of the parent work.
This does all work out a bit slower than just letting each agent get on with its job, but it’s working pretty well for us.
Before editing each agent publishes an intent and the scopes it will change, with the operation it plans to complete on each one.
... and Jev is a sore point for me right now lol we have been training our own decision intelligence model, Corgen, for the last year and a half. We're already using it in GPTree but havn't released it to the public yet. Im actually in the process of running it against JevBench right now to see how it stacks up.