Cost and Complexity Tradeoffs

Multi-agent systems are powerful, but they are not free, and they are not the default. Every agent you add multiplies cost, latency, and the number of ways the system can break. This lesson is the honest counterweight to the previous three: when multi-agent is overkill, and how to justify it when it isn't.

Balance diagram weighing a single cheap model call against a multi-agent committee whose cost, latency, and failure connections multiply.

Every agent multiplies the bill

A single call costs some tokens. A multi-agent system pays for each agent's full context — orchestrator, every worker, every verifier — plus the tokens spent passing results between them. A five-agent fan-out can cost five-to-ten times a single call, and verification or voting multiplies that again. The three axes that grow with agent count:

Token cost — more agents, more context per agent, more inter-agent messages.
Latency — sequential stages add up; even parallel fan-out is bounded by its slowest worker plus a synthesis step.
Failure modes — every agent can time out, hallucinate, or misread its handoff, and the orchestration logic between them can fail on its own.

A system with five agents has far more than five times the failure surface of one call, because the interactions between agents are themselves a source of bugs.

Justify it by the task, not the trend

The right question is never "could this be multi-agent?" — almost anything could. It's "does this task's shape require it?" Reach for multiple agents only when you have a concrete reason from Lesson 1: genuine independent parallelism, a context window that won't fit the input, or roles distinct enough that one prompt can't hold them. If none of those apply, multi-agent is added cost and complexity buying nothing. Sophistication is not a goal; a solved problem is.

A single call often wins

For a large share of real tasks — extraction, classification, grounded Q&A, summarizing one document — a single well-prompted call with structured output beats a committee. It's cheaper, faster, easier to test, and easier to debug when it misbehaves. Before building an orchestrator, try the boring version: one focused prompt, low temperature, a validated schema. Often that is the whole answer, and the multi-agent design was a solution in search of a problem.

Start simple, escalate on evidence

The disciplined path is to start with one call and add agents only when you can point to where it fails. Measure first: if the single call is too slow because of independent work, fan out. If it's unreliable on expensive output, add a verifier. If it can't fit the input, add a map step. Let each agent earn its place by fixing an observed problem — not by appearing on an architecture diagram. That keeps the system as small as the task allows, which is exactly as small as it should be.