Agent Orchestration: When One Model, When a Crew

Crews are seductive because demos hide the cost

A multi-agent crew is a beautiful thing to watch. A planner decomposes the goal, a researcher gathers context, a writer drafts, a critic reviews, and an orchestrator stitches it together. In a slide it reads like a small organization that never sleeps. In production it reads like a bill. Each hop is a full model call, each call carries the accumulated conversation, and each handoff is a place where the chain can silently derail. The demo hides all of this because the demo runs once, on a happy-path input, with a human watching.

The honest question is not whether you can build a crew. Frameworks make that trivial now. The question is whether the task decomposes into subtasks that are genuinely independent and individually verifiable, because that is the only condition under which the coordination tax pays for itself. Most workflows fail that test. They are one coherent reasoning problem that a single capable model, handed the right tools and context, will solve more cheaply and more reliably than a crew of five talking to each other. The default should be inverted from where most teams set it: assume one model until the task proves it needs more, rather than reaching for a crew and pruning it back. Every agent you add is a new call to pay for, a new place to fail, and a new contract to keep synchronized, so the burden of proof belongs on the crew, not on the single model.

Match the topology to the task, not to the demo

Four topologies cover almost everything teams actually need. The trap is reaching for the most elaborate one by default. Start at the top of this table and move down only when the task forces you to, because every step down multiplies cost and failure surface.

The cost multipliers are not decoration. A crew that runs four sequential agents on a 6,000 token context does not cost four times a single call. Each agent re-reads the growing transcript, so by the fourth hop you may be paying for 18,000 to 24,000 input tokens against an original 6,000 token task. That is where the 5x to 12x range comes from, and it is why a crew that looks elegant on a whiteboard can turn a $0.02 request into a $0.20 one.

Start small and earn every added agent

• Begin every design with a single model plus tools, and only split into agents when you can name a subtask that is independent, individually testable, and expensive enough to justify its own call. If you cannot name it, you do not need it.
• Give each agent a written contract: its inputs, its allowed tools, its output schema, and one job. An agent with a fuzzy remit is a coordination bug waiting to happen, because the next agent cannot rely on what it produces.
• Cap the reasoning depth explicitly. Set a hard limit on planner-to-worker hops, say three, and fail loudly at the ceiling rather than letting an agent loop until it burns the budget or times out at 290 seconds.
• Run agents in parallel wherever the subtasks are genuinely independent. Three researchers fanning out concurrently cost the same wall-clock time as one and cut end-to-end latency from 24 seconds to roughly 8, but only if none depends on another's output.
• Put a cheap deterministic router in front of specialist agents instead of asking a large model to route. A small classifier at 40 to 80 milliseconds and near-zero cost beats a full model call that spends 2 seconds and real money deciding which queue a request belongs in.

The five ways crews quietly fail

• Compounding error across handoffs. If each of five agents is 90 percent reliable, the chain is 0.9 to the fifth, about 59 percent end to end. Fix: verify at each boundary with a cheap check, or collapse the chain so there are fewer boundaries to survive.
• Context bloat on every hop. Agents that re-read the full transcript pay linearly growing input cost. Fix: pass a compact structured summary between agents, not the raw conversation, and strip anything the next agent does not need.
• The critic that always approves. A reviewer agent prompted to check the work tends to rubber-stamp. Fix: give the critic a concrete rubric and require it to cite the specific failing criterion, so approval has to be earned against named tests.
• Silent tool failures. An agent gets a 500 from an API, treats the empty result as truth, and confidently reasons from nothing. Fix: make tool errors first-class outputs the agent must handle, and never let an empty result read as a valid answer.
• Orchestration for a linear task. Wrapping a five-step pipeline in an agent framework buys you nondeterminism you did not want. Fix: if the steps are fixed and ordered, write a plain function with typed steps, not a crew.

Before you ship a crew

• Can you state each agent's job in one sentence, with a typed input and a typed output? If not, merge it back in.
• Have you measured the token cost of the full chain on a real input, not just the first hop, and confirmed the multiplier is worth it?
• Is there a verification step at every handoff, or a documented reason there does not need to be?
• Have you capped reasoning depth and set a hard timeout, so a stuck agent fails loudly instead of draining the budget?
• Did you try the single-model-plus-tools version first and prove it was insufficient, rather than assuming a crew was required?