In Kirto Flow, a sub-agent is another tool call. A parent agent’s model decides to invoke it, and Flow dispatches that decision the way it dispatches any connector. A later post in this series covers that mechanism. It is orchestration: one participant with a global view decides what runs next. Orchestration is half of how coordination happens in a business process. The other half has no conductor.
Two words, one distinction
Orchestration and choreography are borrowed vocabulary. SOA and microservices circles have argued about the difference for two decades. The two words name different arrangements, and both get used loosely to mean “agents working together”. Orchestration means one participant has the global view. A central process definition knows the whole sequence, and it calls every other participant by name, in order. Choreography means nobody has the global view. Each participant follows its own local rules and reacts to events it observes. The overall behaviour emerges from those local reactions, and no single document writes it down as a sequence.
BPMN is an orchestration notation. A sequenceFlow says exactly what runs after what, and a process definition is the global view by construction. That is why the sub-agent-as-tool pattern is orchestration. The parent’s model is the conductor, and every tool call, including a nested agent:run, is a decision the conductor makes.
Agents already coordinate by choreography
BPMN cannot help with coordination that has no conductor to begin with. A handful of independent agents subscribed to the same event stream, each deciding on its own whether to act on a message, is choreography. It is a real and increasingly common multi-agent pattern. Group chat in CrewAI and AutoGen is a softer version of the same idea. No script says who speaks next, and each agent reacts to whatever the shared conversation holds so far.
Choreography has a real architectural advantage. No single participant is a bottleneck. A reactor can be added or changed without touching anything else listening to the same events. A rigid central conductor has to know about every participant in advance.
The bill comes due at audit time
The same property is the one the agent control plane argument keeps returning to. When no participant has the global view, no participant can produce the reasoning chain a regulator asks for. “What happened and why” is scattered across every independent reactor that was listening. Reconstructing it means correlating their separate logs after the fact, where each one kept a log. Choreography optimises for decoupling by design. Auditability needs the opposite: something that had the whole picture the entire time.
Choreography stays a sound pattern. Most of what is marketed today as multi-agent choreography has no answer to the audit question. The coordination is real, and the audit trail does not exist.
CMMN was choreography before choreography had a name
The CMMN spec solved this over a decade before the current wave of multi-agent framework design. A CMMN case’s plan items do not call each other. Each one has its own sentries: entry and exit criteria that fire on case-file-item events, user events, or another plan item’s state change. A plan item activates when its own sentry says so. Nothing upstream tells it to run next, and nobody in a case is a conductor. That is choreography in structure, whether or not the spec uses the word.
flowchart LR SENTRY["Sentry<br/>case-file event fires"] ITEM["Plan item<br/>reacts locally, no caller"] CASE["One case model<br/>one audit trail"] SENTRY -->|enables| ITEM ITEM -->|state change| CASE CASE -->|next sentry can fire| SENTRY
CMMN adds the second half, which a bare event bus lacks. Every plan item, every sentry and every case-file-item event belongs to one case model. The case’s runtime state is one queryable, auditable thing for the whole life of the case: what is available, enabled, active and completed. A plan item reacts to events and holds no reference to anything else in the case, which is choreography’s decoupling. The case model keeps the property choreography usually costs: something that had the whole picture the entire time.
Two primitives, one substrate
A CMMN case can dispatch a BPMN process as one of its own tasks. In Flow, a CMMN processTask runs a deployed BPMN process through the cross-engine bridge, which exists for this. A choreographed case can hand a sub-problem with a knowable path to an orchestrated process, get an auditable result back, and keep reacting to whatever else the case enables next. Orchestration and choreography are two coordination primitives on the same durable substrate. No project has to commit to one of them at the start. Which one applies is a property of the specific piece of work, and one system can use both.
Where each shape fits
BPMN’s orchestration fits when the path is knowable in advance and the process has an owner. Examples are a loan approval, a claims intake, or anything with a defined sequence a business analyst could draw before the first instance runs. CMMN’s choreography fits when the path is not knowable ahead of time. Examples are an investigation where what comes next depends on what has been discovered so far, or a case where several people act in an order nobody can specify at design time. Forcing BPMN onto the second kind of work leads to the ad-hoc-subprocess and text-annotation workaround. A bare event bus applied to the first kind of work throws away a global view there was no need to give up.
Flow
We did not build a choreography engine to sit next to the orchestration engine. We did not bolt a conductor onto CMMN to make it look more like BPMN. CMMN already had the properties choreography is reinventing: reactive, local, no single caller. It had them alongside one auditable case model, because that is what the standard was for before “agent” meant a piece of software. A later post covers the conductor’s half of coordination. This post covered the other half, and the standards got there first.