Many Hands Make Heavy Work

In 1955 C. Northcote Parkinson opened an essay in The Economist with a sentence that has outlived almost everything else written that year: "It is a commonplace observation that work expands so as to fill the time available for its completion" (Parkinson, 1955, "Parkinson's Law", The Economist, 19 November). Most people remember the sentence about time. Fewer remember that the rest of the essay was about people. Parkinson's evidence was that the number of officials at the Admiralty rose from 2,000 in 1914 to 3,569 in 1928, while the number of capital ships in the Royal Navy fell from 62 to 20, and his conclusion was that "the number of the officials and the quantity of the work to be done are not related to each other at all."

In a recent conversation I found myself proposing a companion to it, almost in passing: a task will also take as many collaborators as it can get, until it grinds to a halt. This essay is my attempt to state that properly, to find out what the evidence says about it, and to say where it is wrong. Here is the version I have ended up with:

The law of many hands. A task keeps gaining collaborators for as long as each addition pays whoever makes it, not for as long as it pays the task, so it grows past the point where the next collaborator helps; where nothing else caps it, it does not settle before the coordination they create absorbs the work they add.

In Parkinson's register, which is shorter and less exact: work expands so as to absorb the hands available for its completion. By a collaborator I mean anyone whose output another participant must read, or whose approval another must wait for. That includes people hired onto a task, but also reviewers, invitees, consulted experts and, later in this essay, AI agents.

The argument has two halves, and they come from different places. The stall has two sources, and only one of them needs people. In human teams much of it is motivation: people pull less hard when others are pulling. In the two experiments that separated the sources, motivation was about half the loss in shouting and most of it in rope-pulling. The rest is structure: adding people to interdependent work adds coordination faster than it adds capacity. That part is true of software teams, of multiprocessor computers and, it turns out, of language-model agents that have no psychology at all, and it is enough on its own to produce a peak and a decline. The pull is where psychology, and incentives more generally, come in. The decision to add someone is usually taken by a person who gets something private from the addition, such as credit, cover, visibility or a bigger department, while the coordination cost is spread across everyone. That is the same structure that empties an open-access fishery, and it predicts the same outcome: entry continues past the best size and, unless a budget or a rule stops it first, does not stop before the activity is producing little or nothing net.

The claim that I think would most surprise a sympathetic reader is the one about agents, so I will state it now in a form that could be wrong: removing human psychology from a team does not remove the overshoot. AI agent systems in which the cost of adding an agent falls outside the reward of whoever adds it will grow past their best size in the same way that human teams do, and the fix in both cases is not better motivation but making the decision to add a collaborator carry its own coordination cost. If agent systems with unpriced spawning turn out to settle at their best size anyway, the agent half of this essay is wrong.

I should say up front that I build AI agent systems for law firms, so I have an interest in how agent teams are designed, and the conclusion that agent systems need admission control is convenient for someone in my position. I have tried to compensate by citing the evidence that cuts against me, by naming the people who got here first, and by ending with predictions that could prove me wrong.

This essay also started as a conversation with an AI research assistant, which I have treated as data, not as a source. Every factual claim below was checked against the primary paper or, where I could not reach it, against several independent sources, and I have kept a record of that checking. One small example of why that matters: when the assistant described several of my own software repositories and how they related to the idea, the footnotes it attached to those descriptions pointed to a business blog post about Parkinson's law and a BBC article about the same. The descriptions might have been right. The citations were decoration. I wrote about that failure in Floating Theories, published the same day as this essay, and it applies to this essay's own central claim too, as I will show.

Parkinson's other half

Parkinson's 1955 essay was satire, written in deadpan for a general audience, and his Admiralty figures were offered as illustration rather than as a study. I am not leaning on it as evidence. I am leaning on it because his diagnosis of why officials multiply is the pull half of my law, stated seventy years early. He proposed two "motive forces": "An official wants to multiply subordinates, not rivals", and "Officials make work for each other." The first is a reason to add people that pays the person adding them. The second is the coordination cost that those people then impose on one another. Parkinson even put a number on the stall. In his 1957 book he proposed a "coefficient of inefficiency", the size at which a cabinet or committee can no longer work efficiently, and placed it somewhere between 19.9 and 22.4 members, the decimals standing for members who attend for part of the meeting (Parkinson, 1957, Parkinson's Law and Other Studies in Administration, chapter "Directors and Councils, or Coefficient of Inefficiency"). That too was a joke with a point, and I take only the point.

