More people, more agents, same plan

I think the excitement about running many AI agents at once repeats a mistake Brooks described in 1975. The mistake is measuring work in one number, so that doubling the workers halves the time. My claim is narrower: adding workers, human or AI, speeds a project up only as far as its plan lets the pieces run without talking to each other. Past that point the extra workers cost more than they give.

This is my opinion, and I have not run an experiment to prove it. Where I state a fact, it comes from a source linked at the bottom, and where that source is a vendor’s own data or a preprint that has not been peer reviewed, I say so. The section headed My view is where I stop reporting and start recommending.

Fred Brooks’s The Mythical Man-Month [Brooks 1975; Brooks 1995 (CHM)] starts from a unit that does not exist: the man-month, which assumes people and months can be traded freely. They can be traded only when the work is perfectly partitionable, meaning it splits into pieces that need no communication between workers. A task with a sequential constraint does not speed up at all. His example is a baby: nine women cannot produce one in a month [Wikipedia: Brooks’s law].

Brooks sets out four kinds of task in his chapter on this. At the two ends are the perfectly partitionable and the unpartitionable. Between them are tasks that can be partitioned but whose pieces have to communicate, ending in the case of complex interrelationships, where every pair may have to talk. That is the case that matters for software. Each new person needs training, which takes the existing people’s time, and the paths between n people number n(n−1)/2 [Wikipedia: The Mythical Man-Month]. Two people have one path, ten have 45, and fifty have 1,225. Brooks’s law is the consequence, in the sentence he is remembered for: “Adding manpower to a late software project makes it later.” [Wikipedia: Brooks’s law] He called it an oversimplification himself [Wikipedia: Brooks’s law], and I read it as a rule of thumb, not a theorem. The first figure draws three of the four kinds: the two ends, and the last one, where the curve falls and then rises.

The paths are the part people forget. They count pairs who may need to agree, and the count works for any kind of worker. Drag the slider and watch it outrun the headcount. An agent that has to coordinate with every other agent adds paths in the same way a person does, so you can switch the figure between people and agents.

Brooks’s answer to the cost was structure, not a bigger team. His surgical team has one skilled programmer build the critical parts with the others in support, instead of a crowd of equals splitting the code [Wikipedia: The Mythical Man-Month]. And he argued that a system needs conceptual integrity, which comes from separating architecture from implementation: one architect, or a small group, decides what belongs in it [Wikipedia: The Mythical Man-Month]. In my words, one mind holds the design, so the rest of the team does not have to negotiate it.

Computer scientists met the same shape from the other side. Amdahl [Amdahl 1967] argued in 1967 that the part of a computation that must run in sequence bounds the speedup however many processors you add. In the form now usually written, if a fraction α is serial, the speedup on N processors is N / (1 + α(N−1)), and it flattens toward 1/α.

Neil Gunther’s Universal Scalability Law [Gunther (arXiv preprint)] adds a second cost. Throughput on N workers is C(N) = N / (1 + α(N−1) + βN(N−1)). The α term is contention, the queue for something only one worker can use at a time. The β term is coherency, the cost of making the parts agree, and it grows with the pairs. Gunther shows that Amdahl’s law is the case where β is zero [Gunther (arXiv preprint)]. I read β as Brooks’s communication cost in other clothes. With any β above zero, throughput rises, peaks at N* = √((1−α)/β), and then falls. More workers past the peak make things slower. Move the sliders.

Conway [Conway 1968] made the point about organisations in 1968: an organisation that designs a system produces a design that copies its own communication structure. I take two things from that. A team cut along lines of talk leaves those seams in the software. And the useful direction runs the other way: decide the seams you want in the software, then cut the work along them.

QSM sells software estimation tools and keeps a database of finished projects, so what follows is vendor data, and I treat it that way. A QSM summary [QSM (vendor)] covers four studies, and I use two of the four. Putnam (1997) used 491 projects from the QSM database and found that for medium-sized systems, teams of 3 to 7 people were optimal. Armel (2012) looked at about 1,060 IT projects completed from 2005 to 2011 and compared teams of five or more people with teams of four or fewer. The larger teams were roughly three to four times as costly and produced two to three times the defects [QSM (vendor)].

I would not read that as proof that size causes the cost. These are finished projects, not an experiment, and bigger teams may have been given harder work. It fits the arithmetic above, and it says nothing yet about agents.

Cognition, a company that sells an agent product (so, vendor), published Walden Yan’s June 2025 argument against building systems of many agents that each take a slice of the job [Cognition (vendor)]. His reason is the one Brooks and Conway would recognise: “Actions carry implicit decisions, and conflicting decisions carry bad results.” A subagent makes choices the others cannot see.

