Pattern Matrix/White Paper/C6

C6 · Choreography

What problem it solves

The Orchestrate pattern has a central conductor that commands each agent in turn: "do this step, then that step." This structure is correct in most scenarios, but it has two hard constraints that eventually hit a ceiling. The central conductor is itself a single point: if it fails, the whole flow stops. And every new agent added requires going back to change the conductor's logic. As the number and variety of agents keep growing and business boundaries fall under different teams, this central point turns from a coordinator into a bottleneck.

Choreography solves exactly this coupling problem at scale. It removes the central conductor and makes each agent an autonomous unit: it subscribes only to the events it cares about, reacts when an event arrives, and emits its result as a new event back onto the shared event stream, reporting to no center. The system's overall behavior is no longer written into a flowchart in one place; it emerges from every agent's local "subscribe–react–publish" rules. Adding a new agent only requires subscribing it to the events it should subscribe to, with no other agent changing a single line.

This deserves to be a pattern of its own because it is not a parameter variant of Orchestrate but the other pole of the collaboration topology: control shifts from centralized to distributed. In structural orientation it is the opposite of centralized collaboration patterns such as fan-out/gather and hierarchical delegation.

Why the coordinate is "Collaboration × Choreography"

This is the first pattern in the Collaboration module that does not fall on one of the six core topology columns, so it needs to be spelled out explicitly, just as the Action module's minimal tool set (A4) falls on "constraint" rather than a concrete topology column.

• Vertical axis · Collaboration: Choreography describes how multiple agents coordinate; there is no single-agent version, so the vertical axis sits firmly in the Collaboration module.
• Horizontal axis · Choreography (emerging topology, not one of the six core columns): The six core topologies (Chain, Route, Parallel, Loop, Hierarchy, Orchestrate) share an implicit premise—there is a designable control point. Chain has order, Route has a router, Parallel has fan-out/gather, Loop has an iterator, Hierarchy has a manager, Orchestrate has a conductor. The defining feature of Choreography is the removal of this control point. So it is not a seventh value on the core axis but the negative pole of the dimension "is control at the center or not." It and Orchestrate are a pair of twins: Orchestrate is coordinated by a conductor, Choreography is coordinated by events.

There is a clear criterion for why it is placed in the extension ring for now rather than promoted to a seventh core column: for a topology to qualify as a core column, it must cut across multiple cognitive functions. Chain, Route, Parallel, Loop, and Hierarchy all spread across several rows. Choreography currently holds densely only in the Collaboration row, with only faint echoes elsewhere—event sourcing in the Memory row, blackboard-style reasoning in the Reasoning row, event auditing in the Governance row—all adjacent but not yet dense. On top of that, as of 2026 the great majority of multi-agent systems in production are still orchestrated, and pure choreographed event-driven swarms appear mostly in research and a few decentralized systems. The evidence is not yet thick enough, so it is registered as an out-of-roster extension pattern. The promotion path is fixed: when two or three rows beyond Collaboration also have production-grade instances, Choreography cuts across enough, and at that point it joins the core axis paired with Orchestrate.

Core mechanism

Choreography is built from four engineering elements:

1. A shared event medium: an event bus (pub/sub), a shared blackboard, or a trace-leaving mechanism (stigmergy). All agents communicate through it indirectly, never calling each other point to point.
2. Autonomous subscribe–react units: each agent declares which events it subscribes to, decides on arrival whether and how to act, and publishes the result back as a new event. It does not know, and does not need to know, who picks up next.
3. Emergent global behavior: no single place holds the full flow. The overall collaboration is the result of all local rules running on the event stream. This is the entire power of Choreography, and the source of all its trouble.
4. Explicit termination and observability: because no center declares "the task is done," boundaries must be defined with an explicit terminal event or with an orchestrated saga's compensation chain. At the same time, every event must carry a correlation ID, or the causal chain cannot be traced when something goes wrong.

Where it fits in production

• Ecosystems with many agent types, owned by different teams, evolving independently: each team owns its own agents and joins by subscribing to the bus, with no need to change a company-wide central orchestrator.
• High-throughput event streams where central orchestration becomes a bottleneck or single point: systems such as risk control, content moderation, and monitoring alerts, where events flow in continuously and high availability is required.
• Highly dynamic environments where the flow cannot be fixed in advance: you cannot enumerate "which steps to take" ahead of time, and can only let agents react to the events at hand.
• Scenarios that require resilience and cannot have a central point of failure: there is no central conductor to fail, and a single agent's failure loses only its share of the function.

Where it tends to go wrong

• Deploying Choreography without observability: emergent behavior has no central trace, and when something goes wrong there is no place to start. Choreography depends heavily on Observability (G5)—every event must carry a correlation ID and be replayable along the causal chain. Build the Observability Harness first, then deploy Choreography; reversing the order guarantees trouble.
• Event storms / infinite loops: A emits an event that triggers B, B reacts and emits an event that triggers A, and the loop does not converge. You must enforce idempotency, add event TTLs, and detect loops.
• No one declares completion: after decentralization, "is this task actually finished" becomes a question no one can answer directly. Define it with an explicit terminal event or saga compensation; do not leave it vague.
• Treating Choreography as a cure-all: the default for most systems should be Orchestrate. Choreography earns its place only when scale, coupling, or availability hit a ceiling. Deploying it for the sake of being "advanced" means solving with the hardest-to-debug topology a problem that a single orchestrator would have handled.
• Forcing global constraints onto Choreography: decentralization and governance are naturally at odds. When strongly consistent approvals, quotas, or compliance constraints are needed, either keep a thin central gate (hybrid) or admit that Choreography does not fit that segment.

