Concepts
What is multi-agent orchestration?
Multi-agent orchestration is coordinating several agents so they hand work to each other, instead of asking one agent to do a whole job. Each agent gets a narrow role; the orchestration decides the order and how results flow between them.
The reason to bother is not capability, it is diagnosis. When one prompt doing four things goes wrong, you cannot tell which of the four broke. Four agents doing one thing each produce four step rows, and one of them is wrong.
I built this engine, so read the enthusiasm accordingly — but the failure at the bottom is one I shipped.
The shapes, and what each is actually for
| Shape | What it does | Reach for it when | Plan |
|---|---|---|---|
| Sequential | One step after another, passing results | Almost always. Start here | Free |
| Parallel | Several steps at once | The steps do not depend on each other and latency matters | Pro |
| Conditional | Branch on a result | Two cases genuinely diverge | Pro |
| Fan-out | Split work across many, then combine | You have a list and each item needs the same treatment | Pro |
| Loop | Repeat until a condition or an iteration cap | The work is iterative rather than a fixed list | Pro |
| Dependency graph | Each step waits for the steps it names | The order is a real dependency, not just how you typed it | Pro |
A dependency graph is not an option in the execution-mode dropdown. You build one by giving individual steps a depends_on list, and the engine works out what can run when. Looking for a "DAG" mode and not finding one is a confusion worth saving you.
How agents hand work over
By default a step receives the previous step’s text. That is fine for a chain of prose and useless for a branch, because a condition cannot reliably read a sentence. Turn on structured JSON output on any agent whose result a later step must inspect, and later steps and conditions can read its fields by name.
Not every step needs an agent. Condition, Delay and Transform are built in, never call a model, and therefore cost nothing in tokens — reshaping data with a Transform beats asking an agent to reformat something on both price and predictability.
What it costs to split a job up
Each agent step spends tokens, so more steps cost more. A two-step worked support example comes to $0.0144 at our real rates; a real logged support run with a third, escalation step came to $0.0204. Source: two runs costed step by step, no account needed.
That is the trade: splitting a job into focused agents costs a little more and makes failure findable. At these numbers the diagnosis is worth more than the fraction of a cent.
The failure orchestration introduces
A branch that can never match
A condition that never matches is not an error. The branch is skipped, the run finishes as COMPLETED, and nothing says so. Source: 27 of my own branches did this for weeks. A skipped step now writes its own row with a reason — but you only see it if you read the step rows.
A cascade of honest successes
One step that quietly returns nothing hands nothing downstream, and every later step succeeds against it, because each really did its job on what it was given. The rot starts further up than the symptom.
Too many agents
Splitting has a cost in tokens, latency and things to maintain. Split where you would want a separate step row when something breaks, and not further.
Next
- Build one — see Build a multi-agent workflow.
- Understand a single agent first — see What is an AI agent?