Frederick P. Brooks Jr. wrote it in 1975, after managing IBM’s OS/360 project: “Adding manpower to a late software project makes it later.” Fifty years on, you can spin up nine AI agents before your coffee cools. No onboarding, no stand-ups, no politics. So the law should be dead. It isn’t. Nine agents still can’t deliver a baby in one month, and point them at one codebase without clear orchestration and they will cheerfully rewrite each other’s work at machine speed.

The overhead didn’t vanish, it moved. Someone still has to define “done”, review the output, and catch the hallucinations. That someone is you, and in most manufacturing AI pilots, that is exactly where things stall. Here is what the new bottleneck looks like on a factory floor, and how to clear it.

Four People, One Laptop, Zero Progress: The Coordination Trap Hasn’t Changed

Last weekend, four people crowded around a laptop trying to get it to talk to a screen. Someone asked a fifth person to help. The answer: “Haha sorry no! My experience is that adding more people will not solve this problem any quicker”. That instinct is correct, and it is worth more than most project plans.

In 2026, the assumption on factory floors and in quality departments is that agents make headcount math irrelevant. Spin up more, go faster. Teams piloting this are finding something else: the same coordination failures they had with people, now arriving in minutes instead of weeks.

Brooks’s Law and AI agents are not in conflict. Speed just made the old failure mode harder to spot before it costs you a quarter.

What Actually Disappears When You Swap People for Agents

Give the AI case its due, because a large part of it is real. Agents carry none of the overhead that makes human scaling expensive. No two-week ramp-up on your document structure, no handover notes, no one leaving mid-project and taking the context with them. As the source puts it, an agent “is up to speed in milliseconds and doesn’t demand a coffee break.”

For a quality or operations team, that changes the economics of a specific class of work: tasks that were never hard, only blocked. Think deviation write-ups waiting on the one person who knows the product history. Supplier audit prep that sits in a queue because two people are on holiday. CAPA documentation that stalls for a week because the engineer who ran the investigation is on the line. None of these were limited by thinking capacity. They were limited by human availability and the cost of transferring context from one head to another.

Agents genuinely dissolve that constraint. Context transfer costs nothing when the context is a prompt, a procedure document, and a data source. Run twenty of these in parallel and you get twenty outputs, because the tasks were independent to begin with. Nobody needs a stand-up to coordinate twenty separate deviation drafts.

The practical test is simple. Ask whether the task failed because people did not know enough, or because the right person was not free. If the answer is availability, parallel agents will produce a real speed-up and it will show up in cycle time within weeks. Batch release reviews, first-pass documentation, trend summaries across production lines, specification cross-checks: all of these are genuinely parallel work that human teams were running in series for organisational reasons, not technical ones.

That is the honest version of the upside, and it is substantial. It is also narrower than most vendor decks suggest, because the work that actually holds up your quality system rarely falls into this category.

The Baby Problem: Sequential Work Stays Sequential

Some work cannot be compressed by adding capacity. Brooks called it the baby problem, and it holds exactly as well in a cleanroom as it did in software. A 72-hour sterility test takes 72 hours. A three-day stability pull happens on day three. An equipment qualification needs IQ signed before OQ starts, and no amount of compute moves that boundary.

Manufacturing is full of these hard sequences. CAPA effectiveness checks require elapsed production time. Supplier qualification waits on an audit date someone else controls. Root-cause work depends on the next occurrence of a defect you cannot schedule. Agents do not change physics, regulation, or other people’s calendars.

Mapping which steps in your process can actually run in parallel

Take one process and write out every step with its real constraint next to it. Not “takes two days”, but why it takes two days. You will usually find three categories, and only one of them is a candidate for agents.

• Hard-sequenced: physics, regulation, or a dependency on a prior output. Incubation, cure time, signature order under your QMS.
• Soft-sequenced: done in order out of habit or template design, with no technical reason. Most document assembly sits here.
• Genuinely parallel: evidence gathering, trend pulls, literature and historical complaint searches, draft generation across multiple sections.

