AI Glossary / Graphs and symbolic AI / Intermediate

Choreography

Definition

Choreography is a description or coordination pattern for how multiple participants interact through messages and agreed behavior. In service-oriented systems, it gives a shared view of exchanges among services rather than describing only one participant's internal process. The idea also helps explain interactions among AI agents, tools, and other services in a larger workflow.

What it means

A choreography identifies roles, expected messages, and the conditions or ordering of their exchanges. Each participant can have its own internal implementation while conforming to the shared interaction contract. This makes the boundaries between participants explicit.
The term is often contrasted with orchestration, where one participant's process directs calls to others. The distinction concerns the perspective and coordination model; it does not require a claim that a choreographed system has no shared infrastructure. Message brokers, monitoring services, and locally orchestrated processes can still exist within an overall choreography.

How it works

Define the participating roles and the messages they exchange. Specify when messages may be sent, what they mean, how they correlate to the same business instance, and what should happen after success or failure. Implement each participant's behavior so its outgoing and incoming interactions fit the contract.
In an event-driven realization, a participant may react to an event and publish a result that another participant consumes. That is one implementation style, not the entire definition. Correct coordination also needs handling for repeated, delayed, missing, or out-of-order messages. A diagram of the intended happy path does not automatically establish that the distributed implementation follows it.

Three practical examples

• An order service, stock service, and dispatch service exchange events according to an agreed order-fulfillment interaction.
• A document workflow lets extraction, validation, and review services communicate through clearly defined messages while retaining their separate responsibilities.
• A multi-agent application specifies which role may request evidence, return an analysis, or authorize a next step, without assuming that free-form conversation alone defines a reliable process.

Think of it this way

Think of musicians following a shared score while each plays a distinct part. Their parts must fit together, even though no player performs every action. The analogy is limited because distributed services cannot rely on shared timing, perfect hearing, or an implicit understanding of mistakes. Their message and failure behavior must be defined explicitly.

Worked example

Consider a fictional three-role process: Request, Stock, and Dispatch. Request publishes OrderAccepted with order identifier 42. Stock receives it, reserves the items, and publishes StockReserved for the same identifier. Dispatch creates a shipment only after receiving that reservation event.
If OrderAccepted is delivered twice, Stock must not reserve twice merely because two copies arrived. A design can record that reservation for order 42 has already been completed and return the existing result. If Stock instead publishes StockUnavailable, Dispatch must not interpret that as permission to ship. The two outcomes are distinct branches of the interaction contract. This example shows why correlation and repeat handling are part of coordination. It does not claim that message delivery is exactly once or that the three steps form one atomic transaction.

Illustrative case study

At fictional Juniper Documents, independent services extract fields, validate them, and request human review when needed. The team initially relies on informal assumptions about which message arrives first. A delayed validation result reveals that one service can act on an incomplete record.
The team writes explicit allowed transitions and identifies the evidence required before the next role proceeds. This fictional case illustrates improving an interaction contract. It does not claim that choosing choreography automatically reduces coupling, guarantees scalability, or eliminates the need for a responsible process owner.

Common misconceptions and mistakes

Choreography is not merely several services communicating. Their interactions need meaningful rules if the term is used as a design model. It is also not synonymous with an event bus; a bus transports messages but does not by itself define correct business behavior.
The absence of one central workflow controller does not remove coordination complexity. Failures can leave participants with different views of progress. Nor does a choreography specification automatically prove each implementation conforms to it. Finally, AI agents participating in a choreography still need defined permissions and validated message content; conversational fluency does not make an interaction contract reliable.

Business use

Businesses can use choreography to clarify responsibilities across services or organizational boundaries. The practical review should identify who owns each outcome, how progress is observed, and how a stalled or inconsistent instance is repaired. Changes to a message contract need coordination with its consumers. For AI workflows, separate a model's proposed action from the event that authorizes execution, so uncertain content does not silently become process authority.

People also ask

Does choreography require no central infrastructure?

No. Shared messaging and monitoring can support it; the concept concerns participant interactions and their shared contract.

Is every event-driven system choreographed correctly?

No. Events alone do not specify valid ordering, outcomes, or failure handling.

Can choreography and orchestration coexist?

Yes. A participant can internally orchestrate its work while taking part in a broader choreographed exchange.

Check your understanding

A dispatch service receives an order-accepted event before stock is reserved. If the contract requires StockReserved before shipment, may it ship immediately?

Answer: No. Receiving an earlier event does not satisfy the required reservation condition.

Related terms

• Orchestration
• service-oriented architecture
• event-driven architecture
• message contract
• distributed workflow
• correlation identifier
• idempotency

Learn next

Draw the worked interaction with a separate line for each role and label success, failure, and repeated-message cases. Then identify who can determine that the overall process is complete. This exposes coordination gaps that a simple sequence of service names would hide.

More in Graphs and symbolic AI

• Characters - Characters are the written-text elements that a system represents and processes, such as letters, digits, punctuation, and other symbols.
• Child node - A child node is a node directly below another node, its parent, in a rooted tree.
• Chordal - Chordal describes an undirected graph in which every cycle of four or more vertices has a chord: an edge connecting two vertices that are not consecutive on...
• Chronological backtracking - Chronological backtracking is a search method that responds to a dead end by undoing the most recent decision that still has an untried alternative.
• Circuit verification - Circuit verification checks whether a circuit design satisfies a stated specification.
• Circumscription - Circumscription is a formal approach to nonmonotonic reasoning that prefers models in which selected properties hold for as few entities as possible...

Sources

Sources: W3C, original Web Services Choreography Requirements: https://www.w3.org/TR/ws-chor-reqs/ . W3C, Web Services Architecture: https://www.w3.org/TR/ws-arch/ . OASIS, WS-BPEL FAQ on orchestration and choreography: https://www.oasis-open.org/committees/wsbpel/faq.php .

Previous: Chordal Next: Chow - Liu tree