Brooks's Law was never about headcount
Brooks's Law comes from The Mythical Man-Month, published in 1975: "adding manpower to a late software project makes it later" (Brooks's law, Wikipedia). Brooks gave three reasons. New people need time to ramp up, and experienced people lose time teaching them. Communication overhead grows as the team grows. And some work cannot be divided usefully among more people.
The durable insight is that software delivery capacity is not the sum of individual implementation capacity. There is a coordination system around the code, and it has its own costs.
AI changes one side of the equation
Coding agents remove much of what Brooks described as ramp-up. They do not need hiring or onboarding. They explore unfamiliar APIs, write boilerplate, generate tests, and run in parallel. A team of ten engineers can now run dozens of simultaneous agent sessions.
It is tempting to conclude that Brooks's Law no longer applies. That conclusion is only half right. The ramp-up cost has fallen sharply. The coordination cost has not, and the number of contributors that need coordinating has gone up.
This is the second half of a pair. Conway's Law in the age of AI coding agents covers where architecture comes from when agents write code; this piece covers what happens to coordination as agents multiply.
To be clear about scope: Brooks was writing about human teams and schedule compression. His law does not predict how AI agents fail. It is useful as a starting point for a narrower question. What happens to coordination when the marginal contributor is an agent?
The arithmetic Brooks was pointing at
Brooks's communication argument has a simple shape. Among n contributors who all need to coordinate with each other, there are n(n−1)/2 possible pairs. Five people have ten pairs. Twenty have 190. The work grows linearly while the coordination paths grow roughly with the square.
Human teams manage this with structure: team boundaries, interfaces, design reviews, tech leads, and shared conventions. Those mechanisms mostly work through people talking to people.
Agents break that assumption in a specific way. An agent does not attend the design review, ask the tech lead, or remember last quarter's decision. Each session is a contributor that starts without the shared context the human coordination system was built to spread. Adding agents therefore adds contributors to the coordination problem without adding participants to the coordination mechanism.
Parallelism makes the gap visible
Consider one team running five agents at once: one on the API, one on a schema change, one on infrastructure, one on authentication, one on the frontend. Each finishes its own task successfully. Together they introduce two retry abstractions, a second way of reading configuration, a service call that crosses a boundary the team agreed to keep, and a new dependency the platform group had ruled out.
Every individual output looks reasonable. The system still drifts. The individual agents were not wrong. What failed was coordination: no shared, authoritative answer to what had already been decided. The same pattern is analyzed from the distributed-systems side in the next AI infrastructure layer is coordination governance.
From pairwise communication to shared decisions
This is where the Brooks framing becomes practical. Pairwise communication is what grows with the square of contributors. A shared decision corpus does not. If every contributor, human or agent, reads the same authoritative decisions at the moment it changes code, coordination stops depending on who talked to whom. Each new agent adds one reader of the decisions, not n new conversations.
That only works if the decisions are:
- Machine-readable. Architecture that exists only in meetings and prose cannot reach an agent.
- Scoped. An agent needs the decisions that govern the files it is touching, not the whole archive.
- Checkable where possible. Important constraints should not depend on an agent remembering an instruction.
- Traceable. When a change is blocked, the team needs to see which decision blocked it and why.
Implementation speed and decision reach are different measures
Most discussion of AI productivity measures implementation: lines, pull requests, tasks closed. Research tracking hundreds of thousands of developers has already found that more coding activity does not translate one-for-one into shipped releases, as covered in AI throughput is not engineering throughput. The Brooks lens suggests one reason. Implementation capacity scaled. The reach of architectural decisions across contributors did not.
Where Mneme fits
Mneme applies this idea to architectural decisions in a repository. Accepted decisions become scoped rules that return deterministic PASS, WARN, or FAIL verdicts against proposed changes, whichever agent or person proposed them. Its local MCP server, shipped in 0.9.0, lets an agent retrieve the decisions that apply to the paths it is working on and trace a decision's lineage. It is not a general coordination system, and it does not make every architectural judgment mechanical. It makes the decisions that can be shared and checked available to every contributor at once.
Brooks's Law did not disappear
Brooks identified a constraint on software development: coordination does not scale as easily as production. AI made production dramatically cheaper. That does not invalidate Brooks. It makes the coordination side of his argument the part that decides outcomes.
The organizations that scale agentic development successfully may not be the ones with the most coding agents. They may be the ones that make architectural decisions easiest for every agent to discover, interpret, and obey.