Don't Go Multi-Agent: What 2026 Actually Recommends

In 2024 every architecture diagram grew tentacles. A supervisor here, a researcher there, a writer, a critic, a router, a small org chart of models passing notes to each other. It looked like progress.

We built it too. Orchestration patterns, routing layers, QA agents. Some of it helped. A lot of it quietly did not, and it took production data to tell which was which.

By 2026 the teams running agents at scale were saying the same uncomfortable thing: most of those extra agents bought complexity rather than capability.

What the evidence actually says

The cost is the mechanism, not an inefficiency. Anthropic's own write-up of its multi-agent research system reports roughly fifteen times the tokens of a single chat, and is direct that the architecture works largely because it spends enough tokens to solve the problem. That is not overhead you tune away. Remove the spend and you remove the result.

It fails in ways single agents do not. The MAST taxonomy, assembled by researchers at Carnegie Mellon and UC Berkeley from 1,642 annotated execution traces across seven multi-agent frameworks, catalogues fourteen distinct failure modes across three families: system design, inter-agent misalignment, and task verification. The striking part is where they cluster. The large majority originate in specification and coordination rather than in implementation, which is precisely the category a better foundation model does not help with.

The people who built the successful version hedge. Anthropic cautions that domains with dense interdependencies are a poor fit, because agents remain weak at real-time coordination and delegation. Cognition, the team behind Devin, reached the same place from the other direction and published it as advice to default to single-threaded, linear agents: an agent acting without the full trace of earlier decisions produces contradictory work.

And the market is voting. Gartner forecast in June 2025 that more than 40% of agentic AI projects would be cancelled by the end of 2027, naming escalating costs, unclear business value and inadequate risk controls. Model capability is not on that list.

The pattern that won

If not a swarm, then what? The answer is boring, which is usually a good sign: one agent, made capable by what surrounds it. Three layers do the work.

Dynamic skill activation. Rather than an agent per domain, one agent with a library of skills it loads on demand, so the right tools and instructions appear only when the task calls for them. This is the lowest-overhead point on the agent spectrum and a reasonable starting architecture rather than a compromise. Our own platform runs dozens of marketing skills across a dozen domains this way. The agent stays one mind, and a context-aware one.

Retrieval as context engineering. Long context did not kill retrieval, and splitting it across agents actively harms it: retrieval quality collapses on follow-up questions once no single agent holds the whole conversation. Models still attend unevenly across enormous windows, favouring the beginning and the end, so a tuned hybrid search with reranking beats filling a million-token prompt. The shift is in framing: from retrieve-and-stuff to deliberately curating the tokens the model reasons over.

Tiered memory. Working memory for the live task, short-term for the session, long-term for durable facts about the user, each compressed before it re-enters the window. Memory as a subsystem with a policy, not an append-only log.

1# The shape that scales: one agent, three force-multipliers.
2agent = Agent(
3    model,
4    system_prompt=context_engineered_prompt,   # curated, not kitchen-sink
5    prepare_tools=select_by_relevance,          # load skills on demand
6)
7# RAG and memory feed the agent as tools, not as a dozen separate "agents".

What you give up is nothing. What you gain is continuous context, a trace you can actually read, and a token bill that does not multiply by the number of boxes on the diagram.

Keeping that tool list short enough for the agent to choose well is the discipline underneath all of it, and accuracy falls off sharply past about fifteen tools.

When multi-agent is right

This is not dogma, and there is a shape where sub-agents genuinely pay: breadth-first, read-only research. Audit these twelve competitors. Survey the literature on this. The branches are independent, there is no shared state to corrupt, and the work fans out cleanly enough to be worth the token premium. That is the profile of Anthropic's research system, and it is a real profile.

The test is reads against writes.

Reads parallelise beautifully. Writes, meaning edits to records, messages sent, state mutated, generate exactly the coordination conflicts the failure taxonomy is made of. If your sub-agents have to agree with each other while they are running, you have bought a distributed systems problem and attached a language model to it.

Orchestrate when the work is wide and read-heavy. Stay single-threaded for everything else.

What to take away

Default to one agent. Fifteen times the tokens and fourteen documented failure modes is a price to earn, not to assume.

Make the agent smart with its context rather than with colleagues. Dynamic skills, retrieval as context engineering, tiered memory.

Use the read-write test. Wide and read-only, orchestrate. Anything that writes or coordinates, keep it linear.

This is the architecture the product runs on, and it is why one brand-aware agent replaces a 40-app stack rather than orchestrating a team of narrow ones.

We arrived here by building the other thing first, which is the expensive way to learn it. The articles behind this one are that route in order, and they are worth reading as a sequence rather than as advice.

FAQ

Why is multi-agent so much more expensive?
The token spend is the mechanism. Anthropic reports roughly 15x a single chat and credits the spend for the result, so it cannot be optimised away.

What actually goes wrong in multi-agent systems?
MAST catalogues fourteen failure modes from 1,642 traces across seven frameworks, clustered in system design, inter-agent misalignment and verification rather than in implementation.

When is multi-agent genuinely the right choice?
Breadth-first, read-only work with independent branches and no shared state to corrupt.

What replaces the extra agents?
Dynamic skill activation, retrieval treated as context engineering, and tiered memory, all around one agent.