Agent orchestrators and agent coordinators are not the same layer

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 a couple of weeks ago I submitted it to a list called awesome-agent-orchestrators. That was the closest existing list, and it is still the wrong noun. Foremerge is not an orchestrator. It cannot start an agent, cannot stop one, and does not know when one is running. I submitted anyway, because there is no list for the other thing yet.

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.

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.

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?

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.

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.

Structurally, yes, and nothing stops it. An orchestrator could grow declared scopes and deterministic comparison rules and cover both layers in one process. As far as I can tell, none of the ones on that list do today; they manage sessions and worktrees, which is what they set out to do.

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.

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.