The author describes Foremerge, an open-source coordination protocol for parallel coding agents that detects conflicts before changes are made, and explores its applicability to non-code domains while seeking real-world examples.
I maintain Foremerge, an open-source coordination protocol for parallel coding agents. Disclosure: it is my project, and this is a design question, not promotion or launch. The mechanism is small. Before an agent edits anything, it publishes what it is about to change as scopes, each with a declared operation. One agent declares symbol:PaymentService with replace. A second declares extend on the same scope. The second one gets a HIGH finding before either has written a line. The store is SQLite under the repository's Git common directory, so isolated worktrees share it. Claims are leased and advisory. Nothing locks. While looking at where the protocol assumes code, I noticed the lifecycle has two halves. The front half does not depend on Git for anything except locating the store: intent, claims, the conflict finding, the agent's own recorded judgement about an overlap, coordination messages, approval, and resolution. The scope vocabulary is closed today (symbol, api, schema, config, infra, test, migration, env, file, component, contract, domain), but the comparison is kind plus key plus operation. Whether an operation is add, extend, modify, replace, remove, rename, or migrate is a property of any resource, not of source code. The back half is Git all the way down. A ChangeSet is fingerprinted from the tree and the diff. Verification runs a named check and only counts if the fingerprint is identical before and after the run. Acceptance pins an immutable commit under refs/foremerge/accepted, and dependency order is proven by commit ancestry. Landing is proven by ancestry too. So the question. If you run agents that act on something other than a repository, what is your Git? Concretely: What gives a content-addressed snapshot of the thing an agent is about to change? A document revision id? A Terraform state serial? A CRM record version? For a lot of SaaS there is nothing like that. Then the back half degrades to "the agent says it did it", and the audit trail has to say attested rather than verified. What collisions have you actually seen between non-coding agents? The ones I can imagine: a support agent about to refund an order while another escalates it; two outreach agents drafting to the same contact. Two content pipelines posting the same topic to the same channel on the same day. I have not measured any of these. I would rather hear real ones. Should the scope vocabulary be open, so a project declares its own kinds such as record:hubspot/contact/123, or should there be per-domain profiles with their own matching rules? The token similarity that surfaces symbol:CreditLedgerService against symbol:CreditLedger will misfire on ids that differ by one digit. Is pre-action detection worth more when the action cannot be undone? Git makes reversal cheap, so in code the saving is rework. A sent email or an issued refund does not revert. What I am not asking is whether a model should judge conflicts. The design deliberately has no model in the loop: the detector is deterministic, and the agent doing the work records its own verdict on an overlap. I want to keep that. Limits, so nobody has to dig for them: local-first, one machine, the only shipped substrate so far is Git. Every claim in the post checks against shipped code or docs. The one I softened deliberately is the front half, which is described as not depending on Git except to locate the store, because the CLI still refuses to open a store outside a repository without an explicit database path.
Foremerge is an open-source coordination protocol for AI coding agents that detects intent conflicts before they cause code issues by sharing agent plans via a Git-based database.
The author describes an experiment where merging two AI agents' git worktrees led to test failures despite clean merges, highlighting the challenges of parallel agent development without mutual awareness.
The article discusses three unexpected problems when running multiple coding agents in parallel: conflicts over shared working tree, runtime collisions (database, ports), and difficulty detecting stuck agents. Solutions include using per-agent git worktrees, isolated runtimes, and monitoring remaining gap metrics.
The author argues that spreadsheet agents are slow to adopt because they lack Git-style collaboration infrastructure (diffs, reviews, rollbacks) that makes coding agents usable. They announce an early runtime to address this gap.
The author questions whether Git diffs remain adequate for human review as coding agents accelerate, suggesting a shift toward reviewing agent consequences and decisions with enhanced harnesses for better supervision.