One orchestrator, many hands: multi-agent systems that ship

There's a demo making the rounds — you've seen a version of it. A little society of AI agents: a CEO-agent sets strategy, a PM-agent writes tickets, developer-agents discuss implementation, a QA-agent reviews. They confer in eloquent natural language. The transcript reads like a company that finally achieved perfect communication. The room applauds.

Then someone tries to run it on real work, and the society politely, verbosely, expensively falls apart.

The position of this essay: multi-agent systems ship when they're built like distributed systems, and die when they're built like little companies. The pattern that survives production is unglamorous: one orchestrator with actual authority, many narrow hands, typed handoffs, a deterministic spine. Everything else currently sold as "multi-agent" is mostly theatre — impressive in exactly the way and for exactly the duration a demo requires. We've written about that gap before in The demo-to-production chasm; this is the chapter about what to build instead.

Multi-agent theatre, diagnosed

Why does the agent-society pattern collapse outside the demo? Four mechanical reasons — no philosophy required:

• Errors compound per hop. Chain probabilistic components through natural language and the noise multiplies. A per-message accuracy that feels high becomes a coin flip after enough hops — and agent societies love hops; deliberation is their aesthetic.
• Natural language is a terrible wire format. When agent A tells agent B "the client seems flexible on the timeline", what precisely does B now know? Chat between agents is ambiguity, serialized. Every message needs interpretation, and every interpretation is a fresh chance to drift.
• Cost explodes quadratically-ish. Every internal "meeting" burns tokens. The theatre troupe deliberates its way through your budget before touching the actual task.
• Nobody owns state. When five agents each hold a partial, possibly contradictory picture in their context windows, the system's "current truth" is a rumor distributed across amnesiacs. When it fails at 2 a.m., there is no log line that says what the system believed — there are transcripts, and you will read them like tea leaves.

The tell is the diagram. If the architecture slide looks like an org chart, you've built a company — including its meetings, its misunderstandings, and its payroll, just denominated in tokens.

The pattern that ships

What survives contact with production looks less like a society and more like a well-run kitchen: one chef, many stations, tickets on rails.

One orchestrator, with authority. A single component plans the work, routes tasks, owns the state, judges results, retries failures, and decides when humans enter. It's the only part of the system entitled to an opinion about the whole. It might be an LLM with a plan; it might be — better, whenever possible — a deterministic workflow engine that calls LLMs for the judgment-shaped steps.

Many hands, each narrow. Workers do one thing: extract fields from this document, draft this section, validate this claim against this source, format this output for this channel. Narrow scope, tight context, individually testable — a hand, not a colleague. The productive mental model is a function with a mind, and functions have signatures.

Typed handoffs, not conversations. Hands receive structured input and return structured output — schemas, not prose. {claim, source, verdict, confidence} can be validated, logged, diffed, and retried. "I think this mostly checks out!" cannot. Every interface where you replace chat with types deletes a whole species of failure.

A deterministic spine. Under it all: queues, retries, timeouts, idempotency keys, dead-letter lanes — boring workflow engineering, the kind that was mature before LLMs arrived. Intelligence is expensive and probabilistic; plumbing is cheap and certain. Spend the intelligence only where judgment lives, and let code be code — the argument we've made flatly in Determinism is a feature.

Four rules fall out of this shape:

1. Single writer of state. The orchestrator alone updates the record of where things stand. Everyone else returns results and goes home.
2. Contracts, not chat. If two components exchange natural language, one of them is about to be misunderstood.
3. Hands may fail; the orchestration must not. Any worker can time out, hallucinate, or return garbage — and the system should shrug: validate, retry, reroute, or escalate. Fragility at the edges, never at the center.
4. Humans are a node, not an afterthought. Approval gates are first-class steps in the graph — placed where risk lives, with everything the human needs to decide in one glance.

Agents should coordinate like functions, not like coworkers. Save the meetings for the humans.

When you genuinely need many agents

None of this argues for one-model-does-everything. There are honest engineering reasons to multiply agents — note that every one of them is an engineering reason, not an anthropomorphic one:

• Parallel fan-out. Forty documents to analyze, five suppliers to research — identical narrow tasks, dispatched wide, results merged by the orchestrator. Parallelism is a queue property, not a personality.
• Permission isolation. The hand that touches billing APIs and the hand that reads public docs should be different processes with different credentials — blast-radius design, exactly as you'd separate services.
• Context specialization. A hand with a tight prompt, a small tool set, and one job outperforms a generalist drowning in instructions. Specialization is about focus, not job titles.
• Failure containment. A hallucinating researcher should be quarantined by schema validation at its boundary — one bad hand, one rejected artifact, zero contagion.

The acid test for any proposed agent: could you draw its state machine? If its behaviour can't be sketched as states and transitions — if the answer is "the agents will figure it out among themselves" — you're being sold theatre.

What this looks like in practice

We run this pattern daily, so the examples are ours — honestly described:

Our publishing hub is the diagram made real. One brief enters. The orchestrator plans channels and sequence. A drafting hand writes; a brand-checking hand validates the draft against the brandbook's structured rules; formatting hands shape the result for the blog, LinkedIn, and Facebook; a human approval gate sits before anything ships. The hands never talk to each other — each returns its artifact to the spine and stops. When a step fails, it retries or lands in an error lane with context. The result reads like automation, not improvisation — which is exactly what it is.

Our brandbook-to-website engine splits the same way. Agents work upstream, producing and refining structured brand data. Downstream, a deterministic renderer turns that data into a multi-tenant website — same input, same site, every time. The hands are bounded by types; the delivery path doesn't improvise. That division — judgment upstream, determinism downstream — is the single most reusable idea in our AI systems work.

And the spine is self-hosted n8n for a growing share of our internal flows: queues, retries, webhooks, and escalation lanes we own end to end, with LLM steps embedded as nodes inside an auditable graph — one component of the broader ecosystem we build on. None of it is glamorous. All of it is why things still run when nobody's watching.

Notice what this architecture does to headcount math, incidentally: one senior engineer plus a disciplined orchestration layer operates what would otherwise be a department's worth of coordination. That's the mechanism behind Small teams, big leverage — the leverage lives in the spine.

The buyer's interrogation

If someone pitches you a multi-agent system — vendor, integrator, or us — six questions sort the builders from the troupe:

1. Show me the state diagram. Not the concept slide — the states and transitions.
2. Who owns state? If the answer lists more than one owner, you've found the future incident.
3. What's the retry story? Per step: on failure — retry, reroute, or human? Decided when?
4. What does a run cost at production volume? Theatre is cheap to demo and ruinous to run; a builder knows the number.
5. What happens when hand #3 hallucinates? The answer should involve schemas and quarantine, not "the reviewer agent usually catches it".
6. Where do humans approve? Point to the gates in the graph. "We'll add oversight later" means never.

Mumbles on three or more: you're watching a rehearsal, not a system.

The quiet conclusion

The multi-agent future is real — we build it and bet the company on it. It just doesn't look like the demo. It looks like a kitchen at service: one chef calling the pass, stations executing narrow briefs, tickets moving on rails, nobody holding a meeting about the risotto. The intelligence is everywhere; the authority is in exactly one place.

If you're designing an agent system — or auditing one that deliberates beautifully and ships nothing — talk to us. We'll bring the state diagrams. We actually enjoy drawing them.