The earliest connection I have found between Parkinson and over-staffed design work is Melvin Conway's, in the 1968 paper that gave us Conway's law (Conway, 1968, "How Do Committees Invent?", Datamation 14(4), 28-31). Most people know the paper for its thesis, that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations". Fewer have read its section on why large systems disintegrate, which begins with "the tendency to overpopulate a design effort". Conway gives several reasons, and three of them are mine. The first is blame: "A manager knows that he will be vulnerable to the charge of mismanagement if he misses his schedule without having applied all his resources." The second is Parkinson: "Parkinson's law plays an important role in the overassignment of design effort. As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization." The third is misestimation: the accounting habit of treating "two men working for a year or one hundred men working for a week" as "resources of equal value", forty-four years before the error was measured in a laboratory. And then a sentence that I would put on the wall of every engineering department: "Once the organization exists, of course, it will be used."

So the observation is not new, and I want that on the record before I claim anything. What I think is missing is a single mechanism that explains both why the hands arrive and why they stop being useful, that says where the growth should stop, and that can be tested on a kind of team, AI agents, that Parkinson and Conway could not have imagined.

Why more hands stop helping

Start with the stall, because it is the half with the strongest evidence.

Fred Brooks gave it its best-known form: "Oversimplifying outrageously, we state Brooks's Law: Adding manpower to a late software project makes it later" (Brooks, 1975, The Mythical Man-Month, Addison-Wesley, chapter 2). The phrase "oversimplifying outrageously" is his, and it matters, because Brooks was careful about when the law holds. "Men and months are interchangeable commodities," he wrote, "only when a task can be partitioned among many workers with no communication among them", as in reaping wheat or picking cotton, and his three reasons why adding people hurts are the time to train newcomers, the extra intercommunication, and the work of repartitioning the task. His most quoted line makes the sequential case: "The bearing of a child takes nine months, no matter how many women are assigned."

The intercommunication argument is usually summarised as a count. With n people there are n(n − 1)/2 possible pairs, so ten people have 45 possible channels and twenty have 190. I made the same argument about requirements in How High Can You Build in Mud?, and the caveat I gave there applies here too: the pair count is an upper bound on the coordination surface, not its size. Most pairs of people on a large project never need to talk. The argument does not need all of them to. It needs only the number of pairs that do need to coordinate to grow faster than the number of people, and it needs nobody to be able to tell in advance which pairs those will be.

That is the theory. The measurements come from several fields, and they agree on direction while disagreeing usefully on cause.

Rope, noise and the two kinds of loss. In the 1880s the agricultural engineer Maximilien Ringelmann measured how hard people pushed or pulled a load, including on a rope, alone and in groups, and found that the force per person fell as the group grew. He published it in 1913, and the effect bears his name. A reanalysis of the original article confirms the decline (Kravitz and Martin, 1986, Journal of Personality and Social Psychology 50(5), 936-941). Ivan Steiner gave the result its standard frame: a group's actual productivity is its potential productivity minus process losses, and process losses come in two kinds, coordination losses and motivation losses (Steiner, 1972, Group Process and Productivity, Academic Press).

The experiments that separated those two kinds are the ones I find most instructive. Ingham and colleagues repeated Ringelmann's rope-pulling with "pseudo-groups": a participant was led to believe that others were pulling with them, when in fact they pulled alone. With no one to coordinate with, effort still fell as the believed group grew from one to three, and then held steady (Ingham, Levinger, Graves and Peckham, 1974, Journal of Experimental Social Psychology 10(4), 371-384)90033-X). Their real groups of six pulled at 78% of the sum of their members' solo efforts and their pseudo-groups at about 85%, so most of the rope-pulling loss was effort, not coordination; Latané and colleagues later read it as virtually all. Latané, Williams and Harkins did the same with clapping and shouting, and found that groups of two produced about 71% of the sum of what their members produced alone, and groups of six about 40%, with a pseudo-group condition for shouting showing that about half the loss survives when coordination is impossible, which the authors read as half coordination and half loafing (Latané, Williams and Harkins, 1979, Journal of Personality and Social Psychology 37(6), 822-832). Their title was "Many hands make light the work". This essay's title is the correction. A meta-analysis of 78 studies found the effect, now called social loafing, to be robust, larger in larger groups, and smaller when individual contributions are identifiable or the task matters to the people doing it (Karau and Williams, 1993, Journal of Personality and Social Psychology 65(4), 681-706).

