Multi-agent Orchestration

What it is

The coordination scheme that governs how several agents working toward one objective relate to each other: who may start work, how their outputs combine, who settles disagreement, where the shared budget is enforced, and what declares the objective met. It is the shape of the collaboration as a whole, not any individual selection or transfer that happens inside it.

Why it matters

The topology determines cost, latency, blast radius, and debuggability far more than the quality of any single participant. A supervisor-and-workers arrangement has one bottleneck and one place to look when it misbehaves; an open message bus with agents reacting to each other produces behaviour that no trace will adequately explain. It also deserves scepticism: multiple agents multiply token spend and failure surface, and a sizeable share of production multi-agent designs would be cheaper, faster, and more reliable as one agent with a larger tool set.

How this differs from selection and transfer

Coordination is the scheme; selecting which agent receives a given unit of work is a decision taken within it, and moving an in-flight task from one agent to another is an event inside it. Each can exist without this capability: a product with one agent per request class selects without coordinating anything, and a fixed escalation path transfers work without any selection decision being made. This capability is what exists when several agents must be kept coherent about one objective at the same time.

Key decisions

• The topology: a supervisor delegating to workers, a fixed pipeline of stages, a shared artefact that participants read and amend, a peer network, or an ensemble whose outputs are compared.
• Whether participants communicate by passing messages or by reading and writing a common artefact, and whether messages are addressed or broadcast.
• Who owns the objective and is permitted to declare it met — and whether that is an agent or deterministic code holding a checkable criterion.
• Failure containment: whether a worker's failure fails the objective, is retried in place, or is given to a different participant.
• Where the budget ceiling for the entire effort is enforced, as distinct from any per-agent limit, since the interesting overruns are collective.
• Whether the topology is fixed in code or produced at runtime, which decides whether you can test it before it runs.

Failure modes

• Two participants each conclude the other is responsible for a step; the step is never performed and the coordinator reports success because nothing checked.
• One participant's confident fabrication is cited by the next as established fact, and the error is laundered into the final output with more authority than it started with.
• Spend grows super-linearly because every participant receives the full history, so a three-agent design costs many times a single agent for a marginal quality difference.
• A comparison or debate arrangement converges on the most verbose participant rather than the most correct one, because length reads as thoroughness to the arbiter.
• The coordinator becomes a serialisation point and the whole effort proceeds at the rate of one model call at a time, losing the concurrency that justified the design.
• No ceiling spans the group, so a disagreement between two participants consumes an entire monthly budget overnight without exceeding any individual limit.
• Observability is per participant, so nobody can reconstruct the order in which events happened across the effort or attribute the final answer to a contributor.
• Partial completion cannot be represented: the result is finished or failed, and most of the work done before a late failure is discarded.

Related capabilities

• Agent Graph Engineering — node and transition contracts, including single-agent workflows
• Agent Harness Engineering — execution services around each participant
• Agent Routing — the selection decision made inside this scheme
• Agent Handoff — the transfer event that moves work between participants
• Shared State Management — what participants agree on when they are not messaging
• Parallel Execution — the concurrency scheme a topology permits or forbids
• Termination Conditions — how a collective effort is declared over

Applies: Production readiness · Design questions