Be honest in that second category, because that is where the gains live. Plenty of quality workflows are sequential only because a single person was doing all the steps.

Why throughput gains plateau when the sequential core is untouched

If your investigation takes 40 days and 32 of those are waiting on a retest, automating the write-up saves days, not weeks. The sequential core sets your floor. Everything parallel you optimise approaches that floor and then stops.

This is where pilots get declared disappointing. The agents performed. The cycle time barely moved, because nobody checked which constraint was actually binding before the build started. Measure the sequential core first, then decide whether the project is worth running at all.

Overhead Didn’t Vanish, It Moved to You

Every hour of coordination you stopped spending on people, you now spend on agents. Defining the task, checking the output, spotting the confidently wrong answer, merging three partial results into one usable document. None of that is automated away. It lands on one person, usually the most senior person in the room, which is the worst possible place for a bottleneck.

The failure mode is well documented in software and it transfers directly. Point nine autonomous agents at a single codebase without crystal-clear orchestration and they will happily rewrite each other’s work in a high-speed loop. Swap the codebase for a validation protocol or a supplier file and you get the same mess, with the added problem that nobody notices until an auditor does.

“Adding agents to a project with unclear requirements gets you the wrong answer faster.”

Writing an acceptance definition an agent can’t misread

“Done” cannot mean “looks right”. It has to be a checkable list. For an AI-assisted deviation workflow that means: which fields must be populated, which source documents are authoritative, which phrases are forbidden, what evidence must be cited for each claim, and what the output must not do (invent a batch number, infer a root cause, close an action).

Write it once, in the prompt and in your SOP, and make it the same text in both places. If two reviewers would disagree about whether an output passes, the definition is too loose and the agents will exploit the gap.

Budgeting human review time as a hard constraint, not an afterthought

Review capacity is your real throughput ceiling. If your quality lead can review twelve AI-drafted records a day, running agents that produce eighty creates a queue, not a gain. Count the hours before you count the agents.

Treat it like line capacity. Measure minutes per review, set a weekly cap, and only add agent volume once review time per item drops through better acceptance criteria. Scale the definition first, the agent count second.

The 2026 Update: Unclear Requirements Now Fail Faster

The source lands on a reformulation worth pinning above your desk:

“Adding agents to a project with unclear requirements gets you the wrong answer faster.”

Read that as a shift in what constrains you. For thirty years, the limit on process improvement work was labour capacity: not enough analysts, not enough engineering hours. That limit is largely gone. What binds now is specification quality, and most manufacturing organisations have never had to be precise about it because humans quietly filled the gaps.

Agents do not fill gaps. They guess, plausibly, at scale. A vague brief that a junior engineer would have questioned becomes forty pages of confidently wrong deviation analysis before lunch.

Three questions to answer before you add another agent

1. What does “done” look like, in writing?: Acceptance criteria specific enough that two people reading them would reject the same output. If you cannot write it, the agent cannot hit it.
2. Who orchestrates?: One named person owns task decomposition, merge decisions, and final sign-off. Not a committee, not a steering group.
3. What is our review throughput?: Count how many agent outputs your reviewer can actually verify per day. Cap agent count at that number until it proves out. Adding capacity above your review ceiling just builds a queue.

Then fix what you measure. Total task volume flatters every pilot, because agents generate volume effortlessly. Measure cycle time against the sequential core instead: the irreducible chain of waits, approvals, and elapsed-time steps that no amount of parallelism touches.

Good ROI under these conditions looks unglamorous. Batch release cycle time drops because documentation is ready when the test result lands, not three days after. CAPA closure dates hold because the writing is no longer the lagging step. Your senior quality people spend their weeks on investigations and supplier risk rather than formatting.

That is the honest version of Brooks’s Law for AI agents. Clarity scales. Headcount, human or synthetic, does not.

Source: j11g.com