Foremerge – Catch intent conflicts between parallel coding agents

At, GPTree, we run several coding agents across our team on one repo using parallel worktrees. Apart from wasted time reviewing and fixing conflicts at PR time, the failures that hurt the most are when multiple plans or tickets cause architecture changes that cannot both be true. Ex. one agent replaces a class while another one is in the process of extending it. Git only notices if the resulting patches happen to touch the same lines and the review only catches it if they are familiar with both tickets.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 The publish by the 2nd agent returns a HIGH destructive_vs_additive finding before writing any code. Agents keep their own worktrees and the shared state is one SQLite file in gits common direectory. No hooks, no merge drivers, nothing rewrites your history.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 decl

Hacker NewsToolAISource
0Sign in to voteCopy link

FL score

72

out of 100

Verdict

VALIDATE

high confidence

Competition

No competitor data yet

Trend

No signal yet

A coordination layer that detects architectural conflicts between parallel coding agents before they waste time in code review.

The pain

Teams running multiple AI coding agents on the same repo waste hours resolving conflicts that git cannot catch. One agent replaces a class while another extends it. Git only flags line-level conflicts. Code review catches semantic conflicts only if reviewers understand both tickets. This happens repeatedly as teams scale agent usage.

The gap

Git has no concept of intent or scope. Code review is manual and unreliable for cross-ticket architectural conflicts. No tool sits between agent planning and execution to validate compatibility. Existing solutions either require changing git workflows or rely on post-hoc detection.

Build angle

Start with teams already running GPTree or similar multi-agent setups on single repos. Ship the SQLite store and CLI first. Integrate with Claude Code and Cursor via MCP. Validate that deterministic symbol-level conflict detection catches real architectural issues. Expand scope detection rules based on actual conflict patterns observed in early users.

Strengths

  • Solves a concrete, measurable problem that grows as teams deploy more agents.
  • Non-invasive design respects existing git workflows and does not require history rewrites.
  • Deterministic detection avoids false positives from LLM-based judgment.
  • Rust binary with MCP server is portable and works across multiple agent platforms.
  • SQLite store is simple to operate and audit compared to external services.

Risks

  • Market is small and early. Most teams are not yet running multiple agents on one repo at scale.
  • Requires adoption by multiple AI platforms (Claude, Codex, Cursor) to be useful. Coordination across vendors is slow.
  • Scope detection rules may be too simplistic for complex refactors. False negatives could undermine trust.
  • Teams may prefer to solve this through process (code review discipline, ticket planning) rather than tooling.
  • If git or agent platforms add native conflict detection, the product becomes obsolete quickly.
  • Narrow TAM limits venture scale. Likely a lifestyle business or acquihire target rather than a breakout company.

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “Foremerge – Catch intent conflicts between parallel coding agents”.

Open FlyBot