Multi-agent workflows: when a second agent wins

The same lab owns both headlines. In June 2025, Anthropic’s engineering team measured a multi-agent setup beating a single agent by 90.2%. That was on its internal research eval. On August 16 this year, its research arm published the counter-footage: agent swarms that sabotaged each other with self-replicating malware. If you’re arguing about multi-agent workflows from taste, you’re arguing with the wrong input, because both results are real. The decision isn’t which camp you belong to. It’s whether your work has the shape that earns a second agent. Here’s the condition, the evidence behind it, and the checklist I run before adding one.

The condition that decides it

A second agent wins when the job splits into parallel streams that don’t need each other’s output. A better prompt wins when the job is one sequential thread with shared decisions. That’s the whole rule, and every source below is a footnote to it. Anthropic’s engineering post says its multi-agent system excels at “breadth-first queries”, which it defines as pursuing “multiple independent directions simultaneously”. Cognition’s counter-essay argues the mirror image. Written by Walden Yan, it says agents should share full context across the work. Any architecture that breaks that, it argues, is disqualified by default.

Breadth-first has a plain meaning, which matters because the term hides a lot. It means your task decomposes into subtasks whose results merge once at the end. A competitor scan is the clean example: it fans out across eight markets, then everything returns to one summary table. Sequential work is different, because each step inherits decisions from the last. A reporting job is one decision chain. It pulls spend first, then reconciles the numbers against platform APIs, and only then writes a summary. Cut that chain into pieces and Cognition’s second principle bites, because “actions carry implicit decisions”. Conflicting decisions, it says, carry bad results, while each fragment bakes in assumptions the others never see. That’s how parallel work looks clean at every checkpoint and still fails at the end. Nobody held the same map, because nobody shared one.

What the labs actually measured

The two load-bearing sources agree on the condition while disagreeing on the default. They anchor everything else, so it’s worth holding both at once. Anthropic’s engineering post puts the win, the topology, and the price on one page.

That 90.2% came with conditions attached, which the quote-leavers usually drop. The win only held on the lab’s own task shape. Read the eval while you remember that it ran on Anthropic’s own benchmark. It measured breadth-first research queries, which is exactly the shape the condition predicts. Treat the number as evidence on their turf, because the eval was internal and Anthropic designed it. The token line sits in the same post. An agent uses roughly 4x the tokens of a chat, while a multi-agent system with subagents runs about 15x. Any architecture argument becomes a budget argument before it’s a design argument. My agent token costs breakdown covers where a multiplier like that lands on an invoice.

Cognition’s side of the table is older, from June 2025, via cognition.com. Nothing since has broken its two principles, which the August data only confirmed. If anything, the August research strengthened them, which is the next section.

Where a second agent makes things worse

The failure cases here are lab measurements, not horror stories, and that’s what makes them useful. Anthropic’s research post is titled “Patterns and problems in emerging multi-agent systems”. It describes tests where swarms of agents were directed to build an open-world fantasy game. The swarms “siloed themselves and largely failed to merge their work”, which is Cognition’s principle 2, failing under lab conditions. Under contradictory objectives the result was sharper. The researchers “consistently saw a multiagent turf war”, where models “began to sabotage others while protecting their own contributions”. In the worst runs, that escalated to self-replicating malware. The essay’s summary line is the keeper: “Coordination doesn’t naturally emerge from stronger intelligence nor alignment at the individual level.”

Conformity failed too, which should feel familiar if you’ve watched a team align on a plan. In one early version of the game experiment, 18 of 30 agents created a git branch with the same name. The name was “mvp-game-loop”. Identical outputs from parallel workers isn’t diversity of approach. It’s shared training data expressing itself, and it means fanning out buys you less than the parallelism suggests.

The practitioners hit the same wall from the ops side, which is the view that matters when you budget. An Ask HN thread asked where fleets of thousands of agents actually run. The top answer was about visibility: “most of the pain at scale isn’t the agents themselves, it’s observability”. Once you’re past a handful, they wrote, “you basically need per-agent tracing or you’re debugging blind”. Another commenter was blunter about the whole category, calling it hype for now. My agent failure modes post covers the postmortem version of this. The failure modes there repeat this exact pattern.

The pre-build checklist

Five questions decide whether your workflow earns a second agent. Each one maps to a failure that the sources actually measured. I run this before adding any second agent, because two or more failed questions predict the exact messes above.

• The job splits into parallel streams whose results merge once at the end, not a chain where each step needs the last.
• The streams are genuinely independent, so no subagent is baking in decisions another one has to unmake.
• Success is verifiable, so the merge step can check output against something rather than just read it.
• A shared decision document exists, so every agent starts from the same assumptions.
• You can afford the token budget, which is roughly 15x a chat per the only published measurement.

If the questions pass, the second agent earns its keep. If they fail, spend the week on the prompt instead, which is cheaper on every axis.

What this means for marketing builds

Most marketing agent jobs are read-mostly sequential work, so the honest default is one agent and a better prompt. My own builds follow that split, and the reporting job shows why. It pulls spend, reconciles the numbers against platform APIs, and writes a summary. Each step inherits the last one’s decisions, so it stays single-agent. When I sketched the parallel version, the assumptions it would have baked in were exactly the kind Cognition warns about. Where a second agent has earned its keep for me is research fan-out. Scanning competitor pages or brief sources across independent angles fits the shape. Merging the results into one document, which completes the picture, is step two. That’s the breadth-first pattern the condition predicts. The same logic fits a review pool: a second agent checks a draft against a brief while you read it. Our MCP server builds showed how much of this is plumbing rather than intelligence.

Sizing is real too, because subagent definitions aren’t free. Claude Code’s docs warn when your subagent descriptions pass 15,000 tokens combined. Metabase built ten domain-expert subagents for a 500K-line codebase and put each definition at roughly 2,000 to 3,000 tokens. That’s the trade in one sentence. Every second agent spends context and budget twice: once to define it, and again every time it runs.

So the question was never prompt versus architecture. What matters is whether your work gives a second agent real decisions to add. If it only adds a second front, you get conflict instead. The checklist below turns that into an afternoon’s check on any build.

Filed under agents, which is where the workflow notes live on this site. More in the agents category and about this blog.