Last week I open-sourced Foremerge, a coordination protocol for coding agents that sits above Git. Agents publish intent and claim semantic scopes with declared operations before writing code, so two plans that cannot both be true collide in a queryable store instead of in your merge.
A few days in, a reader named Vedant Madane went through the repo and left thirty-one questions across a GitHub discussion. They were the best kind of questions: the kind you can only ask after actually reading the source. I answered every one in the thread, but most people will never click into a GitHub discussion, so here is the full Q&A, lightly edited, plus three questions I missed in the thread and answer here for the first time.
If you want the short version of what the tool does first: one Rust binary, local-first, Apache-2.0, exposing a CLI, a local JSON API, and an MCP server over one SQLite store in your repo's git common dir. The README has a real terminal recording.
Origin and users
What real failure made you build this? A specific multi-agent wreck, or a bet that fleets would need a whiteboard above Git?
Initially it was just the growing pain of resolving collisions from multiple agents working in parallel worktrees and duplicating code. We had "find a better solution" on our roadmap with no success, because nothing seemed to exist at this layer of the stack. What pushed us to focus was a specific incident: the team was using an agent to replace a payment service class, and one of our automated agents picked up a backlog ticket to extend that same class with an additional provider. Different worktrees, no overlapping lines, both merged clean, and the second change depended on an extension point the first had deleted. We caught it in review, and it would have failed in CI, but something like this can slip into production without proper tests in place. It cost us a day of refactoring, and the gap was obvious.
After using the tool internally, I extracted it from our internal tools monorepo and open-sourced it in late August.
Why "intent before code" rather than post-hoc PR/diff analysis?
Timing and determinism. Post-hoc catches the collision after both agents have spent their tokens, so the best you can do is discard or refactor work. Comparing plans catches it before those costs exist. And a declared operation is a fact you can assert HIGH severity on, while an operation inferred from a diff is a guess. A coordination layer that guesses wrong at HIGH severity gets ignored within a week, which is why prose-inferred matches cap below HIGH in 0.4.0 and only declared operations can assert it.
Who is the primary user today: solo power users running 2-3 agents, or teams running fleets?
Solo power users running two or more agents on one machine. That is who we were. Fleets and teams are the later story, and honestly need further validation before we lean on that.
What does success look like at 1.0 that isn't true at 0.4.0?
Published coordinated-vs-uncoordinated benchmarks with raw data. Versioned JSON Schemas for the full protocol surface, hopefully with community agreement. At least one language adapter so symbol scopes resolve structurally instead of as strings. Calibration evidence that findings correlate with real conflicts. Protocol stability is the promise 1.0 makes; 0.4.0 does not make it yet.
Design choices
Why advisory-only and never hard locks? What about "agent ignored the warning and shipped damage"?
A lock assumes the declarer is right and will finish, and agents abandon work constantly. One stale lock could gridlock an entire fleet. Deeper than that: we cannot enforce a semantic lock without intercepting filesystem writes, which we deliberately do not do, so a "lock" would be an advisory pretending to be a lock.
On the tradeoff: the warning is not the enforcement point, acceptance is. Accepting a ChangeSet requires no unresolved HIGH findings plus verification against the exact candidate fingerprint, and the ledger records that a finding was overridden. Ignoring a warning becomes a visible decision instead of a silent one.
Why deterministic rules and no LLM judge for conflicts? When do pure rules hit a wall?
The conflict detector is the trust core, so it has to be reproducible, testable, free, offline, and identical for every user. A judge that changes its mind between runs erodes exactly the trust the layer exists to provide, and an LLM judge is only as good as the context it is given.
The real limits of rules show up when meaning, not exact text, matters: synonyms, undeclared renames, cross-file contract drift. The plan is to keep rules authoritative and let fuzzier matching only propose findings below HIGH.
Why SQLite under the .git common dir instead of a separate service, CRDTs, or Git notes?
SQLite in the common dir is zero infrastructure, transactional, and queryable, and the common dir is the one location every worktree of a repo already shares, so worktree isolation plus shared state comes for free.
CRDTs solve convergence of concurrent edits, but our problem is whether two plans can both be true, and convergence is not correctness. CRDTs are engineered to make conflicts disappear; Foremerge exists to make them visible. They are excellent for what they are built for, and the wrong tool at the layer we would use them.
Git notes are append-only but query poorly and entangle coordination state with push semantics. And I would push back hard on any new storage engine until SQLite produces evidence one is necessary.
Why one Rust binary (CLI, daemon, MCP) rather than a library every runtime embeds?
Agents integrate through protocol surfaces (MCP, CLI, JSON API), not linkage, and runtimes already speak MCP. A library per runtime means N bindings with version skew. One binary keeps the deterministic core single-sourced.
What did you deliberately put in non-goals that people keep asking for anyway?
Hard locks are the most requested, then a merge queue, then editor-buffer sync. They share a theme: each would make Foremerge claim authority it cannot honestly enforce. A lock it cannot physically hold, a merge decision that belongs to your Git host, a synchronization layer that would confuse convergence with correctness. The non-goals list is the tool refusing to pretend. Also on the list: automatically trusting a ChangeSet because an agent says its tests passed. Verification runs, or acceptance does not.
Protocol practice
How much do agents actually publish intents in the wild?
With the MCP skill or project template in context, compliance is good, because declaring intent is just another tool call in the loop. Without it, compliance is whatever your system prompt enforces. Hard numbers on wild compliance rates are one of the things we most want real traces for, beyond our own use.
How stable is the scope vocabulary, and who owns expanding it?
The seven operations (add, extend, modify, replace, remove, rename, migrate) are versioned with the protocol. Expansion needs to happen conservatively through community discussions, and the same goes for removals. If you hit a real change the vocabulary cannot express, that report is a contribution.
When should an agent claim vs only publish intent? What cadence in a long session?
Publish intent when the plan forms, claim when you are about to touch the scope. Claims are leases, so long sessions renew them, and a materially changed plan is a new intent. Detecting drift between what was declared and what is actually being edited is on the 0.5.0 roadmap, based on feedback from Reddit reviewers.
Empty conflicts on first publish is "none yet," not "none ever." How should clients handle that?
Correct reading, and a source reviewer made the same point independently. 0.4.1 adds an as_of sequence to conflict queries so a client can tell how stale its view is instead of mistaking an early empty answer for a verdict.
What should happen when two agents claim the same scope and both continue?
Both can continue, because claims are advisory leases, and that is deliberate. The protocol's ideal shape: the second claimant sees the finding at claim time, and its options are all first-class moves. Proceed anyway (recorded), coordinate by recording an assessment (conflicts, depends_on), or re-scope the work. If both continue regardless, the acceptance gate is the backstop: the first ChangeSet through accepts clean, the second faces an unresolved finding that requires explicit resolution or an operator override, and every step of that is in the ledger. For HIGH findings, my advice is that a human should make the call. The tool's job is to make sure the call is made with both plans visible, not discovered at merge.
Measurement
How do you measure false positives vs false negatives on real multi-agent traces?
Paired runs: the same tasks with and without coordination, then labeling discarded work, post-integration failures, and warnings dismissed as noise. False negatives are the hard half because they are breaks that nothing detected, which means human labeling. We will publish raw results before making any quantitative claim, and until then the documentation says exactly that.
Synonyms and rename collisions (PaymentService vs BillingService): research track or near-term?
Worth splitting into three layers. Declared renames are in the operation vocabulary and detected deterministically. Across different labels, the deterministic core refuses to guess on purpose: scope matching is token-normalized but never speculative, because speculation about synonymy erodes the trust the HIGH tier depends on. Instead, the protocol hands semantic similarity to the layer that actually has semantic understanding: the agents. An agent that recognizes two differently-named intents overlap records an assessment (conflicts, compatible, duplicate, or depends_on, with rationale), and that verdict becomes durable, queryable coordination state the rest of the fleet sees. Language adapters shrink the alias problem near-term by resolving symbols to canonical paths instead of strings. The research track is narrower than it sounds: whether the engine itself should ever propose cross-label matches below HIGH with calibrated confidence.
Are conflict suggestions meant to stay heuristic forever or become policy-driven?
Suggestions stay heuristic suggestions in core. The policy layer being designed in the community threads is where a team encodes what must happen when a finding fires. The resolution itself stays a recorded human or agent decision.
Which shipped rule are you least confident in, and why keep it?
Probably divergent_rewrite. Two broad modifications of one scope are sometimes genuinely compatible, which is why it fires below HIGH. We keep it because the cost asymmetry favors the warning: dismissing a wrong one costs a sentence, missing a right one costs a rewrite.
The trust boundary
Validation runs as trusted OS commands with no sandbox. What's the threat model for agent-supplied check names?
Checks are registered by name, by a human, once (foremerge checks set unit-tests -- cargo test --workspace). Agents reference the name and cannot supply arbitrary command lines; the string an agent sends is a lookup key, not a shell command, and the stored command is argv, never shell-interpreted.
The residual risk is real and documented: agents still write the code that a legitimate check executes, so a malicious test file runs with your privileges regardless. Our threat model is fallible agents, not adversarial ones. If your agents are adversarial, you need OS-level sandboxing underneath everything, and no coordination layer replaces that.
"Authoritative" validation can be gamed if tests mutate and restore the tree. Accepted residual risk or future fix?
Accepted residual risk today, stated in the limitations doc. Verification binds to the exact fingerprint and failed validation leaves refs untouched, but a test that lies about itself can win. Re-hashing the tree after the run is a plausible 0.5+ hardening.
ChangeSet accept is not merge/push. Will Foremerge ever gate merges?
Core stays above Git permanently; not becoming a merge queue is a listed non-goal. The roadmap path is status checks: surface acceptance state to your Git host and let your branch protection do the gating. Git gates, Foremerge informs.
Coordination state isn't in clone/push. What's the real backup story before multi-machine?
Intentional, because Git is the wrong transport for it. Coordination state is live, expiring, operational data, and Git moves snapshots of history. A claim is a lease; a lease you learn about only when someone remembers to push is pointless, and a stale synced copy is worse than none because it looks authoritative.
What is actually at risk: the store is .git/foremerge/state.sqlite3, running in WAL mode. Losing it loses zero code. It loses open intents and claims (transient, agents re-declare) and the durable record: the hash-chained event ledger, assessments, verification evidence, acceptance decisions. For a solo user that is telemetry and audit trail. If you care about the provenance ledger as a record, back it up.
The two loss scenarios that actually happen are re-cloning a repo and disk death. General backup tools cover the second, with one catch: some configs exclude .git directories. The correct stopgap is SQLite's online backup, which is safe while the service runs (never plain cp a WAL-mode database mid-write):
sqlite3 "$(git rev-parse --git-common-dir)/foremerge/state.sqlite3" \
".backup '$HOME/backups/foremerge-$(date +%Y%m%d).sqlite3'"
Restore is putting the file back before starting the service. A built-in foremerge backup command is a natural first installment of the export/import tooling already on the roadmap.
Roadmap
Multi-machine is "later." What's the hardest unsolved piece: auth, consistency, or threat model?
The trust model, more than consistency. Consistency is boundable: one shared daemon first, no distributed SQLite pretensions. But a verification result asserted from another machine is hearsay unless re-executed or attested, and designing auth and attestation without turning a local-first tool into a server product is the genuinely hard part. That tension is why it sits in "later."
Which language adapter first, and will manual scopes stay first-class?
TypeScript and Python first, following where agent usage concentrates. Manual scopes stay first-class forever: APIs, schemas, config, infrastructure, and environment variables live in no AST. Many of the things agents collide on are not code symbols and appear in no syntax tree. Two agents both migrating the same table is exactly the "both plans cannot be true" failure, and often a worse one than a code collision, because nothing else in the stack even pretends to watch for it.
When will you publish benchmarks, and which metric matters most?
Pilot after the 0.5.0 tooling settles. Priority order: conflicts avoided, discarded work, post-integration failures, time-to-merge. Wasted human and agent hours are the cost that scales with fleet size.
Windows install story: intentional lag or capacity?
Release CI builds and tests x86_64-pc-windows-msvc today, including Windows-specific validation-timeout behavior, and cargo install foremerge works. The curl installer is unix-only; a winget or scoop manifest would be a very welcome contribution.
What's the business/maintenance plan if this stays open source?
The core stays Apache-2.0 and local-first, and the local tool will never require a server. GitHub Sponsors covers maintenance today. If a sustainable business ever grows around this, it will be around optional team infrastructure, the shared coordination service already described in the roadmap's "later" section, and never around gating the local tool. The word "optional" in that roadmap entry is load-bearing, and I intend to keep it that way.
Strategy
Best path to stickiness: MCP skill, setup templates, or CI status checks?
The MCP skill, because it works with any coding tool and makes coordination another tool call instead of a discipline. Setup templates second. Status checks third, because that converts an individual habit into a team default.
What would make Claude/Codex/Cursor default to Foremerge?
Community adoption, and the fact that the protocol is boring and neutral. Versioned schemas, no vendor coupling, Apache-2.0, published evidence. Runtimes adopt what their users already run, so the path is bottom-up through MCP, not partnerships.
If another project ships "agent locks" or "agent worktrees," where do you still win?
Locks and worktrees manage files; we compare plans. Worktrees are complementary and we assume them. If someone ships actual semantic plan comparison, we compete on determinism, the verification gate, and the provenance ledger. And if they do it better, it is Apache-2.0 all the way down and users win.
What contribution do you most want right now?
Conflict evidence. Real traces where detection was right, wrong, or missed, even a paragraph describing the collision. Second: scope vocabulary proposals grounded in a real codebase. Third: client adapter recipes for specific agent stacks.
The takeaway
The questions I could answer fastest were the ones where a non-goal did the work. Never hard-lock, never merge-queue, never guess about synonymy, never trust an agent's word for its tests: each of those is the tool declining authority it could not honestly enforce, and each one made the harder questions (trust boundaries, multi-machine, benchmarks) easier to reason about.
If you run parallel coding agents and have seen a collision that clean diffs missed, that story is the contribution I want most: open a discussion. And if you read the source and come back with questions like these, you will get answers like these.
Thanks again to Vedant for the interrogation.
Top comments (0)