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 ...
For further actions, you may consider blocking this person and/or reporting abuse
This is one of the clearest structural breakdowns of agentic systems architecture I've read recently. That single-question test ("What happens if you kill it?") is a brilliant heuristic for separating the Execution Plane from the State/Consensus Plane.
A few technical observations on why Foremerge's approach to coordination over orchestration makes sense:
PaymentServiceinterface while Agent B extends a class implementing that old interface in a different directory,git mergesucceeds silently. Catchingdestructive_vs_additiveintent at the semantic level (symbol:PaymentService=replace) before AST generation is the exact layer VCS has been missing since multi-agent codegen became viable.--scope 'symbol:...') keeps the coordination engine deterministic and mathematically verifiable.Curious about your roadmap: are there plans to export intent state to a remote daemon or shared CRDT layer for multi-machine/multi-developer agent synchronization across distinct local Git clones?
Awesome work open-sourcing this—submitting to
awesome-agent-coordinators(when it inevitably gets created) for sure!Thanks. The optimistic concurrency comparison is fair, with one difference: the check happens earlier, while the work is still a plan, and again at acceptance.
Two corrections, so nobody questions a bigger claim than the tool makes. Foremerge doesn't analyze ASTs right nowrf. Scopes are declared by the agent and there's no whole-program analysis, so it can miss a collision when two agents name the same concept differently. And "deterministic" means the same declarations always produce the same finding, not that the finding is proven correct. The rules are still heuristics.
On multiple machines: an authenticated shared daemon is on the public roadmap. I lean away from a CRDT for it. A CRDT lets copies converge without agreeing, but the acceptance gate needs one authoritative answer to "is there an unresolved HIGH finding right now?" That's an agreement problem, not a convergence problem.
The kill test is a clean way to draw that line. I've been in code reviews where engineers were mixing what you'd call orchestrator and coordinator concerns into the same process, and the conversation went in circles because everyone's mental model of "orchestrating" was slightly different. Splitting authority-over-sessions from shared-state-awareness as two distinct layers tends to end that argument pretty quickly.
Thanks, Tae. That matches what I've seen in that the argument usually isn't about the design, it's about which half of "orchestrating" each person means. In those reviews, which concern kept getting pulled into the orchestrator process: conflict detection, or deciding what's safe to accept?
The acceptance boundary is what makes this distinction especially useful to me. An orchestrator can successfully manage the execution of several agents while the resulting changes can still be semantically incompatible. That suggests the final acceptance step should be independent of both execution and agent self-reporting. In other words, “all agents finished” and “all tests passed” aren't necessarily enough to establish that the combined change is safe to accept. A coordination layer that evaluates the resulting state against declared intents could provide a much stronger final signal without needing to control how the work was executed.
Agreed Glen, and that's where I'd draw the line too. "All agents finished" is a fact from the orchestrator, and "tests passed" is only the agent's word unless something independent ran the tests.
One correction on what exists today. Foremerge's acceptance gate checks two things: that no HIGH finding between the declared intents is unresolved, and that a named check Foremerge ran itself passed against the exact candidate. It doesn't yet compare the resulting diff against what was declared, so an agent that wanders outside its declared scope still gets through. That comparison is the most requested feature since launch.
I'd like your take on the open design question: should drift raise a finding, or block acceptance outright?
Submitting to the closest wrong noun is how half the category errors in this space happen - the list shapes the vocabulary, and the vocabulary shapes what people build. Orchestration owns lifecycle, coordination owns agreement; a coordinator with no start/stop authority is a real layer and it's chronically unlisted. There's no awesome-agent-coordinators list yet because coordination looks like plumbing until the day you have two agents.
"Orchestration owns lifecycle, coordination owns agreement" is a sharper way to say it than anything in the post.
The plumbing point is right too. Nobody goes looking for a coordination layer until two clean merges contradict each other, and by then the vocabulary has already filed it under orchestration. If that list existed, what else would you put on it?
The useful contract between these layers is a correlation ID, not shared authority: the coordinator can attach findings to a declared intent, while the orchestrator decides how to schedule or recover the run. That keeps an advisory conflict from becoming a stranded process lock.
Agreed, and that's close to how it works today. Every finding cites the two intent IDs it compares. An orchestrator that keeps the intent ID for each session can decide to pause, reschedule or carry on, and Foremerge never touches the process.
Right now the in the open source version the orchestrator has to poll check_conflicts to learn about new findings. An event subscription interface is on the roadmap. Would you rather the coordinator push findings to the orchestrator, or stay pull-only so it never depends on anyone listening?
Kill your orchestrator and the fleet stops. Kill your coordinator and every agent keeps typing."
That one line is the clearest explanation I've seen of this distinction. I've been reading about AI agents for weeks and every article uses "orchestrator" and "coordinator" like they're the same thing.
I'm a beginner — I just started writing Python tutorials this week. So I'm nowhere near running 14 parallel agents. But here's what this post made me realize:
The reason I got confused by the terminology is the same reason most bugs happen in infrastructure. Two things get called by the same name, and then everyone assumes they behave the same way.
The other thing that stood out: "The coordination layer's absence hurts on a delay." That's the scary kind of bug. Not the one that breaks immediately — the one that works fine until it doesn't.
Saved this one. The noun test is going in my notes.
Thanks for reading it. Two things get one name, everyone assumes one behaviour. That is a naming collision, and it is the same failure this tool exists to catch one layer down, where two agents use one word for different operations.
Worth saying plainly though, since you are just starting out: at one agent you need neither layer, and adding them makes nothing better. The reason the vocabulary is still worth having early is the delay you picked up on. Orchestration problems announce themselves the same afternoon. A session died, two agents stomped the same file, nothing is running and you cannot tell why. You feel it, so you go and find a tool. Coordination problems announce nothing. Both agents finish, both are right, Git merges both without complaint, and the thing that breaks is something neither of them was looking at. Nobody goes looking for a tool for a problem that never raised its hand.
Delayed failure you describe is the scary one. A merge conflict at least gets your attention. 2 clean merges that quietly disagree with each other can survive for days before anyone notices.
Right, and it is worse than "nobody notices". A merge conflict is an object: it has a name, it turns up at a specific moment, and a human has to resolve it before anything lands. Git's real trick was never preventing disagreement, it was making disagreement a first-class thing with a name. Two clean merges that quietly disagree produce no object at all. Nothing to assign, nothing to route, nothing to count.
I have a small amount of real data on this now. I replayed 76 intents from our own agent builds through the detector this week and then merge-tested the results against the actual commits. 48 / 48 intents that touched the same files were flagged. There was one conflict (also flagged) at merge time which highlighted a genuine conflicted gap in the protocol where one agent named the class and the other named the method inside it. We are working on resolving this for the next release.
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.