The distinction, in one sentence
Orchestration is central control: one component tells each agent what to do next. Choreography is distributed coordination: each agent publishes events and reacts to events from peers, with no one in charge.
Both can produce the same end-to-end behavior. The choice between them is not about “which is cleaner” — it is about where the trust boundary sits.
When orchestration wins
Orchestration is the right answer when you need an auditable decision log, deterministic failure handling, or human-in-the-loop approval. A central orchestrator is a natural place to enforce policies, checkpoint state, and implement retry logic — because it is the only component that sees the whole flow.
Railyard was built for this case. Its pipelines are declarative, its state is checkpointed, and its failure handling is defined up front. That rigidity is the feature: in regulated environments, you have to be able to prove why the system did what it did.
When choreography wins
Choreography is the right answer when agents are mutually distrustful, when the coordination graph changes at runtime, or when no single component should be able to unilaterally stop the system.
The canonical example is a federation of agents from different organizations — each org controls its own agents, none trusts the others to arbitrate. In that setting, a central orchestrator is a policy problem before it is an engineering problem, and choreographed event exchange plus per-party enforcement at the boundary (Nautilus’s job) is the cleaner design.
The middle
Most real systems are a mix: choreographed at the outer edges, orchestrated within each trust domain. Railyard and Nautilus are built to compose this way — Railyard drives the inside, Nautilus mediates the outside, and Fathom sets the rules that both consult.
The heuristic: pick orchestration when you need to answer “what happened and why,” and pick choreography when you need to answer “who decided, and with whose authority.” Most systems need both.