You probably don't need multi-agent

Every quarter a team shows me their agent architecture and it looks like an org chart: a planner agent delegating to a researcher agent reviewed by a critic agent, coordinated by an orchestrator agent. And every quarter I ask the same rude question: what does the second agent do that the first one's next turn couldn't?

The answer is usually "separation of concerns", which is a software architecture concept doing unpaid work in a prompt engineering context. Your agents are not services. They share no state isolation, they fail together, and every hop between them is a full model call that costs real money and adds real latency while mostly reformatting what the previous call already knew.

the bill for the org chart

Count what a five-agent pipeline actually spends. Each handoff re-serializes context into the next agent's prompt: tokens, paid again. Each agent maintains its own instructions: cache surface, multiplied. Each hop adds seconds of latency to a user who wanted an answer. And the failure modes compound: a 20% error rate per stage across five stages is not 20%. The agent-tool-design piece made the core argument already: most "agent roles" are just tools the one agent should call. The critic agent is an eval. The researcher agent is a search tool. The planner agent is the model thinking before acting, which current models do in one turn when you let them.

what the roles actually cost you in debugging

The multi-agent pipeline's worst tax arrives when something breaks. One agent with tools produces one transcript: every decision, every call, one timeline you can read. Five agents produce five interleaved transcripts plus an orchestration layer, and "why did it answer that" becomes a distributed tracing problem you built voluntarily. I have watched a team spend a sprint adding correlation IDs to their own prompt pipeline. Correlation IDs. For prompts. Nobody stopped to ask whether the architecture was the bug.

the honest exceptions

Multi-agent earns its complexity in exactly three cases I have seen hold up. Genuinely parallel work: fan out fifty independent research tasks, fan in results; that is a job queue wearing agent vocabulary and it is fine. Privilege separation: an agent with production credentials taking instructions from an agent that reads untrusted input is a real security boundary, not an org chart (the sandboxing writeup covers why). And context budget overflow: when one task's working set truly exceeds a context window, splitting by subtask beats truncating, though check the window sizes shipping this year before assuming yours overflows.

Notice what is not on the list: quality. "The critic agent catches the writer agent's mistakes" describes an eval loop you could run cheaper as a second pass with different instructions, same model, same context, no serialization tax. Run the A/B before believing the org chart improved anything. Mine came back flat, twice, and the pipeline was five times the cost.

do this instead

One agent. Good tools with crisp contracts. A real eval harness so quality regressions surface as numbers instead of vibes. Thinking budget spent where the model needs it, not on inter-agent diplomacy. Then, if a measured constraint (parallelism, privilege, context) actually binds, add the second agent for that constraint, and write down which one it was so the next architect knows what to delete when the constraint moves.

The diagram below shows the before and after of the last pipeline I helped collapse: five agents to one, same evals, 41% cheaper, three seconds faster. The org chart was the latency. It usually is.