DEV Community: Nick Woodhead

AI agents introduced several new layers to the development stack. You are probably missing this one.

Nick Woodhead — Thu, 17 Sep 2026 01:39:19 +0000

The development stack grew more in the last two years than in the previous ten. Most teams adopted the new layers so quickly they never noticed them becoming layers. Count them.

The agent layer: Claude Code, Codex, Cursor. The thing that writes code. Two years ago this layer did not exist; today it is where implementation happens.

The context layer: CLAUDE.md, AGENTS.md, rules files, memory systems. Telling agents how your repository works, what your conventions are, what not to touch. Everyone who onboarded an agent wrote these within a week, because an agent without context is a very fast junior with amnesia.

The tool layer: MCP. Agents reaching databases, browsers, issue trackers, deployment systems. Adopted fast because an agent that cannot touch your systems can only talk about them.

The isolation layer: git worktrees, containers, cloud sandboxes. One agent per checkout, because two sessions in one working directory stomp each other's files and poison each other's context. Anyone who ran two agents learned this in the first afternoon.

The orchestration layer: Gas Town, claude-squad, Foreman, and a fast-growing ecosystem of fleet runners. Who works on what, which sessions are alive, what needs review. The moment you run more than two or three agents, supervision becomes its own job, and this layer takes it.

Each of these layers got adopted quickly for the same reason: its absence hurts immediately and obviously. No context, the agent writes nonsense today. No isolation, files get stomped today. No orchestration, you lose track of your fleet today.

There is one more layer, and almost nobody runs it, because its absence hurts silently.

The failure that announces nothing

Two agents, one repository. Agent A is told to replace PaymentService with a Stripe-specific implementation. Agent B is told to add PayPal support to PaymentService. Run the failure through every layer you have adopted.

The agent layer performs perfectly: both sessions write competent code. The context layer performs: both followed your conventions. The tool layer performs: every MCP call succeeded. The isolation layer performs: separate worktrees, no stomped files. The orchestration layer performs: two independent tasks, both completed, both green.

Git merges both branches without a conflict, because the changes touch different lines. And the design is now broken: agent B built on an extension point agent A deleted. Nothing in the toolchain objected at any moment, because every layer you have answers a different question, and none of them answer this one: can these two plans coexist?

Git compares diffs, and there is no diff at the moment this collision actually happens. The collision is between intentions, at plan time, before either agent has written a line. We hit versions of this for months. The one that finally made us build tooling surfaced three days after a clean merge, in production.

The coordination layer

The missing layer answers exactly one question: can the work currently in flight all be true at once?

To be precise about what it does not do: it does not create plans. Your agents plan however they already plan. The coordination layer is a ledger and a referee, not a planner. Each agent declares what it is about to change before writing code: a semantic scope plus an operation, like symbol:PaymentService=replace. Scopes are not file paths, because file paths miss API, schema, configuration, and cross-language collisions. Deterministic rules compare the declarations and raise a finding while both sides are still plans: the rule that fired, an explanation, a suggested resolution. In the PaymentService case, one destructive operation and one additive operation on the same scope cannot both be true, and the second agent learns this in the same call that published its intent.

The other half of the layer is evidence. When work finishes, acceptance is gated on a verification command the layer executes itself against the exact fingerprint of the candidate change. An agent reporting that tests pass is provenance, not proof. If the tree changed after validation, the attempt does not count.

What building one taught us

Three lessons, each paid for.

First: declared beats inferred. We started by inferring operations from agent prose, and it produced confident false alarms. "Delete the flaky ThumbnailCache benchmark test" was read as destroying ThumbnailCache itself. Widening the verb list just moved the boundary. Making agents declare the operation as structured syntax removed the whole error class.

Second: advisory beats locks, but severity must be earned. Most overlaps between agents are compatible, and a lock serializes work that did not need serializing; the moment a lock exists, a busy repo becomes a queue. So claims warn instead of block. The discipline that makes warnings survivable is reserving HIGH for two declarations that genuinely cannot both be true. Our repo carries a regression fixture that fails the build if compatible work ever raises a HIGH.

