Anthropic's Multi-Agent Research System Beat a Single Agent by 90.2%; Separately, It Uses 15x the Tokens of Plain Chat

A lead agent splits the question and hands pieces to subagents that run at the same time ^[1]. In research retrieval those pieces are genuinely separate: ten sources can be read by ten readers who never talk to each other ^[15]. Each reader costs tokens.

The two Anthropic figures have different denominators. The 90.2 percent gain is measured against a single agent on an internal research eval ^[2]. The 15x token figure is measured against a plain chat ^[3]. So the pair cannot give you cost per point of gain ^[22].

Token usage by itself explained 80 percent of performance variance on BrowseComp ^[4]. That leaves 20 percent for role design, prompting and coordination ^[20]. For the 90.2 percent to transfer to your workload, your subtasks would have to decompose the way source-reading does. Anthropic's own post names the domains where they do not: every agent needing the same context, or many dependencies between agents ^[5]. Most coding tasks, the post says, have fewer truly parallelizable pieces than research ^[6].

A 2025 paper from UC Berkeley researchers and collaborators, Why Do Multi-Agent LLM Systems Fail?, opens by saying gains on popular benchmarks "are often minimal" ^[7]. The authors annotated more than 1,600 traces across 7 frameworks at 0.88 kappa and sorted what they found into 14 failure modes ^[8].

System design accounted for roughly four failures in ten, led by disobeying the task specification, repeating steps and missing the termination condition ^[9]. Inter-agent misalignment took about a third, and its largest single mode is a reasoning-action mismatch, where the agent says one thing and does another ^[10]. Verification failures took about a quarter, split between no verification, wrong verification, and stopping before the work was done ^[11]. The authors wrote that failure "is not merely a function of challenges in the underlying model" ^[12].

They then tried the obvious repairs on one framework. Clearer role specifications lifted the success rate by 9.4 percent, and adding a high-level verification step lifted it by 15.6 percent ^[13]. Verification bought 6.2 points more than role clarity, about 1.7 times the gain ^[21]. The authors still concluded that those isolated fixes were not enough and that reliability needs deeper redesign ^[14].

The dev.to write-up turns this into a pre-build check: take the cost of one good single-agent run, multiply by fifteen, and ask whether a person would pay that for the better answer ^[17]. A question asked once a quarter that saves a day of reading clears the bar; a routine task run a hundred times a day almost never does ^[18]. Its parallelism test is to write the subtasks down first, because if B needs A's output, five agents add four handoffs and no concurrency ^[16]. On the checking step, the same post says: "A multi-agent system without a named checker is a group chat" ^[23].

Every agent also needs its own written job: the input it gets, the output it returns, the format, and the condition that means stop ^[19].