Key metrics

• Event traceability rate (healthy zone > 95%): the proportion of cases where a full causal chain can be reconstructed from the correlation-ID event log. This is the gating prerequisite for whether Choreography can go to production, directly tied to G5 Observability.
• Convergence rate / event-storm rate (healthy zone: runaway loops < 1%): the proportion of a collaboration that normally reaches a terminal event rather than falling into an infinite loop.
• Coupling blast surface (healthy zone ≈ 0): the number of other agents that must change when an agent is added or removed. This number approaching zero is precisely the core benefit of deploying Choreography, and the most direct measure of whether it was done right.
• End-to-end latency (healthy zone: comparable to the orchestrated version): decentralization should not trade resilience for a large latency increase; otherwise it is worth reassessing.

Minimal implementation skeleton

# Orchestrate (control group): the center holds the full plan and commands one by one
            orchestrator.run(task):
                for step in plan(task):
                    result = agents[step].execute()      # central scheduling
                    state.update(result)                 # central convergence
                return state.result

            # Choreography: no center, each subscribes + reacts + emits events
            bus = EventBus()                             # shared event medium

            class ChoreographedAgent:
                subscribes_to = [...]                    # I only care about these events
                def on_event(self, e):
                    if self.should_act(e):               # autonomous decision
                        out = self.act(e)
                        bus.publish(out, correlation_id=e.cid)  # after reacting, emit a new event, no report to center

            for a in agents:
                bus.subscribe(a.subscribes_to, a.on_event)
            bus.publish(initial_event)                   # ignition, then it all runs on emergence
            # Completion = a terminal event appears; tracing = thread the full causal chain by correlation_id
            

The four engineering points map to the four elements: EventBus is the shared event medium; subscribes_to plus on_event is the autonomous subscribe–react unit; no place holding the plan is emergence; correlation_id plus the terminal event is explicit termination and observability.

Enterprise deployment example

A content risk-control platform routed every piece of content through fixed steps in its first version, using a central orchestrator: check spam first, then fraud, then policy, then decide whether to escalate to a human. After a year in operation, the detection dimensions grew from 4 to more than 20, owned across four teams—spam, fraud, compliance, and brand—and every new detector required changing that company-wide orchestrator, with schedules dragging out further and further, while the orchestrator also became the single point every piece of content had to pass through. The second version switched to Choreography: a content event bus was built, every detection agent subscribed to content.received, reacted in parallel on its own, and emitted events such as flag.spam / flag.fraud; a policy agent subscribed to the various flag events and synthesized them; an escalation agent subscribed to high-risk events and emitted case.opened. Bringing on a new deepfake detector only required subscribing it to the bus, with no other agent changing a line, and the four teams iterated their own agents without blocking one another.

The cost was acknowledged honestly: they first filled in observability, with every event forced to carry a correlation ID and replayable along the full chain per case, because otherwise emergent behavior cannot be investigated at all; and in the final segment of "is the case fully resolved," they kept a thin orchestrated saga to define the completion state, because pure Choreography cannot answer "is this case closed." This is the most common form in production—choreography-led, with a thin orchestration kept at the critical convergence point, a hybrid rather than either-or. Among today's mainstream frameworks, AutoGen refactored its runtime into an event-driven actor model in version 0.4, which is one of the implementations closest to mainstream engineering for this choreographic tendency; the A2A protocol (donated to the Linux Foundation) is also steering multi-agent interoperability in an event-driven direction.

Relationship to other patterns

• Observability (G5): a hard prerequisite dependency. Choreography has no central trace and relies entirely on correlation-ID event logs to trace causality. Without G5, Choreography is undebuggable and cannot go to production.
• Orchestrate (scattered across Hierarchy / Governance): a pair of twins, each other's opposite. Orchestrate is coordinated by a conductor with centralized control; Choreography is coordinated by events with distributed control. Production systems are mostly a mix of the two rather than pure-bred.
• Fan-out/gather (C2): similar in form, different in spirit. Fan-out has a center responsible for fan-out and gather; workers run in parallel but must return to the center to converge. Choreography has no such center; reaction results enter the event stream directly. Fan-out is parallelism with a center; Choreography is collaboration without a center.
• Failure journal (Memory module M4): event sourcing is Choreography's echo in the Memory row—recording state changes as an immutable event stream, the same in essence.
• Blast-radius control (G2) / Approval gate (G1): naturally at odds with Choreography. For chains that need strong governance constraints, either keep a thin central gate or do not use Choreography in that segment.

What this pattern teaches

Choreography looks like "removing the conductor from Orchestrate," but in essence it devolves the control of collaboration from a single center into each agent's local rules—the baton is replaced by the event stream, and the whole dance forms its figures out of each agent moving on its own without a master score. It gives you resilience and decoupling, and what it asks of you in return is observability and respect for emergent behavior.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.