A preprint, Why Do Multi-Agent LLM Systems Fail? [Cemri et al. (MAST, preprint)], read more than 1,600 annotated traces from 7 multi-agent frameworks and sorted the failures into 14 modes in 3 categories: system design, misalignment between agents, and task verification. The middle category, misalignment between agents, is mostly about agents failing to communicate.

Another preprint [Kim et al. (preprint)] ran 260 configurations across six benchmarks, five architectures (one agent and four ways of connecting several) and three model families. On PlanCraft, a sequential planning task, every multi-agent design did worse than one agent, by 39.1% for the hybrid design up to 70.0% for independent agents. On Finance Agent, a task that splits into parts, every multi-agent design did better: +80.8% for the centralized design, +74.5% decentralized, +73.1% hybrid, and about +57% for independent agents, which is the low end of the range the paper states. The benchmark closest to software development is SWE-bench Verified, real GitHub issues. There every multi-agent design did slightly worse than one agent on average: 2.1% worse for hybrid, 3.1% centralized, 5.4% decentralized and 14.9% independent. The authors flag that their samples are small and the uncertainty wide, so I would not lean on any single digit. They also estimate, from traces, how far errors are amplified: 17.2 times for independent agents and 4.4 times for a centralized design, whose orchestrator catches errors before they are combined [Kim et al. (preprint)]. That is the shape of the earlier figure in a new medium: the same extra workers lose on work that cannot be split, gain on work that can, and cost the most when nothing checks the results.

The cost of collisions shows in version control too. Xu and colleagues [Xu et al. (preprint)], in a preprint, studied 33,596 agent-authored pull requests in 2,807 repositories, and found that 79.4% were open at the same time as another agent-authored pull request in the same repository, mostly from the same agent. When they replayed 747 such pairs as merges, 41.7% of the pairs from different agents conflicted in the text, against 19.8% for pairs from the same agent. The cross-agent figure rests on a small sample, 115 pairs that could be evaluated (from 122 repositories), against 601 same-agent pairs, and it counts only textual conflicts, so the authors call their results a lower bound. A separate preprint, AgenticFlict [AgenticFlict (preprint)], simulated merges for more than 107,000 agent pull requests and found 27.67% had textual conflicts. The two studies count different things, so I show them as separate bars.

The case for many agents is real, and I should give it its due. Anthropic reported [Anthropic: research system (vendor)] that a research system with a lead agent and parallel subagents beat a single agent by 90.2% on the company’s internal research evaluation, and used about 15 times the tokens of a chat. The same post says that “most coding tasks involve fewer truly parallelizable tasks than research.” [Anthropic: research system (vendor)] That is a vendor describing its own test, and a breadth-first research question is close to the most partitionable work there is.

Nicholas Carlini, an Anthropic researcher writing about Anthropic’s own model (so, vendor), had 16 parallel Claude agents write a C compiler of about 100,000 lines that builds Linux 6.9 on x86, ARM and RISC-V. They claimed tasks by writing lock files, and the version control forced an agent to pick another task if one was taken. The instructive moment is where it broke. When the job became compiling the kernel, one big shared task, every agent hit the same bug, fixed it, and overwrote the others’ changes. What fixed it was using GCC as a known-good oracle, so most files were built with GCC and the rest with the new compiler. Each agent could then work on a different file. He also notes that merge conflicts were frequent and that Claude resolved them itself [Carlini: C compiler (vendor)]. Conflicts were part of the cost, and an agent handled them; that is a result for a strong model on a project with a very good test oracle, and I would not assume it holds without one.

Two objections come from the theory. Gustafson [Gustafson 1988] pointed out that Amdahl assumes a fixed problem, and that when the problem grows with the machine, speedup keeps going. For a software project, that means a bigger product can use a bigger team, if the extra work is new work that is independent of the rest. And the Brooks’s law page quotes Steve McConnell, in 1999, saying he no longer believes the law holds as stated. As the page reports it, he argues that late projects are later than managers think because the original schedule was too optimistic, so adding staff is not what makes them late, and that the law applies only to a project’s final phases [Wikipedia: Brooks’s law]. On that reading, people added early are outside what the law describes.

Kim et al. [Kim et al. (preprint)] add a warning that I take seriously. The design with no coordination at all, independent agents, amplified errors most, 17.2 times against 4.4 for the centralized design with a hub that checks the work. So not needing to talk is not the same as not coordinating: the lesson I draw is to partition the work and keep one place that checks the pieces together.

Here is what I notice about every success above. Each one was partitioned first. The research question was split into independent searches. The compiler’s agents took separate claimed tasks, and when they could not, the oracle made separate pieces. Gustafson’s bigger problem is more of the same independent work. I read that as support for my claim, not a refutation of it, but you can fairly read it the other way: they show parallel work paying off, and my claim says only when.