Knowledge work. Effort on a rope is not the work most readers do. The closest study to it that I know of followed 212 knowledge workers in 26 teams of between 3 and 19 people, and found that individuals in larger teams performed worse, largely through feeling less able to get help and support from teammates when problems arose, which the author calls relational loss (Mueller, 2012, Organizational Behavior and Human Decision Processes 117(1), 111-124). In open-source software, an analysis of 58 projects, more than 580,000 commits and more than 30,000 developers found that average productivity per developer fell as teams grew, and tied the decline to the growing density of the network of developers editing the same files (Scholtes, Mavrodiev and Schweitzer, 2016, Empirical Software Engineering 21(2), 642-683). That finding is contested, and I come back to the dispute below, because it is one of the places where the law fails.

Decisions. A slower kind of stall comes from responsibility rather than effort. In Darley and Latané's best-known experiment, participants who believed they were the only person hearing someone have a seizure reported it before the seizure ended 85% of the time; when they believed four others could also hear it, 31% did (by the end of the study, all of the first group had reported it, against 62% of the second) (Darley and Latané, 1968, Journal of Personality and Social Psychology 8(4), 377-383). A project is not an emergency, and I use this only as the cleanest demonstration of the mechanism: when more people could act, each is less likely to. That is how a task with many collaborators can be fully staffed and still wait.

Machines. The same curve appears in computers, where there is no motivation to lose. Gene Amdahl's 1967 argument bounds the speed-up from adding processors by the fraction of the work that must run in sequence (Amdahl, 1967, AFIPS Spring Joint Computer Conference). Neil Gunther's Universal Scalability Law adds a second term for the cost of keeping shared state coherent, which grows with the number of pairs, and with that term the throughput of a real system does not just level off as you add capacity: past a peak it falls (Gunther, 2007, Guerrilla Capacity Planning, Springer). Gunther calls that retrograde scaling. It is the engineering name for grinding to a halt.

Put together, the evidence supports the stall half of the law well for interdependent work, and it supports one refinement that matters for what follows: in people the stall has a motivational component and a structural one; where they have been separated, the structural one was about half the loss in shouting and a minority of it in rope-pulling, and it is the one that survives when you remove the motivation entirely.

Why they keep coming

If adding people to interdependent work has falling and eventually negative returns, why do tasks keep acquiring them? There are four reasons with evidence behind them, and they share a shape.

People underestimate the cost. Staats, Milkman and Fox named the "team scaling fallacy": as team size increases, people increasingly underestimate the labour hours that a project will need. They found it in two laboratory experiments, one of them a Lego-building task, and in the forecasts for projects at a software company, among outsiders and project insiders alike (Staats, Milkman and Fox, 2012, Organizational Behavior and Human Decision Processes 118(2), 132-142). Conway named the error in 1968 and Brooks in 1975, when he called the man-month "a dangerous and deceptive myth"; Staats and colleagues measured it. If the person deciding whether to add a collaborator systematically underestimates what the addition will cost, additions will overshoot even with nobody acting in bad faith.

Adding is easier to think of than removing. In eight experiments, Adams and colleagues found that people systematically overlook changes that improve something by taking an element away, and that they overlook them more under cognitive load (Adams, Converse, Hales and Klotz, 2021, Nature 592(7853), 258-261). In one example in the paper, about one in ten of the suggestions an incoming university president received proposed removing something. Taking someone off a task is a subtractive change, and the people least likely to think of it are the busy ones running the task.

Joining is credited, leaving is risky. This is the pull that Parkinson and Conway described, and it is a close relative of the game I described for rules in Nobody Is Paid to Delete: where adding is visible diligence and removal carries the risk of being blamed for what goes wrong next, nobody removes. One condition is missing, the one I said did the heavy lifting there: the author of a rule has usually moved on before its cost arrives, while the person who adds a collaborator is usually still on the task. That is why blame, not short tenure, carries this version. For collaborators the game runs in both directions. The person who adds a reviewer, a stakeholder or a second team is protected if things go wrong, because everyone was consulted. The person who joins gains visibility, information and a claim on the result. The person who leaves gains nothing visible and loses the chance to shape what is decided without them. Conway's manager, "vulnerable to the charge of mismanagement if he misses his schedule without having applied all his resources", is the clearest statement of the blame half.

Coping adds people. The organisations I described in Systemic Coping Syndrome seek approvals "to share blame rather than to improve a decision". Every such approval is a collaborator added for a reason that pays the person seeking it. An organisation that copes with its dysfunction by consulting more widely will, by the law of many hands, slow every task that touches the dysfunction, which makes the dysfunction more expensive and the coping more necessary.

