Single Agent vs Multi-Agent Systems

Decision rule

Start with one agent that has clear instructions, a small set of well-described tools, retrieval or memory where it matters, and an evaluation set that represents real tasks. Split only when that baseline fails for a reason that a split can actually fix.

The most common valid reasons are prompt overload, tool overload, independent parallel research, separate trust boundaries, or a need for independent critique. The common invalid reasons are fashion, "more agents means more intelligence," and vague hopes that one agent will correct another without a tested protocol.

Anthropic's general agent guidance and OpenAI's builder guide both point in this direction. They do not say "never split." They say to earn the split by showing that extra orchestration improves accuracy, coverage, reliability, or control enough to pay for its latency and cost.

When multi helps

Multi-agent systems are strongest when a problem has breadth. A research query can branch into independent leads. A due-diligence task can divide by company, jurisdiction, and source class. A code review can use separate prompts for correctness, security, and migration risk, then merge findings.

In those cases, separate context windows are not just a convenience. They are capacity. Each worker can explore its slice without stuffing every intermediate source into one global transcript. The coordinator's job is not to micromanage each token; it is to set the plan, receive compressed artifacts, check them against the question, and ask for more work only where coverage is weak.

This result should be read narrowly. It is evidence that a carefully engineered multi-agent system can help on breadth-first research. It is not proof that every support bot, coding assistant, or business workflow should become a swarm. Anthropic itself notes that coding tasks often have fewer truly parallelizable pieces than research.

When one agent wins

One agent often wins when decisions are tightly coupled. Product implementation, editing a single code path, troubleshooting a live incident, and negotiating a policy-sensitive customer flow all require continuity. If one subagent makes an implicit decision and another cannot see it, the coordinator inherits mismatched assumptions rather than useful work.

Cognition's critique is the clearest statement of this risk. Its argument is not that collaboration will never work. It is that today's agent systems often split decision-making faster than they can share the full context and action traces that made those decisions meaningful.

Single-agent systems also remain easier to evaluate. When one agent fails, the trace is one trace. When a multi-agent system fails, the cause may be a bad delegation, a missing artifact, a low-quality worker result, a coordinator synthesis error, or a conflict between two plausible but incompatible assumptions.

Scorecard

Use this scorecard before you add a second agent. A "yes" does not automatically justify a split, but several strong yeses make a multi-agent prototype worth testing.

The practical threshold is simple: if you cannot explain what each agent knows, what it owns, what artifact it returns, and how the coordinator validates that artifact, the system is not ready to be multi-agent.