My view, not a finding

The lever is the plan, not the headcount. Before adding a person or an agent, I would partition the work so that parallel tasks don’t need to talk. Four things do that. An oracle gives every worker a way to know what correct means without asking a neighbour: a test suite, a reference implementation, a spec it can run. A claim system, like Carlini’s lock files, keeps two workers off one task. One architect holds the design, which is Brooks’s conceptual integrity, so interfaces get decided once instead of being rediscovered by each branch. And one place checks the pieces together before they merge, a reviewer or a test gate or a hub agent, because pieces that never talk still have to fit. Only then add workers, up to the number of independent pieces and no further.

I run my own work this way: specialist agents, wired as a graph, where each branch gets a piece that does not need to talk to the others. Designing an agent graph draws the patterns. This page is an argument, not a report of results.

What would show I am wrong? A controlled comparison in which the same agents, with the same checking, finish a tangled plan as fast and as cleanly as a partitioned one. Or one in which throughput keeps rising as I add agents past the number of independent pieces. I have not seen either, and I would change my mind if I did.

The last figure draws the same eight tasks two ways. Step through time. The partitioned plan has four lanes that never touch. The tangled plan has the same tasks, but lanes wait on each other and two pairs edit the same file at once. It is an illustration with made-up tasks, not data.

If most of those answers are no, the plan is tangled, and more workers will buy you more paths and not more throughput. Fix the plan, then hire.

• The next platform teamWhere I argue for small pods that direct agents, and what a platform team has to provide for that to work.
• Designing an agent graphThe patterns an orchestrator uses to fan work out to agents and fan the results back in.
• One loop, three modelsA scripted replay of the loop that builds this site, with plain code holding the gates.

• Brooks 1975 · Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975; anniversary edition 1995, ISBN 978-0201835953 (the book itself; O’Reilly copyright page)
• Brooks 1995 (CHM) · Computer History Museum catalogue record for the 1995 anniversary edition of The Mythical Man-Month: Essays on Software Engineering
• Wikipedia: Brooks’s law · Brooks’s law, revision 1357983889: the law’s wording, Brooks’s own "oversimplification" remark and McConnell’s 1999 caveat (a secondary source for Brooks)
• Wikipedia: The Mythical Man-Month · The Mythical Man-Month, revision 1354227795: the partitioning argument, n(n−1)/2 channels, the surgical team and conceptual integrity (a secondary source for Brooks)
• Amdahl 1967 · Gene M. Amdahl, "Validity of the single processor approach to achieving large scale computing capabilities", AFIPS Conference Proceedings 30, 1967, pp. 483–485
• Conway 1968 · Melvin E. Conway, "How Do Committees Invent?", Datamation, April 1968
• Gunther (arXiv preprint) · Neil J. Gunther, "A General Theory of Computational Scalability Based on Rational Functions", arXiv:0808.1431: the Universal Scalability Law, with Amdahl’s law and Gustafson’s speedup as corollaries
• Gustafson 1988 · John L. Gustafson, "Reevaluating Amdahl’s Law", Communications of the ACM 31(5), 1988
• QSM (vendor) · QSM, "4 key studies on team size" (vendor data: QSM sells estimation tools), dated 2019-06-27; summarises Putnam 1997 and Armel 2012
• Anthropic: research system (vendor) · Anthropic Engineering, "How we built our multi-agent research system", 2025-06-13 (the company’s own internal evaluation)
• Cognition (vendor) · Walden Yan, Cognition, "Don’t Build Multi-Agents", 2025-06-12 (vendor: Cognition sells an agent product)
• Cemri et al. (MAST, preprint) · Cemri et al., "Why Do Multi-Agent LLM Systems Fail?", arXiv:2503.13657 (preprint): 1,600+ annotated traces, 7 frameworks, 14 failure modes in 3 categories
• Kim et al. (preprint) · Kim et al., "Towards a Science of Scaling Agent Systems", arXiv:2512.08296 (preprint): 260 configurations, 6 benchmarks, 5 architectures, 3 model families
• Carlini: C compiler (vendor) · Nicholas Carlini, Anthropic Engineering, "Building a C compiler with a team of parallel Claudes", 2026-02-05 (vendor: an Anthropic researcher reporting on Anthropic’s own model)
• Xu et al. (preprint) · Xu, Subramanian and Karthik, "AI Agent Pull Requests on GitHub: Frequency, Structure, and Merge Conflict Rates", arXiv:2607.04697 (preprint)
• AgenticFlict (preprint) · Ogenrwot and Businge, "AgenticFlict: A Large-Scale Dataset of Merge Conflicts in AI Coding Agent Pull Requests on GitHub", arXiv:2604.03551 (preprint)