Do You Need Many AI Agents, or One Good One?
Do you need many AI agents, or one good one?
For almost every marketing and web workflow, one good agent wins. Multiple agents help when the work is genuinely parallel research, where each agent reads and reports but none of them writes. The moment two agents both change things, you get conflicts that nobody can debug.
This is not a settled question, and we like that about it. Two serious AI labs have published opposite advice, both from production experience, within a day of each other. Reading them side by side taught us more than either alone.
So this piece is a comparison, not a verdict handed down. We will show you both arguments with their real numbers, then tell you where we land for the kind of work our clients actually run.
What does a multi-agent system actually mean?
A multi-agent system uses one lead model to break a task into parts, hands each part to a separate model instance with its own context window, and then combines the results. A single agent does the whole job in one continuous thread, keeping every step in the same context.
The distinction is not about how many models you pay for. It is about how many separate contexts exist. One agent calling ten tools in sequence is still one agent. Three agents each holding their own view of the task is a multi-agent system, even if they never speak.
That framing matters because the failure modes are completely different, and so is the bill.
What did Anthropic find when it split the work?
Anthropic published "How we built our multi-agent research system" on June 13, 2025. Its headline result: a multi-agent system with Claude Opus 4 as lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on their internal research evaluation. That is a large gap, not a rounding difference.
Anthropic also explained where the gain came from. On the BrowseComp evaluation, three factors explained 95% of performance variance, and token usage by itself explained 80%. Tool call count and model choice were the other two.
Read that carefully, because it is the honest part. Multi-agent systems mostly won by spending more. More context windows means more tokens means more reasoning applied to the problem.
Anthropic put a price on it too. Agents use about 4 times more tokens than chat interactions, and multi-agent systems use about 15 times more tokens than chats. Fifteen times.
Why does Cognition say not to build multi-agents?
Cognition published "Don't Build Multi-Agents" by Walden Yan on June 12, 2025, one day earlier. It argues from two principles: "Share context, and share full agent traces, not just individual messages" and "Actions carry implicit decisions, and conflicting decisions carry bad results."
The worked example is a small game build. Split across subagents, one builds a background in the wrong visual style while another builds a character that does not match it. Neither was wrong about its own instruction. They were wrong about each other.
Cognition's fix is blunt: "The simplest way to follow the principles is to just use a single-threaded linear agent." Keep one context. Keep one writer. Accept the slower path.
Can both of these be right?
Yes, and the reason is the word actions. Anthropic's subagents read, search and summarise. They do not overwrite each other's work. Cognition's failing subagents build things, and their outputs must fit together. Parallel reading is safe. Parallel writing is where the trouble starts.
Once you see that, the two posts stop contradicting each other. Anthropic's research agents are a fan out of questions with a single point of assembly at the end. Cognition is warning about a fan out of decisions with no point of assembly at all.
We have found this the most useful test we know for any automation someone wants to build. Count the writers, not the agents.
What does context fragmentation look like in real marketing work?
It looks like three plausible outputs that cannot be merged. One agent writes a page in the brand voice from a style guide. Another writes the meta description from the keyword brief. A third picks internal links from a sitemap. Each is defensible. Together they read like three people who never met.
We have seen the same pattern in content pipelines that split research from drafting. The research agent decides the piece is about pricing psychology. The drafting agent, given only the outline, decides it is about pricing pages. Nobody flagged a conflict because no agent ever saw both decisions.
The tell is always the same. The output is not broken. It is just subtly incoherent, and the person reviewing it cannot say why. That is expensive in a way no token counter shows you.
When is one agent clearly the right answer?
Whenever the work produces one artefact. Writing a page, editing a document, updating a CMS record, replying to a lead, filing a ticket. One output means one writer, and one writer means one context. Adding agents here adds coordination cost and buys nothing.
It is also the right answer when you need to explain a result later. A single thread has a single trace you can read top to bottom. That matters more than teams expect, and we made the case for it in our piece on when an agent beats a plain script.
Most of what a marketing team automates falls here. That is not a limitation. It is the cheap, reliable majority of the work.
When does a second agent actually earn its keep?
When the task is wide rather than deep, and reading is the bottleneck. Checking twenty competitor pages. Pulling facts from thirty sources. Classifying a backlog of support tickets. Each unit is independent, nothing overwrites anything, and one agent at the end assembles the findings.
The second good case is review. One agent drafts, a separate agent with a clean context checks the draft against rules. The checker has no stake in the draft and no memory of writing it, which is exactly why it catches things. It proposes, it does not edit.
Both cases share a shape. Many readers, one writer. Keep that shape and the Anthropic result is available to you. Break it and the Cognition warning applies.
What does this cost, and who ends up paying for it?
Using Anthropic's own multiples, a multi-agent workflow costs roughly 15 times a chat and about 4 times a single agent run. For a research task you run twice a month, that is trivial. For a workflow that fires on every form submission, it is a budget line somebody will question.
The trap is building the expensive shape for the cheap problem. We see teams reach for orchestration because it feels more serious, then run it on a job a single prompt would finish. Our notes on keeping AI costs predictable go deeper on this.
There is a second cost nobody budgets: debugging time. One trace is readable by a human. Five parallel traces are not, and the person reading them is usually the person who least wanted the job.
How would we build this for a marketing team today?
Start single threaded. Give one agent a clear job, real tools, and the full context it needs. Run it for a few weeks and write down every place it actually failed. Only then ask whether any of those failures is a breadth problem that a parallel reader would fix.
If the answer is yes, add readers, never writers. Fan out the research, assemble in the main thread, and keep the single agent as the only thing that changes any system of record. Pair that with a human approval step on anything irreversible, which we cover in where to put a human in the loop.
Resist the urge to name your agents. It sounds small, but teams that build an org chart of agents start defending the org chart instead of the output.
What should you try first this week?
Take one workflow you already run by hand and count its writers. If it produces a single artefact, build it as one agent and stop there. If it reads widely and produces one summary, that is your candidate for a fan out, and it is the only one you need this quarter.
The broader lesson from reading both posts is that architecture arguments in this field are usually arguments about context. Anthropic spent more context and won. Cognition split context and lost. Neither result is about agent count.
We build these pipelines for B2B teams alongside the websites they feed, so we see which ones survive contact with a real content calendar. If you are weighing an automation and want a second opinion before you commit engineering time, we are happy to walk through it. Find us at phoenix.studio.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.