The shape the four share is that the decision to add a collaborator is taken by someone whose gain from the addition is private and whose share of its coordination cost is small or invisible to them. That is the whole of the pull. Psychology supplies some of it, through misestimation and subtraction neglect. Incentives supply the rest, through credit and blame. When I first proposed the law, I said that it held "because of human psychology". I now think that is half right. Psychology explains why the person deciding gets the cost wrong. It does not explain why the cost lands on someone else, and that part is structure.

The law as a model

Here is the smallest model I could write that has both halves in it. Each collaborator adds a units of work, and each pair of collaborators costs c units of coordination, so a team of n produces an − c n(n − 1)/2. The definition and three facts about it compile and run on Lean 4.29.1:

/-- Toy model. Each collaborator adds `a` units of work, and every pair of
collaborators costs `c` units of coordination. Output with `n` people. -/
def output (a c n : Int) : Int := a * n - c * (n * (n - 1) / 2)

/-- With a = 10 and c = 1, no team below 40 people beats a team of 10. -/
theorem ten_is_best : ∀ n : Nat, n < 40 → output 10 1 n ≤ output 10 1 10 := by decide

/-- Output falls back to zero at 21 people, about twice the best size. -/
theorem stall_at_twenty_one : output 10 1 21 = 0 := by decide

/-- In general: when a = c·k, output is exactly zero at 2k + 1 people. -/
theorem zero_general (c k : Int) : output (c * k) c (2 * k + 1) = 0 := by
  unfold output
  have h : (2 * k + 1) * (2 * k + 1 - 1) / 2 = k * (2 * k + 1) := by
    have : (2 * k + 1) * (2 * k + 1 - 1) = 2 * (k * (2 * k + 1)) := by grind
    rw [this]; omega
  rw [h]; grind

With a = 10 and c = 1, output peaks at 55 with a team of 10 or 11, and falls back to exactly zero with a team of 21. In general the peak sits at a/c + 1/2 for a team that could be any size, so a/c and a/c + 1 tie when a/c is a whole number, and the zero sits at 2a/c + 1, which the third theorem checks for every whole-number ratio. In this model, the size at which the task produces nothing is twice the size at which it produces most. The first two theorems are checked by evaluation and use no axioms; the third uses Lean's three standard axioms, as most tactic proofs about integers do.

The model so far only says where the best size is. The pull says where the team ends up. Suppose each collaborator is added by someone who weighs a private benefit against the cost to them of the addition, and counts the coordination cost to everyone else at nothing. That is the structure of an open-access fishery, which H. Scott Gordon analysed in 1954: when entry is free and each entrant ignores the cost they impose on the others, boats keep arriving past the point that maximises the fishery's net value, until that surplus has been competed away (Gordon, 1954, Journal of Political Economy 62(2), 124-142).

In the toy model, suppose the reward for each addition is a share of what the task produces, such as credit for the result, and that staying out is worth nothing. Then the 22nd collaborator would get a share of a negative output, so entry stops at 21, where the task's net output is zero. That is Gordon's result in miniature. If the reward does not shrink with the output, as with cover, visibility or a bigger department, nothing in the model stops entry at all, and only an outside cap, such as a budget or a headcount limit, does. Either way the team ends past its best size. Which of the two it is decides what the endpoint looks like: a task that grinds to a halt, or a task held at whatever size the cap allows, still past its best. Grinding to a halt, in this sense, does not mean that the work becomes impossible. It means that the last collaborators' contribution is cancelled by the coordination that they and their predecessors create, and nobody making the additions is paid to notice.

I want to be exact about what that block proves, because I wrote Floating Theories about exactly this. The theorems are checked by Lean's kernel, and they are about the function on the first line and nothing else. The function's two premises are that each person adds the same amount of work and that every pair costs the same amount of coordination. Both are false of any real team, and the second is the floating root: it is the n(n − 1)/2 upper bound treated as if it were the actual coordination load. The proof secures the interior. It does not anchor the model to any team. What anchors the shape, a peak and then a decline, is the empirical work in the previous section, including Gunther's, whose coherency term has been fitted to measured throughput on real systems.

The factor of two is less fragile than the quadratic assumption that produced it. If coordination grows as the number of people raised to any power between one and two, the size at which the task produces nothing is between two and about 2.7 times the best size (the ratio is k^(1/(k − 1)) for a power k), and the agent study I discuss next measured a close proxy for it: averaged across architectures, the total number of reasoning turns grew as roughly the 1.7th power of the number of agents, which the authors attribute to the cost of messages between agents, and which puts the ratio at about 2.1. What nothing anchors yet is whether human coordination grows that way, and the constant in front of it, which decides where the best size is. I include the model because it makes the claim precise enough to be wrong, not because it shows that the claim is right.

Agents: the natural experiment

