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.
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.
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.
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:
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:
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.
| | 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 |
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.