DM Explains · No. 005 · Agents
Agent choreography: why some multi-agent AI systems have no boss
Agents that react to shared events instead of taking orders scale better and debug worse. Here's how the pattern works and when it earns its keep.
· 13 min read
Read me first
Agent choreography genuinely does let AI systems scale past the point where a central controller chokes, but only when the events are well-defined and someone builds proper tracing — otherwise you've swapped a slow bottleneck for an invisible one.
Illustrative: a new ERP domain agent is added by writing one class and subscribing it to the event bus — 1 order-placed event published → 2 ERP agent reacts without anyone editing a graph → 3 lexical match fails, semantic search via Qdrant hits, LLM confirms → 4 a circuit breaker trips when ERP is overloaded → 5 a regex + classifier firewall screens the reply → 6 Pact-style rules define each agent's utility and choice — extending the system took one class, not one workflow edit.
A company has chained a dozen specialist AI agents into one pipeline: one researches, one drafts, one checks compliance, one files the result. Every request funnels through a single orchestrator node that calls each agent in turn, waits for the answer, and calls the next.
That works fine until traffic spikes. Then the one orchestrator becomes the queue everyone waits behind, and adding a thirteenth agent means editing the same fragile workflow graph everyone else depends on. Agent choreography is the alternative: instead of a controller giving orders, agents watch a shared stream of events and act when something relevant appears. Nobody is in charge, and that is either the whole point or the whole problem, depending on what you're building.
Everyday picture. Instead of Amma standing in the kitchen doorway telling each family member exactly when to lay the table, fetch water, or answer the gate, everyone simply listens for the smell of food and the clatter of plates, and does their part when they notice it — until Bruno barks at the gate and both Arjun and Papa go to check, and nobody afterwards is sure whether one of them was needed at all.
Where the picture breaks. A real household eventually notices duplicated effort at dinner-table conversation; distributed software needs dedicated tracing tools to catch this, and many choreographed systems don't have them by default.
Why it exists now
The problem is old: chaining agents through a single controller creates a bottleneck and a single point of failure, and every new capability means editing that controller's logic. What's new is a wave of open-source projects and formal research through 2025 and 2026 treating "no boss" coordination as a named, buildable pattern rather than an accident. The ai-orchestrator-choreography project and the now-paused underpass-choreographer both published event-driven architectures explicitly contrasted with central orchestrators like LangGraph or AutoGen. At the same time, academic work formalised the idea: the Pact choreographic language paper gives designers a way to reason about agents with their own goals, and the Prompt Choreography paper, published in the Transactions of the Association for Computational Linguistics in 2026, reports concrete latency gains from sharing computation across a choreographed workflow. Open-source releases plus peer-reviewed formalisation, arriving together, is why "agent choreography" is now discussed as its own architecture pattern rather than a workaround.
How it works
Publish and move on
Nobody is told; something is announced.
What it is. An agent finishes a unit of work — research done, document drafted, check passed — and publishes an event describing what happened onto a shared message bus, without naming any specific agent to receive it.
Why it exists. Decoupling the sender from the receiver is what lets agents be added, removed or rescaled without editing anyone else's code.
Where it breaks. If the event schema is vague or inconsistent — "done" instead of "research completed, topic: X" — downstream agents simply never notice the announcement.
How that's handled. Event types and payload shapes get treated as a contract, versioned and tested, the same way an API would be.
In technical terms
In technical terms: choreographic programming is designed to guarantee that programs built this way are correct by construction and deadlock-free — a property that holds for the formal model, not automatically for whatever schema a team actually ships.
Subscribe and react
Control flow emerges; nobody wrote the plot.
What it is. Other agents subscribe to specific event types; when a matching event appears on the bus, a subscribed agent picks it up on its own and performs its task.
Why it exists. This replaces an orchestrator's explicit sequencing logic — "call agent A, then B, then C" — with control flow that emerges from who happens to be listening.
Where it breaks. Two agents can subscribe to the same event and both act, or none can, and there is no controller keeping score of which happened.
How that's handled. Teams building this pattern describe it as decentralised coordination: agents react to events and coordinate without a central controller, which scales well but shifts the burden of tracing outcomes onto observability tooling rather than a single log.
In technical terms
In technical terms: subscription-based reaction is the mechanism that turns a message bus into a coordination layer — the bus carries data, the subscriptions decide behaviour.
Route cheaply first
Ask the cheap question before the expensive one.
What it is. Incoming requests are matched to the right domain agent through a layered cascade: cheap lexical matching first, then semantic vector search, then a large language model (LLM) call only if the cheaper layers fail.
Why it exists. Every fallback to an LLM call costs latency and money; routing decisions that a keyword match or a vector search can resolve don't need one.
Where it breaks. Poorly tuned lexical rules push too much traffic into the expensive LLM layer, eroding exactly the cost savings the cascade exists to deliver.
How that's handled. The routing cascade is monitored on its own — how much traffic each layer resolves — the same way retrieval quality gets measured separately from generation quality elsewhere.
In technical terms
In technical terms: the ai-orchestrator-choreography project routes requests through a three-layer cascade — lexical matching, then semantic search via the vector database Qdrant, then an LLM call — as a content-based router pattern.
Catch the failures
Nothing tracks the whole; everything must protect itself.
What it is. Circuit breakers stop calls to overloaded downstream services before they cascade into a wider outage, and dead-letter agents capture events that failed to process so they can be retried or inspected later.
Why it exists. Without a central controller tracking overall state, resilience has to be built into the event fabric itself, or failures simply vanish.
Where it breaks. These patterns catch failed calls, not silent ones — an event that nobody subscribed to fails invisibly, with no error to trap.
How that's handled. Some teams add health-check events specifically to confirm that expected subscribers are still listening, rather than only checking for errors.
In technical terms
In technical terms: the ai-orchestrator-choreography project uses a circuit-breaker pattern to protect domain microservices from overload, paired with dead-letter handling for unprocessed events.
Screen every message
Any agent can hear anything, so everything gets checked.
What it is. Messages crossing the bus pass through a prompt firewall combining regex rules and a language-model classifier for injection attempts, before any agent is allowed to act on them.
Why it exists. Because any agent can react to any event, there is no single trusted gate to enforce permissions at — screening has to happen at the message itself.
Where it breaks. A firewall applied at every hop adds latency to every message, and a classifier can still miss injection phrasing it wasn't trained to catch.
How that's handled. Firewall rules and classifier training get reviewed and updated as new attack patterns surface, the way spam filtering is never treated as finished.
In technical terms
In technical terms: the ai-orchestrator-choreography project implements a prompt firewall combining regex rules with a BERTimbau classifier for injection detection at the message layer.
Formalise the game
When agents have their own goals, write down the rules.
What it is. Choreographic languages such as Pact let designers specify explicit agent choices, explicit utilities, and priors about the world (called "nature variables"), so a protocol maps unambiguously to a formal game that can be analysed.
Why it exists. Real multi-agent ecosystems involve agents with different, sometimes competing goals — reasoning about that requires more than tracking message order.
Where it breaks. Formal games need real numbers for utilities and priors; guessing them wrong makes the analysis precise but wrong.
How that's handled. Formal analysis is treated as a design-time check, not a runtime guarantee — it tells you whether the protocol can misbehave, not whether the deployed system will.
In technical terms
In technical terms: the Pact paper adds three constructs to choreographic programming for agentic coordination — explicit agent choices, explicit agent utilities, and nature variables — so every protocol maps to a formal game.
Compared with what came before
| Central orchestration | Agent choreography | |
|---|---|---|
| Who decides the next step | One controller, explicitly | Whichever agent is subscribed to the event |
| Adding a new agent | Edit the central workflow graph | Write one agent, subscribe it to an event |
| Scaling under load | Scale the controller and its callees together | Scale each agent type independently |
| Debugging a failure | Trace one execution graph | Trace who published, who consumed, who didn't |
| Auditability | Every step logged by the controller | Emergent; needs dedicated tracing tooling |
The judgement isn't that one replaces the other. A 2026 guide on agentic orchestration notes that real systems often combine both, mixing event-driven orchestrators, supervisor agents and decentralised swarms in the same deployment, according to Tembo. Choreography buys independent scaling and cheap extension; it spends that gain on traceability, and whether that's a fair trade depends entirely on what happens when something goes wrong.
Where it breaks
Choreography earns its keep when a system is high-throughput and loosely coupled, and it costs the most exactly when auditability matters most — which is why the trade is conditional, not absolute.
Not built for regulated audit trails
A practitioner writing about multi-agent orchestration patterns reports that financial services uses centralised orchestration almost exclusively, because rollback capability and full auditability of every step matter more there than agent autonomy, according to gallon.me. Choreography doesn't remove the need for that kind of record — it just makes assembling one harder, because no single component saw the whole sequence.
The same source describes choreography's decentralised design as scaling well and making it easy to add agents, but calls debugging "brutal" without strong observability: without dedicated tracing, it becomes genuinely hard to tell which agent failed to publish an event, whether an event was consumed at all, or whether it was consumed twice. That last failure mode — duplicate consumption — is quietly expensive: two agents both acting on the same event can mean duplicated work, conflicting writes, or a customer getting two responses instead of one, and there is no controller positioned to notice.
Cost and latency risks sit at the routing and screening layers rather than in the bus itself. A cascade that leans too hard on its LLM fallback layer, or a prompt firewall applied at every hop, both add real overhead per message, and that overhead compounds across a system with many small agents rather than a few large calls.
Numbers to carry
| Figure | What it means |
|---|---|
| 2.0 to 6.2× faster time-to-first-token | Speedup reported for Prompt Choreography's shared key-value cache across LLM workflow calls, per the TACL 2026 paper |
| Up to 2.2× end-to-end speedup | Reported for workflows dominated by redundant computation, same paper |
| Three-layer routing cascade | Lexical match → semantic vector search (Qdrant) → LLM call, as implemented in the ai-orchestrator-choreography project |
| Propose → peer-critique → revise → validate → score → winner | The structured deliberation sequence run as an event-driven coordination plane by underpass-choreographer |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Choreography means no rules at all." | Choreographic languages like Pact formalise explicit agent choices and utilities precisely so behaviour can still be reasoned about, per the Pact paper. |
| "Removing the orchestrator removes the bottleneck problem entirely." | It moves scaling flexibility to individual agents, but debugging and tracing get harder without strong observability, per gallon.me. |
| "Prompt Choreography and agent choreography are the same idea." | Prompt Choreography is a technique for sharing transformer key-value cache across LLM calls to cut latency; it shares a name with the coordination pattern but not the mechanism. |
| "Production systems pick one pattern and stick with it." | Real deployments often mix event-driven orchestration, supervisor agents and decentralised swarms in the same system, per Tembo. |
Worked example
The running example: adding a new ERP domain agent to a live choreographed system, versus adding it under a central orchestrator.
- The engineer writes one class implementing the new ERP agent's task logic — nothing about the rest of the system needs to change.
- The engineer subscribes that class to the event type it should react to on the shared bus, for instance "purchase order flagged".
- The event bus starts delivering matching events to the new agent as soon as it's live, with no change to any other agent's code or to a central workflow graph.
- The new agent picks up an event, does its work, and publishes its own completion event — say, "ERP request resolved" — for whatever else might be listening.
- Illustrative, not measured: under a central orchestrator, the same addition would mean editing the controller's call graph, redeploying it, and re-testing every existing path that graph touches, because the controller is the one place that knows the full sequence.
- The team now depends on tracing tools to confirm the new agent actually consumed events and didn't silently overlap with an existing one — the cost choreography charges for skipping step five.
Should you use it?
Choreography fits high-throughput, loosely coupled workloads where different agent types need to scale independently, and where new capabilities get added often enough that a central workflow graph becomes the thing everyone's afraid to touch. It doesn't fit small, simple pipelines where one orchestrator isn't actually a bottleneck, regulated workflows where rollback and full auditability outweigh flexibility, or any team without the observability tooling to answer "who consumed this event, and did they consume it twice."
The cheapest first experiment: take one existing orchestrator-driven step, replace it with an agent that publishes and subscribes to a single well-defined event type, and run both paths side by side long enough to see whether tracing the choreographed path is actually harder in practice — before betting the whole pipeline on it.
Say it in the room
"Use it when agents need to scale independently and new ones get added often; skip it when every step needs to be provably auditable and nobody's built the tracing for the alternative yet."
Lines to carry
- "Removing the boss doesn't remove the work — it moves the work into the wiring."
- "Easy to extend, hard to trace."
- "Ask the cheap question before the expensive one."
- "When nobody is in charge, everybody has to defend themselves."
- "The librarian who tracks everything can become the queue everyone waits behind."
- "Two agents answering the same bark is a cost, not a feature."
FAQ
Is agent choreography just a fancy name for a message queue?
No. A message queue moves messages from one place to another; choreography adds the assumption that agents subscribing to those messages make their own autonomous decisions about what to do with them, rather than just passing data along a fixed pipeline.
Does choreography mean agents have no rules at all?
Not in the formal versions. Languages like Pact require designers to write down explicit agent choices, utilities and priors, turning a protocol into something that maps to an analysable game — the rules are just distributed across agents rather than enforced by one controller.
Can I mix choreography with a central orchestrator?
Yes, and many real systems do exactly that — combining event-driven orchestration, supervisor agents and decentralised swarms depending on which part of the pipeline needs which property, according to Tembo's 2026 guide.
Why is debugging harder in a choreographed system?
Because no single component sees the whole sequence. Tracing which agent failed to publish an event, or whether an event was consumed once, twice, or not at all, requires dedicated observability tooling that many choreographed systems don't build by default.
Is "Prompt Choreography" the same thing as agent choreography?
No, despite the shared name. Prompt Choreography is a technique for sharing a transformer's key-value cache across calls within an LLM workflow to cut latency — a performance optimisation, not a multi-agent coordination pattern.
Glossary
- Choreography — a coordination pattern where autonomous agents react to events on a shared bus, with no central controller directing them.
- Orchestration — a coordination pattern where a central controller explicitly calls and sequences each agent's actions.
- Event bus / message bus — a shared communication channel where agents publish events and other agents subscribe to receive them.
- Dead-letter queue/agent — a mechanism that captures messages or events that failed to process so they can be inspected or retried.
- Circuit breaker — a resilience pattern that stops calls to a failing service temporarily, preventing cascading failures.
- Content-based router — a component that decides which agent should handle a request based on the content of that request.
- KV cache (key-value cache) — stored intermediate computations from a transformer model that can be reused to avoid recomputing them, speeding up later calls.
- Prompt injection — an attack where malicious text embedded in input tries to make an AI system ignore its instructions or perform unintended actions.
- LLM-as-judge — using a large language model to evaluate the quality of another agent's output before it is used or shown.
Sources
- roanbrasil/ai-orchestrator-choreography — GitHub
- What Is Agentic Orchestration? A 2026 Guide — Tembo, 2026
- Pact: A Choreographic Language for Agentic Ecosystems — arXiv
- underpass-ai/underpass-choreographer — GitHub
- Accelerating Language Model Workflows with Prompt Choreography — Transactions of the Association for Computational Linguistics (TACL), 2026
- Your Multi-Agent System Isn't Failing Because of the AI — gallon.me