For seventy years the two sources of the stall have been hard to separate on the work that matters. Computers showed the stall without people, but computers do not write, plan or review. Pseudo-group experiments separated effort from coordination, but only for pulling and shouting. Every team doing knowledge work that showed the stall was also made of people with careers, egos and fear of blame. AI agent systems separate them on that kind of work. An agent has no career to advance and nothing to fear. If the stall in knowledge work is mostly psychology, agent teams should not show it. If it is mostly structure, they should.

They show it. The most careful study I know of evaluated 260 configurations of agent systems across six benchmarks, five architectures and three families of language model, with tools, prompts and compute standardised to isolate the effect of the architecture (Kim et al., 2025, "Towards a Science of Scaling Agent Systems", arXiv:2512.08296). The authors report that the total reasoning-token budget was matched too, which would make a team of agents the same budget divided rather than extra capacity. Compared with a single agent, multi-agent systems improved performance by up to 80.8% on a financial-analysis benchmark whose work splits into independent parts, and reduced it by up to 70% on a planning benchmark with strict sequential dependencies, where every multi-agent variant tested did worse, by 39% to 70% (Google Research blog, 28 January 2026). The number of inter-agent messages per task ranged from 58% more than the single-agent baseline for agents working independently to 515% more for the most connected hybrid design. Once a single agent already solved more than about 45% of a benchmark's tasks, adding agents tended to make things worse. And on one of the paper's two measures of error amplification, the extra work caused by coordination failures, agents working in parallel without any check on each other came to 17.2 times the single-agent level, against 4.4 times for systems routed through a central orchestrator. The authors' own predictive model explains about a third of the variance in the results (a cross-validated R² of 0.373), so this is a map of tendencies, not a law of nature, but the tendencies are clear.

That is Brooks's condition, measured in a population with no psychology: work that splits into independent parts gains from more agents, and work in strict sequence loses. By the authors' account it is a stricter test than Brooks's, because nobody added resources: dividing the same compute among agents that must coordinate was enough to make the sequential tasks worse. Their own efficiency figures suggest the teams spent more tokens than a single agent; if so, more resources made sequential work worse, which is Brooks's law itself. Either way the stall is there. The same paper also varied the number of agents directly. With Gemini-2.0 Flash, performance peaked at seven agents and then fell, although its centralised design scaled more stably, and the authors conclude that coordination overhead eventually outweighs the benefit of parallel work (Kim et al., 2025, Figure 5). The structural half of the law of many hands survives the removal of the people.

There is an equally clean result on the other side, and it is just as important. Li and colleagues found that simply sampling more agents and taking a majority vote improves a language model's performance as the number of agents grows (Li et al., 2024, "More Agents Is All You Need", arXiv:2402.05120). That is not a counterexample. Voting agents never coordinate: each one works alone and the answers are only counted at the end. With no coordination term there is nothing to stall, which is exactly what the model predicts, and exactly Brooks's exception for work that can be partitioned with no communication.

Now the pull. Agents have no motives, but agent systems can recreate the pull mechanically, and it is worth being exact about where. An orchestrator rewarded only on the final result bears every coordination loss through that result, so on its own it is not an open-access case; it overshoots only if it misjudges those losses, which is the team scaling fallacy reproduced in a model. The open-access structure appears in two other places. One is cost outside the reward: if nothing the orchestrator sees counts the tokens, time and money that each sub-agent consumes, another agent looks free when it is not. The other is many spawners: where several agents can each create helpers that share one context or one budget, each decides on a gain it keeps and a cost it shares. When I wrote The Agent Tending Problem, the major coding-agent platforms allowed spawning at most at depth one, which I argued there is the right design. I would now say why. A depth cap does not limit how many agents the orchestrator creates, but it does make the orchestrator the only one deciding, which removes the second structure. It leaves the first untouched.

This is the point at which I part company with my own conversation's framing. The pull is not, at bottom, psychological. It is a property of any system in which the decision to add a collaborator is taken by someone who does not bear its coordination cost, or who cannot see it. Human psychology is one way to produce that property. A spawn function whose cost nobody counts is another.

Where the law fails

A law that does not say where it fails is a slogan. This one fails in at least four places, and I think stating them makes it sharper.

Where the work does not need coordination. Voting agents, independent analyses, picking cotton. Brooks said so in 1975, and the agent studies confirm it. The law applies to interdependent work, and the honest test of whether a task is interdependent is whether the people on it have to read each other's output to do their own.