Third: soft claims, hard gate. Everything before the finish line is advisory, because the finish line is not: no acceptance while an unresolved HIGH finding stands, and no acceptance on self-reported evidence. The gate staying hard is what lets everything before it stay soft.

Do you need this layer?

If you run one coding agent, no. Close the tab, you are fine.

If you run two or more on the same repository, whether in parallel today or sequentially across days, you have already had the silent version of this failure whether you noticed it or not. The tell: a change that made you say "wait, when did that class stop existing?" three days after a clean merge.

We open-sourced the coordination layer we built and use: Foremerge (https://github.com/naw103/foremerge), Apache-2.0, one Rust binary, local-first, above Git rather than inside it. Setup is one paste into Claude Code, Codex, or Cursor. Stated plainly per the honesty its own docs demand: detection is deterministic but heuristic and can warn on compatible work, claims never lock anything, and there are no published benchmarks yet, so no performance claims. The layer matters regardless of whose implementation you run, including one you build yourself.

The stack grew five layers in two years because each one's absence hurt the day you needed it. The sixth one's absence hurts three days later. That is the only reason you are probably missing it.

Foremerge
The open-source coordination protocol for parallel coding agents, built above Git. Agents declare intent and semantic scopes before writing code, so plans that cannot both be true collide in a queryable store instead of in your merge. One Rust binary, Apache-2.0, local-first.

curl -fsSL https://foremerge.com/install.sh | sh

Any thoughts on this?

Nick Woodhead — Thu, 17 Sep 2026 01:32:04 +0000

Nick Woodhead

Sep 4

31 hard questions about coordinating parallel coding agents, answered

#ai #opensource #git #rust

11 min read

Both words mean "make several agents work together," so they get used interchangeably. They name different layers, and one question tells you which one you are running.

Nick Woodhead — Mon, 14 Sep 2026 05:06:30 +0000

Nick Woodhead

Sep 14

Agent orchestrators and agent coordinators are not the same layer

#ai #devtools #opensource #git

6 min read

Agent orchestrators and agent coordinators are not the same layer

Nick Woodhead — Mon, 14 Sep 2026 05:05:29 +0000

If you only ever run one coding agent, you do not need either of these. Close the tab, you are fine.

For everyone else: I maintain Foremerge, and I recently submitted it to a list called awesome-agent-orchestrators. It was merged into a section for infrastructure and coordination protocols, which is the right shelf. The list's name is still the wrong noun for it. Foremerge is not an orchestrator. It cannot start an agent, cannot stop one, and does not know when one is running. Coordination currently lives as a shelf inside an orchestration list, which says a lot about how new the distinction is.

The two words get used interchangeably, and reasonably so. Both mean something like "make several agents work together." But they describe different layers of the stack, with different authority, different failure modes, and different reasons to exist. Here is the difference, and a one-question test for telling them apart.

The test

What happens if you kill it?

Kill your orchestrator and the fleet stops. Sessions die, queued work never starts, nothing is spawned or resumed until you bring it back. An orchestrator sits in the control path.

Kill your coordinator and every agent keeps typing. You lose the shared picture, not the work. A coordinator sits beside the control path, not in it.

That single structural fact drives everything else about how the two behave.

What an orchestrator does

It owns the run loop. Concretely: spawning sessions, placing each one somewhere isolated (a worktree, a container, a cloud sandbox), deciding what runs next and in what order, restarting what died, routing prompts and results, and giving you one screen showing which of your fourteen sessions are alive and which are waiting on you.

This is real work and it becomes its own job the moment you pass two or three agents. The ecosystem here is growing fast and includes both standalone session managers, claude-squad, dmux, amux, agent-deck and their neighbors, and in-session fan-out inside a single agent, like Claude Code's subagents or a workflow script that runs a dozen tasks in parallel.

An orchestrator's authority is imperative. It can start things and stop things. Its input is tasks. Its state is sessions and processes. Its question is who is running what right now?

What a coordinator does

It never starts or stops anything. Its input is not tasks but declarations: before an agent edits, it states what it is about to change, in a form precise enough to check.

foremerge intent publish \
  --agent "$AGENT" \
  --task modernize-payments \
  --summary "Replace PaymentService with StripePaymentService" \
  --scope 'symbol:PaymentService=replace'

A scope is not a file path, because file paths miss API, schema, configuration and cross-language collisions. The operation (replace, extend, and the rest) is declared rather than parsed out of the summary. When a second agent declares symbol:PaymentService=extend, deterministic rules compare the two declarations and return a finding in the same call that published the second intent. This is real 0.4.0 output, captured while writing this piece:

{
  "kind": "destructive_vs_additive",
  "severity": "HIGH",
  "scope": { "kind": "symbol", "key": "PaymentService" },
  "explanation": "One intent will replace `PaymentService` while the other will extend it; both declare the same semantic scope.",
  "evidence": {
    "rule": "FM-C001",
    "source_operation": "extend",
    "target_operation": "replace",
    "source_operation_inferred": false,
    "target_operation_inferred": false,
    "detected_before_code": true
  }
}

Note what is absent. No process id, no session, no queue position, no instruction to either agent. The coordinator does not know whether either agent is currently running, and does not need to. Its question is can the work in flight all be true at once?

Its authority is evidentiary rather than imperative. It cannot stop a keyboard. What it can do is withhold its blessing at the end and say exactly why:

BLOCKING_CONFLICT: 1 unresolved HIGH intent conflict(s);
coordinate and resolve them before acceptance

CHECK_FAILED: this ChangeSet is UNVERIFIED (no verification check was
run against this ChangeSet)

Both are overridable, by a human, with a recorded reason. That is the shape of evidentiary authority: it can make you look, it cannot make you stop.

The split, in a table

	Orchestrator	Coordinator
Owns the run loop	Yes	No
Authority	Imperative: start, stop, schedule	Evidentiary: findings, gates, audit
Input	Tasks	Declared intents and scopes
State	Sessions, processes, queues	Intents, claims, findings, changesets, validation
Question answered	Who is running what?	Can these plans coexist?
If it dies	The fleet stalls	Agents keep working, you lose visibility
Visibility scope	Its own sessions	The repository, across sessions and vendors

Three consequences worth caring about

One: an orchestrator can only see its own fleet. It knows about the sessions it spawned. Your actual working day is Claude Code in one window, Codex in another, Cursor open on the same repository, plus a colleague, plus something you started on Tuesday and came back to on Thursday. Claude Code coordinates its own subagents inside one session, and does it well, because there is one root and one plan. Between roots, nothing does. A coordinator earns its keep by being neutral about who spawned the agent, which is also why one built into a single runner would see less.

Two: an orchestrator's only lever is scheduling. If the only tool you have is control over execution order, then your only conflict resolution is serialization: run them one at a time and the collision cannot happen. That is correct and expensive, because most concurrent work on a repository is compatible and did not need serializing. A coordinator can let both agents run and raise a finding, precisely because it is not responsible for the run loop.

Three: being outside the control path forces a design choice. A coordinator must never lock, because a single crashed agent holding a lock would stall the fleet, which is the exact failure it was supposed to help you avoid causing. So claims are leased and advisory: overlap produces a warning and shared context, never a lock. What makes advisory claims survivable is that the last step is not advisory. No acceptance while an unresolved HIGH finding stands, and no acceptance on an agent's own report that tests passed. Soft claims, hard gate.

Could one tool be both?

Structurally, yes, and nothing stops it. An orchestrator could grow declared scopes and deterministic comparison rules and cover both layers in one process. Most of the tools on that list manage sessions and worktrees, which is what they set out to do, and its infrastructure section already carries a few coordination tools, this one included. What I have not yet seen is a single tool that runs the agents and also compares declared operations before code exists.

The interesting part is what such a tool would have to add, because it is not just a feature. An orchestrator holds prompts. A prompt is prose, and inferring an operation from prose produces confident false alarms: we tried it, and "delete the flaky ThumbnailCache benchmark test" got read as destroying ThumbnailCache itself. Widening the verb list only moved the boundary. Asserting HIGH severity on a guess is how a coordination tool gets ignored in a week. A declared operation is a fact, and facts are what a rule can be strict about. In 0.4.0 only declared operations can assert HIGH; prose-inferred matches cap below it.

So the question is not whether one process can hold both layers. It is whether it holds declarations or just prompts.

Which one do you need?

One agent: neither.

Two or three in parallel: orchestration first. Its absence hurts today, in ways you notice within an afternoon. Lost sessions, stomped files, no idea what is still running.

The coordination layer's absence hurts on a delay. Both agents finish, both look right, Git merges both without a conflict because nothing textually overlaps, and three days later you are asking when that class stopped existing. That is the failure that made us build this one.

Foremerge is the coordination layer we extracted from the monorepo of internal tools we use building GPTree, and open-sourced in late August 2026. One Rust binary, Apache-2.0, local-first, a CLI plus a local JSON API plus an MCP server over one SQLite store inside your repository's Git common directory. It sits above Git rather than inside it, and it composes with whatever orchestrator you already run.

Stated plainly, per the honesty its own docs demand: detection is deterministic but heuristic, so it can warn on compatible work and can miss incompatible plans when agents name the same concept differently. Claims never lock anything. Agent identity is self-asserted, so the ownership guards raise the bar against confusion, not against a caller that deliberately presents another agent's id. It is local-only today, with no multi-machine mode. There are no published benchmarks yet, so there are no performance claims here.

The layer matters regardless of whose implementation you run, including one you write yourself. So here is the noun test one more time. If it can start and stop your agents, it is an orchestrator. If it can only tell you whether their plans can coexist, and refuse to bless the result at the end, it is a coordinator. Most fleets run the first. Almost nobody runs the second.

[Boost]

Nick Woodhead — Fri, 04 Sep 2026 05:39:26 +0000

Nick Woodhead

Sep 4

31 hard questions about coordinating parallel coding agents, answered

#ai #opensource #git #rust

11 min read

31 hard questions about coordinating parallel coding agents, answered

Nick Woodhead — Fri, 04 Sep 2026 04:50:40 +0000

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.

Parallel coding agents without the carnage

Nick Woodhead — Thu, 27 Aug 2026 18:21:26 +0000

We build GPTree with several coding agents working the same repository at once: Claude Code, Codex, and Cursor, each in its own git worktree. The failure that finally made us build tooling for it was small and completely silent.

One session was told to replace PaymentService with a Stripe-specific implementation. Another was told to add PayPal support to PaymentService. Different worktrees. Different files. Zero textual conflict. Git merged both branches cleanly, and the second change now depended on an extension point the first had deleted. Nothing in the toolchain had an opinion about it at any moment.

Git compares diffs. It cannot compare plans.

Worktrees isolate files, not plans

Worktrees became the standard answer to parallel agents for a good reason: two sessions editing one checkout will overwrite each other's files and poison each other's context. Isolated checkouts fix that completely.

But three failure modes survive file isolation, because they were never about files:

Destructive versus additive. One agent removes or replaces a thing another agent is building on. The example above. Merges clean, breaks the design.
Duplicate work. Two agents solve the same problem from different angles because nothing assigned ownership. You pay twice and then pay again to reconcile.
Contract drift. One agent changes an API, a schema, or a config contract while another codes against the old shape. Compiles, runs, disagrees at runtime.

A shared task list helps with the second one, if every agent reads it, every time. Nothing in that setup catches the first or third, because the collision is between intentions, and intentions live in prompts, not in any file a tool can watch.

Declare the work before doing it

Foremerge is the internal tool we built for this, open-sourced this week. It is a coordination protocol that sits above Git: agents declare what they are about to do, before they do it, in a form precise enough to check.

A declaration is an intent with one or more semantic scopes, each carrying an operation:

foremerge intent publish \
  --agent "$AGENT" \
  --task "modernize-payments" \
  --summary "Replace PaymentService with StripePaymentService" \
  --scope symbol:PaymentService=replace

Scopes are not file paths. The vocabulary covers symbol, api, schema, config, migration, contract, and more, because file paths miss API, schema, configuration, and cross-language collisions entirely. The operation (replace, extend, and so on) is declared rather than parsed out of the summary, so it does not matter how the agent phrased its plan.

When a second agent declares work on the same scope, deterministic rules compare the declarations and raise a finding while both pieces of work are still plans. This is real output from 0.4.0, captured while writing this post:

{
  "kind": "destructive_vs_additive",
  "severity": "HIGH",
  "scope": { "kind": "symbol", "key": "PaymentService" },
  "explanation": "One intent will replace `PaymentService` while the other will extend it; both declare the same semantic scope.",
  "suggestion": "Coordinate on a stable `PaymentProvider` contract first, then implement StripePaymentProvider and PayPalPaymentProvider behind it and migrate callers deliberately. This is a heuristic suggestion, not an automatic design decision."
}

The finding names the rule that fired, explains itself, and suggests a resolution. It does not block anyone. Claims in Foremerge are leased and advisory: overlap produces a warning and shared context, never a lock, because two agents can often work the same region compatibly and a lock would serialize work that did not need serializing.

The other half of the protocol is evidence. When an agent finishes, it publishes a ChangeSet, and acceptance is gated on verification that Foremerge runs itself: your named check (a build, a typecheck, a test target you registered) executed against the exact candidate fingerprint. An agent saying "tests pass" is recorded as provenance; it does not satisfy the gate. If the tree changed after validation, the attempt is non-authoritative and the gate says so.

Mechanically it is one Rust binary. The CLI, a local JSON API, and an MCP server are adapters over the same SQLite store, which lives inside your repository's git common directory, which is exactly why worktrees work well with it: linked worktrees share that directory, so every agent in the repo sees the same declarations while keeping isolated files. Local-first, no cloud, Apache-2.0.

The five-minute version
The fastest path is to let your agent set it up.

Paste this into Claude Code, Codex, or Cursor from inside the repository you want to coordinate:

Set up Foremerge in this repository so we can coordinate parallel agents.
1. Install it:      curl -fsSL https://foremerge.com/install.sh | sh
2. Initialize:      foremerge init
3. Wire this client and any others in use: foremerge setup all
4. Register the check I should be validated against, for example:
                    foremerge checks set test -- cargo test --all-targets
5. Confirm:         foremerge doctor --client all
Then read the Foremerge skill that step 3 installed for this client and follow
it from now on: publish your intent with semantic scopes before editing, claim
the scope, and check for conflicts before you start.

The MCP server gives the agent the full lifecycle as tools: publish intent, claim scope, check conflicts, publish ChangeSets, run verification, record the commit that landed. Set it up once per repository and every agent connected to that repository shares the same awareness.

Doing it by hand instead is the install line,

foremerge init

, and the commands in the README, which walks two throwaway agents into the exact conflict above in under five minutes.

What it deliberately does not claim
This is a pre-1.0, local-first MVP, and the parts it does not do are documented as carefully as the parts it does:

Detection is deterministic and explainable, but heuristic. It can miss synonymous concepts and warn on work that was always compatible.
Claims warn. They never lock files, symbols, or agents.
Passing validation proves that the recorded command passed for the recorded fingerprint. Nothing more.
The store is per-machine SQLite. Shared multi-machine mode does not exist yet.
There is a reproducible benchmark harness in the repo, but no published coordinated-versus-uncoordinated results yet. Performance claims wait for numbers.
The full list is in docs/limitations.md. We think a coordination tool that overclaims is worse than no coordination tool, because severity is the signal an agent uses to decide what to stop for, and a false HIGH is worse than silence.

Where this goes
The protocol is the part we most want feedback on: is the scope vocabulary the right shape, where would the conflict rules warn on compatible work in your codebase, and which collisions would they miss? Issues and Discussions are open.

Repo: github.com/naw103/foremerge
Site and install: foremerge.com
Crate: cargo install foremerge

If you run parallel agents and have hit collisions worktrees could not see, we would genuinely like to hear what they looked like.