Should you build a single agent or a multi-agent system?

In detail

Default to a single agent

A single agent — one agent running the whole task with its tools — is the simplest thing that can work, and it covers a surprising amount of ground. You can read its trace top to bottom, see why it did what it did, and fix it. Many teams reach for multiple agents before they’ve exhausted what one well-built agent can do.

When multiple agents earn their place

The case for splitting up holds when a task breaks into distinct specialties — a researcher, a coder, a reviewer — each needing its own instructions, tools, and context window that would clutter a single prompt. Separating them keeps each agent focused and lets you scale or swap pieces independently. The win is managed complexity and cleaner division of labor. MongoDB’s Mikiko Chandrasekhar describes this as the practice now developing for complex work: rather than one agent trying to do a lot of complex tasks, a system of small agents that each handle one to three tasks, each judged against criteria for its own skill set.

Update, October 3, 2026: Task specialization also appears in episode 73. Wen Sang calls Genspark’s design a “mixture of agents” architecture, describing more than 70 models selected for different tasks and more than 150 in-house tools those models can call. Sang gives planning, coding and media generation as examples of different model strengths. For the architecture choice discussed here, the distinction is between selecting models for tasks and assigning independent agents separate responsibilities; the model count alone does not establish the latter.

The costs you take on

Every agent you add is another thing that can fail, and the connections between them are where multi-agent systems break: handoffs drop context, agents loop or contradict each other, and a small fault in one cascades. Debugging gets harder because the failure is now spread across a conversation between components. Add agents when the problem demands it, not because more sounds more capable.

Two engineering write-ups from 2025 frame the trade from opposite sides. Anthropic reported that its research system, a lead agent directing parallel subagents, beat a single agent by 90.2% on its internal research eval, because subagents could explore separate directions at once in their own context windows. The same post says these systems used about 15 times the tokens of a chat and fit poorly where every agent needs the same context. Cognition’s Don’t Build Multi-Agents argues the opposite default: agents should share full context, because every action carries implicit decisions, and subagents working from partial context make conflicting ones. They don’t agree, and Cognition stays skeptical even of parallel subagents. Our reading of the two: splitting has the strongest case for broad, independent research, and work whose steps depend on each other belongs in one context.

Make the second agent earn its place

Compare the same tasks against a single-agent baseline. The checks below are our suggested experiment, not measured results from the guest examples.

Write down what each agent must return, how the next step validates it, and when the whole run stops. Measure the final outcome as well as each agent’s output. A reviewer saying “approved” is evidence to inspect, not proof that the task succeeded. Use agent evaluation to define the outcome and multi-agent failure diagnosis to inspect the connections.