Where structure makes coordination grow more slowly than the team. The open-source evidence is the most interesting case, because it is genuinely disputed. Against the Scholtes finding of falling productivity, Sornette, Maillart and Ghezzi found superlinear productivity in open-source projects, with output growing faster than the number of active developers across group sizes from 5 to a few hundred (Sornette, Maillart and Ghezzi, 2014, PLoS ONE 9(8), e103023). Their own abstract adds that large groups tend to show smaller superlinearity than small ones. The two groups have argued about samples and measurement since, and a later replication attributes much of the disagreement to how productivity was measured rather than to which projects were chosen (Gut and Goldman, 2024, arXiv:2408.04782). My reading, which is mine and not theirs, is that large projects that work are the ones that have found structures, such as modules, maintainers, review hierarchies and narrow interfaces, that keep the live coordination channels closer to linear in the team size than quadratic. That is not a refutation of the law. It is the law's remedy, discovered in the field. But it means the law is a claim about unstructured accretion, and a well-structured large team is not a counterexample to it.

Where entry is not free. The overshoot depends on the person adding a collaborator not paying for the coordination. Where a single owner who carries the deadline decides every addition, is not rewarded for the size of the team, and is charged for the coordination it creates, the pull is weaker, and the law predicts that such teams will settle nearer their best size. The conditions matter. Conway's overstaffing manager carried the deadline and the budget, and added people anyway, because he was paid in prestige by size and blamed for unused resources. If owners who meet all three conditions do not settle nearer their best size, the pull half is wrong.

Where the extra hands are buying something other than throughput. Wu, Wang and Evans, looking at more than 65 million papers, patents and software products from 1954 to 2014, found that large teams tend to develop existing ideas while small teams tend to disrupt them (Wu, Wang and Evans, 2019, Nature 566(7744), 378-382). Large teams are not failures, and much valuable work needs them. Collaborators also bring training, buy-in, legitimacy and resilience against one person's absence. A task may rationally carry more people than its throughput needs in order to buy those things. The law says only that the overshoot happens whether or not anyone is buying them, because the person making the addition is not asked to say which.

What is new here, and what is not

Most of the parts are old, and the people who got there first deserve naming before anything is claimed. Parkinson described the multiplication of officials and its motives in 1955. Conway connected Parkinson's law to the over-assignment of design work, with the blame motive spelled out, in 1968. Brooks stated the stall for software in 1975, with its exception for partitionable work. Steiner separated coordination losses from motivation losses in 1972, and the social-loafing literature measured the second. Mancur Olson argued in 1965 that, without coercion or selective incentives, larger groups fall further short of providing what their members collectively want, which is the free-rider half of the same structure (Olson, 1965, The Logic of Collective Action, Harvard University Press). William Niskanen modelled the budget-maximising bureau in 1971, and showed that under simple assumptions it supplies up to twice the efficient output, at the point where its net value to the people paying for it is zero (Niskanen, 1971, Bureaucracy and Representative Government, Aldine-Atherton). That is Parkinson's motive with an equilibrium attached, and it reaches the same factor of two by a different route. Gordon modelled open-access entry in 1954. Gunther gave retrograde scaling an equation. Staats, Milkman and Fox showed that people underestimate the cost of larger teams.

Against that, what I think the law of many hands adds is narrow:

1. One mechanism for both halves, applied to coordination among collaborators. Niskanen gave the overshoot an equilibrium for bureaucracies, where the cost being ignored is output that the sponsor does not want. What I add is that the cost being ignored is coordination, that it is ignored most where nothing budgets it, which is participation rather than headcount, and that the same structure appears in software with no motives at all. That one structure explains why teams grow (the pull) and where they stop (no earlier than where the net contribution of the last arrivals is cancelled, if nothing caps them first), and it locates the fix in the decision to add, not in the people added.
2. Separating psychology from structure on knowledge work. Psychology is one source of the pull and much of the human stall, but the stall does not need it. Computers showed that much decades ago, and pseudo-group experiments showed that part of the human stall is coordination rather than effort; AI agents make it testable for the first time on knowledge work, because they remove the psychology and leave the structure, and the early evidence says the stall survives.
3. A prediction for agents. Agent systems in which the cost of adding an agent falls outside the reward of whoever adds it should overshoot their best size the way human teams do, and the remedy that works should be pricing the addition, not improving the agents.

If you prefer an established name, "Brooks's law plus Niskanen's bureau, with coordination as the cost" covers most of it. I keep the new name because the old ones each describe one half: Brooks's law describes what happens after the hands arrive, Parkinson's describes why they arrive, and the useful thing is to see that both are one mechanism.

What exists and what does not

• What exists: the studies cited above, each of which measured what it says it measured in its own setting; the Lean block, which compiles and checks the three stated facts about the toy function and nothing more.
• What does not exist: any measurement of the law of many hands itself. I know of no study that compares open-entry and owner-admitted teams on randomly assigned tasks, and I have not run one. The claim that agent systems with unpriced spawning overshoot is a prediction: the agent study I rely on varied architectures and agent counts, not who pays for spawning.
• What is model, not measurement: the factor of two to about 2.7 between the best size and the stall size, which holds whenever coordination cost grows as a power of the team size between one and two. A cost that is zero until the team reaches some size can give a ratio below two.
• What is illustration: Parkinson's figures, from an essay he wrote as satire.

The strongest objections

"This is Brooks's law with a new name." It overlaps with Brooks, and I have said where. Brooks explains why adding people to a late project makes it later, and he explained part of why they keep getting added: misestimation, the man-month that treats people and months as interchangeable, and "the natural (and traditional) response" to slippage, which he compared to dousing a fire with gasoline. He did not explain why the addition is made by someone who gains from it while others pay for it, and that is the half that survives everyone having read Brooks. His remedies for a late project were to reschedule or trim the task, and, for teams in general, to organise small "surgical" teams that cut the communication paths. The second is structure, and it is remedy 4 below. The law of many hands adds a remedy he did not have: change who pays for an addition.

"Large teams do great things, and open source scales." True, and the Wu and Sornette findings are the strongest evidence against any simple reading of my claim. Where I come down: the law does not say large teams fail. It says unpriced additions overshoot the size the task can use, and successful large efforts are those that have built structures to keep coordination closer to linear. If well-run large teams turn out to have no such structure, and still scale, I am wrong.

"Teams do not visibly grind to zero. Budgets stop them long before." True for headcount, which is why the law is mostly about something else. Hiring is priced: somebody signs off the salary. Participation is not: adding a reviewer, an invitee or a consulted expert costs the person adding them nothing that any budget records. That is where I expect to see the law's endpoint, in the meeting that thirty people attend and nobody can cancel, not in the organisation chart. If participation turns out to be as well controlled as headcount, the endpoint half of the law is wrong.

"Collaboration is valuable for reasons your throughput model ignores." Partly right, and it is why the model is a toy. Training, buy-in and resilience are real goods. I come down on the side of pricing them, not denying them: if a collaborator is on a task for buy-in, say so, and the team can decide whether the buy-in is worth the coordination. What the law objects to is the addition that nobody had to justify.

"It is human psychology after all: agents only show the stall because they were trained on human text." I take this seriously, because language models do imitate human patterns. But the agent study's losses are well explained by mechanisms that need no imitation: messages that consume context, errors that propagate between agents, and sequential tasks that cannot be split. Machines with no training on human text, the multiprocessor computers that Gunther's law was built for, show the same retrograde curve. I think the structural reading is the better one, and the test that would distinguish them is whether the stall shrinks as models improve while the task structure stays the same. The agent study gives a first reading: with its stronger model, the decentralised teams peaked at a smaller size, not a larger one, and the gains from adding agents shrank as the single agent improved. That fits the structural reading, since a stronger single agent leaves less for a team to add, though it does not rule out imitation.

"You build agent systems, so of course you think they need an admission controller." Correct, which is why I have tried to make the claims falsifiable and why the first remedy below costs nothing and applies to human teams.

Predictions

Each of these needs a measure and a horizon.

1. Open entry overshoots. In one organisation, randomly assign comparable new tasks (the same type of work, scoped in advance by someone outside the trial) to open entry, where anyone may add themselves or others, or to owner admission, where one person who carries the deadline admits each collaborator and is not rewarded for team size. Record participants per task, meaning anyone who attended a decision meeting, was asked to review, or was copied on a handover, and cycle time. Over twelve months the open-entry tasks will end with at least a quarter more participants and longer cycle times for the same scope. If participant counts and cycle times do not differ, the who-decides part of the pull is wrong. If open-entry tasks are larger but not slower, the overshoot exists but has not passed the best size, and the endpoint half is wrong.
2. Unpriced spawning overshoots in agents. On one harness and one model, run a fixed set of tasks with verifiable outcomes, for example a sample of SWE-bench Verified. Fix a price per token in advance, stated as a fraction of the value of one verified success, and high enough that the best net size in the sweep is at least two below the size with the most verified successes; at a price near zero the two arms cannot be told apart. First sweep a fixed number of sub-agents, from one to twelve, to find the size with the best net score, meaning verified successes minus the token charge. Then let the orchestrator choose how many sub-agents to create, in two arms: one where the orchestrator is scored on verified success alone and sub-agents' tokens are not counted against anything it sees, and one where it is scored on the same net score and each sub-agent's tokens are charged against it, from a balance it can see. The unpriced arm will create more sub-agents than the best size found in the sweep, and the extra verified successes they bring will be worth less than the tokens they cost; the charged arm will settle within one or two of the best size. If the unpriced arm settles at the best size, the agent half of the law is wrong. If it creates more sub-agents and they are worth their tokens, the overshoot is real but bought something, and the endpoint half is wrong for agents.
3. Free exit speeds tasks. Randomly assign teams in one organisation either to a rule that anyone may leave a task at any time, with the departure recorded but not penalised, or to no rule. Compare tasks of the same type, and score the quality of each result blind, by two raters who do not know the arm. At three months, the free-exit teams will be smaller and will finish comparable tasks faster, with no loss in rated quality. If they do not shrink, the leave-is-risky part of the pull is wrong. If they shrink but do not speed up, the stall half is.

What to do about it

If the overshoot comes from additions that nobody pays for, the remedies have to price the addition.

1. Let the person who pays decide, and make sure they pay. Whoever owns the deadline admits each collaborator, and whoever wants to join asks them. That moves the decision to one person, but it fixes the overshoot only if that person's reward does not grow with the team, and if each addition is charged to them at its real cost. In the toy model that cost is not a flat fee: the n-th collaborator adds c(n − 1) of coordination, one unit for every person already there, so the charge has to rise as the team grows.
2. Admit work, not people. Every addition names the piece of work it will own, and that piece should be checkable without reading everyone else's output. If no such piece exists, the addition is coordination, not capacity. This is Brooks's partitionability test applied at the door. It is also the view of a role I took in From Roles to Morphisms, where a role is a bundle of typed transformations rather than a person: an addition is worth making for the transformation it brings, not for the title or the seat.
3. Make leaving free, visible and the default. A recorded, unpenalised exit is the subtractive change people overlook. Better still, make every place on a task lapse at the next milestone unless the owner renews it, so that removal is the default and staying is the decision. A cue works too: in the first experiment of Adams and colleagues, telling people that removing pieces was free raised the share who found the subtractive solution from 41% to 61%.
4. Coordinate through artefacts, not meetings. A shared document, a typed handover or a test that anyone can run lets people coordinate without each pair talking. If my reading of the open-source dispute is right, structure is what kept the large projects closer to linear.
5. For agents, price spawning and centralise checking. Concretely: the harness gives the orchestrator a token budget it can see, deducts each sub-agent's cap from that budget when the sub-agent is created, returns any unspent tokens when it finishes, and refuses a creation the budget cannot cover. Then score the orchestrator on the value of its verified results minus a fixed charge for every token spent, so that what it leaves unspent counts in its favour and a sub-agent is worth creating only if it adds more than it costs. A budget alone is a cap, and a cap holds the team at the cap, not at its best size; the cost has to enter the score of the agent deciding to create the next one, and it has to enter as a price, not a ratio. Scoring on results per token would be the opposite mistake: in the toy model, output per collaborator is highest with a team of one, so an orchestrator maximising a ratio would turn down help that is worth more than it costs. Then route results through a single checker. In the agent study, coordination failures cost independent agents 17.2 times the single-agent level of extra work, against 4.4 times for agents routed through an orchestrator. That measures wasted work, not wrong answers: the authors found it did not predict success once their other coordination measures were included, and the orchestrator did more than check. It is still the clearest number I know of for what skipping a central check costs in tokens, and the authors' account of why independent agents did worst, each repeating errors with no chance of correction, is the case for the checker.
6. Watch for the workaround. Any headcount rule invites people to route work through collaborators who are not counted: the reviewer copied in, the expert consulted informally, the second agent called as a tool. Count participation in decisions and handovers, not names on a roster, or the rule will move the coordination out of sight without reducing it.

The cost of the next pair of hands

Parkinson's joke was that the number of officials has nothing to do with the work. The serious version is that the number of collaborators on a task is set by the people who add them, at a price that does not include the cost they impose, and so, wherever nothing caps it, it tends to exceed what the work can use. Many hands do make light work, for wheat, for votes, for anything that can be split without anyone reading anyone else's output. For everything else, which is most of the work worth doing, they make heavy work, and the weight is not anyone's laziness. It is the next pair of hands that nobody had to pay for.

About the author: Eduardo Aguilar Pelaez is CTO and co-founder at Legal Engine Ltd. He writes on formal methods, AI agents, and the discipline of building systems that survive being walked away from.