You probably don't need a multi-agent orchestrator

There's a moment in every enterprise AI build where the architecture diagram gets exciting: a planner agent on top, a router below it, five specialist sub-agents fanning out, arrows everywhere. I've built that system. It demoed wonderfully. And almost everything that made our products actually get adopted came from deleting it.

This is a pattern note about where the leverage really is in agentic systems, written for anyone currently sketching that diagram.

The hop problem

Every hand-off between agents costs you three ways, and the costs compound:

Latency multiplies. Each hop is a full model round trip. Five hops at a few seconds each and your "assistant" takes half a minute to say anything. Users don't experience that as intelligence; they experience it as a spinner.

Reliability decays exponentially. If each step is 95% reliable, a six-hop chain is ~74% reliable. No single step feels broken, but the system is.

Debugging complexity grows nonlinearly. A wrong answer at the end of a DAG of agents could have gone wrong at any node, in any prompt, with any intermediate artifact. Tracing one bad output through six agent contexts at 2am is an experience that converts architects into minimalists.

What actually moved adoption

When we looked at what made consultants and clients keep using our tools daily, none of it was orchestration cleverness:

• Tool quality and contracts. Typed inputs, validated against data that exists; deterministic, exportable outputs. A mediocre model with great tools beats a clever multi-agent system with vague ones.
• Evidence and replayability. Users trusted outputs they could trace, export to Excel, and re-run.
• Failure visibility. When something broke, the system could say what and where, because the workflow was a state machine, not a conversation between agents.

Meanwhile, the models' native tool-calling kept improving underneath us. The orchestration layer we'd built to compensate for model weakness became pure overhead once the model could reliably chain tool calls itself. A single capable agent with a well-designed toolbox quietly outperformed the planner-router-specialist ensemble.

The pattern: invest in the harness, ship per use case

The alternative to orchestrator-first is what I'd call harness-first:

1. Pick one use case with real user pull: someone who needs the answer this week.
2. Spend your engineering budget below the agent: clean ETL, schemas and contracts, typed tool interfaces, retrieval that observes real data, deterministic exports, observability.
3. Give one agent the whole toolbox. Let the model do the orchestrating; that's the part it's genuinely good at now.
4. Only extract shared infrastructure after the second or third use case proves what's actually shared. Consolidate primitives into a thin spine; resist building the platform before the products.

A note on the build-vs-buy version of this: enterprise assistant builders (custom GPTs and friends) hand you the top of the stack free: strong models, code execution, API actions. What they can't give you is the bottom: your data contracts, your tool quality, your evals, your exports. That's the moat and the work. Same conclusion from a different direction: the harness is the product.

When you do need real orchestration

Long-horizon background jobs. Fan-out over thousands of items. Human approval gates mid-workflow. Genuinely parallel work streams. And when you hit those, reach for boring technology first: queues, state machines, checkpointed jobs with resumable state. We run massive daily pipelines exactly that way. The orchestration that scales is the kind that looks like infrastructure, not the kind that looks like a committee of chatbots.

The one-line version

Agent cleverness is a depreciating asset; the models absorb it release by release. Tool contracts, data quality, and reliability engineering appreciate. Build where the value compounds.