A practical framework for deciding between multi-agent and single-agent LLM architectures, drawn from real production experience rebuilding the same system both ways. The author argues that single agents with good tools now handle most tasks better than multi-agent crews, given improved frontier model capabilities in 2026. Multi-agent is only justified in three specific cases: genuinely parallelizable subtasks, tasks requiring distinct specialist knowledge boundaries, and output quality improvement through critic loops. The post details the real costs of multi-agent systems (multiplicative token spend, stacked latency, exponentially harder debugging, multiplied failure modes) and recommends a hybrid pattern where a primary agent delegates to sub-agents only when truly needed. Includes guidance on state management patterns, cost modeling, and a decision framework to apply before reaching for multi-agent architecture.
Table of contents
What People Actually Mean by Multi-AgentThe Single Agent CounterargumentWhat You Pay For Multi-AgentWhen Multi-Agent Is Actually RightWhen Multi-Agent Is The Wrong AnswerA Hybrid That Often WinsMemory and State Across AgentsCost Modeling Before You BuildThe Decision FrameworkSort: