Summary: Four laws written between 1967 and 1975, all about human organizations and processors, predict why multi-agent AI systems stall as they scale. Brooks's Law (1975) explains why adding agents adds coordination cost quadratically, fifteen communicating agents means 105 possible conversations. Amdahl's Law (1967) caps the speedup any number of parallel agents can deliver once a serial merge or certification step exists. Conway's Law (1968) explains why agent architectures split along departmental boundaries rather than workflow boundaries, and fail exactly there. Gall's Law (1975) explains why a twelve-agent architecture designed on a whiteboard on day one is structurally more likely to fail than one grown from a working three-stage system.

In brief: This is the second installment covering laws behind a 49-part series, drawn from two production systems, a legacy ETL migration platform that grew to fifteen specialized agents, and a natural-language query platform referenced in earlier installments. The first five laws, covered in 5 Laws of AI Agents: From Postel's Law to Ashby's Law of Requisite Variety, dealt with what an individual agent should trust and how review councils should be built.

In This Article:

• Brooks's Law: coordination cost grows quadratically with agent count
• Amdahl's Law: parallel agents are capped by the serial fraction
• Conway's Law: agent architectures mirror org charts, including their failures
• Gall's Law: complex agent systems have to evolve from simple ones that worked
• What Current Research Says About Multi-Agent Scaling

Four Laws That Explain Multi-Agent Orchestration at Scale

Each law below predates AI agents by decades, and each one maps to a specific, recurring failure mode in multi-agent systems built today.

Law	Origin	Core statement	Design implication for agents
Brooks's Law	Fred Brooks, 1975, The Mythical Man-Month	Adding manpower to a late software project makes it later; coordination cost grows as n(n-1)/2	Every new agent that talks to existing agents adds channels quadratically, not linearly
Amdahl's Law	Gene Amdahl, 1967	Speedup from parallelism is capped by the fraction of work that remains serial	A merge, validation, or certification step you never profiled is your real speed limit
Conway's Law	Melvin Conway, 1968, Datamation (named by Brooks, 1975)	Organizations design systems that mirror their own communication structures	Agent boundaries drawn from an org chart fail exactly where the org chart fails
Gall's Law	John Gall, 1975, Systemantics	A complex system that works is invariably found to have evolved from a simple system that worked	A twelve-agent architecture designed before anything runs is structurally doomed

Brooks's Law: coordination cost grows quadratically

Problem: A document pipeline lags, so the team adds six more agents. Cross-agent messages triple, each handoff re-serializes context, disagreements need reconciliation rounds, and end-to-end latency ends up worse than before the "scaling."

That is close to what happened on a legacy ETL migration platform built to convert thousands of jobs into governed pipelines on a modern data stack. It started as three stages: discover, convert, validate. Reality then demanded capability, graph parsing, metadata analysis, lineage, security scanning, complexity scoring, code and test generation, a reviewer council with an arbiter, until the platform passed fifteen specialized agents. Every agent earned its place. What also grew was the conversation count: Fred Brooks wrote the formula in 1975, channels grow as n(n-1)/2, so fifteen communicating agents means 105 possible conversations.

In fig. Brooks's Law applied to multi-agent coordination, adding agents adds communication channels quadratically unless the architecture removes cross-talk.

Solution: The fix is not fewer agents, it is fewer conversations. The platform runs on a shared, canonical knowledge model: every analysis agent publishes evidence into it, every downstream agent reads from it, and the parsing agent never talks directly to the security agent. The operating rules that fell out of this:

• Work is sharded into independent lanes with zero cross-talk between them
• Agents publish to the shared model and read from it, never from each other
• Where a handoff must exist, it crosses a narrow typed contract
• Reviewers judge evidence in parallel; one arbiter integrates
• A new agent is admitted only if it adds zero new mandatory conversations

Note: Brooks wrote about humans, and agents change his law in both directions. Worse, because context serialization makes every agent handoff expensive by default. Better, because agents accept whatever communication structure is imposed on them. People resist being told who they may talk to. Agents do not mind.

Amdahl's Law: parallel agents are capped by the serial fraction

Problem: Ten research agents run in parallel, but one orchestrator serially reads and merges all outputs, then serially validates. Adding ten more agents changes nothing, the merge step still dominates total latency, and costs double for identical speed.

Analyzing a legacy estate of thousands of ETL jobs is embarrassingly parallel work, parsing, metadata extraction, lineage, and security scanning can all run independently, and adding parsers genuinely helps. But every migration converges into the same corridor afterward: evidence assembly, code generation, validation, the reviewer council, the arbiter, a trust score, certification. That corridor exists because certification requires one accountable decision. Gene Amdahl wrote the law for exactly this shape of problem in 1967.

In fig. Amdahl's Law applied to agent orchestration, the bottleneck is the conductor, not the orchestra.*

Solution: The serial corridor is not a defect. Governance is supposed to converge to one accountable verdict, that is what makes it governance, so the goal is to make the governed moment as cheap as possible rather than to delete it:

• The council reviews one canonical evidence model, never raw agent outputs, so judging is reading, not interpreting
• Deterministic conversion rules shrink ambiguity before review
• Dozens of evaluation dimensions compress into one trust score instead of a debate
• Validation streams alongside generation instead of waiting for it
• Certification is hierarchical: independent modules certify first, full pipelines certify from certified parts
• Strict output contracts make evidence merging mechanical instead of interpretive

Note: Amdahl has a well-known rebuttal, Gustafson's Law (1988), which argues you should scale the problem instead of the ceiling. That holds for workloads that grow with capacity. For a fixed job, certify this estate, ship this answer, Amdahl's ceiling is the one that applies, and the serial fraction is the speed limit.

Conway's Law: agent architectures mirror org charts

Problem: Three departments each build an agent for their slice of order management. A customer request crossing all three stalls at every boundary: incompatible context formats, unclear ownership, and escalations that mirror the org's own turf disputes.

This is the one law in the series whose root cause sits outside the code entirely, which is exactly why no prompt change, model upgrade, or orchestration trick fixes it. Different teams owning different parts of a legacy estate, infrastructure, ETL, security, governance, testing, operations, each ship their own agent for their own slice. A migration then has to walk the same corridor as an inter-departmental memo, and every handoff changes context format, loses information, and waits on an approval. The failures land exactly on the boundaries between agents, which are exactly the boundaries between teams. Melvin Conway published the underlying observation in 1968, after Harvard Business Review rejected it for being unproven; Fred Brooks named it "Conway's Law" in the same 1975 book that carried Brooks's Law.

In fig. Conway's Law applied to multi-agent boundaries, agent seams land exactly where organizational seams already exist.*

Solution: The migration platform drew agent boundaries from the workflow lifecycle, discovery, parsing, metadata, evidence assembly, generation, validation, certification, rather than from the ownership map, since no department owns a "graph parsing" function. This is the inverse Conway maneuver: design the boundaries the workflow demands, then align ownership to those boundaries. A simple test applies to any existing system: for every boundary between agents, ask whether the workflow demanded that boundary or a team did, then check whether failures cluster on the second kind.

Note: the inverse Conway maneuver is easy to state and hard to execute, since redrawing agent boundaries usually means redrawing ownership, and most architects do not hold that authority. The minimal version that needs no reorg is standardizing the context contract every team's agent must speak. Teams cannot always be merged. The language they use to hand off work can always be merged.

Gall's Law: complex systems evolve from simple ones that worked

Problem: A team designs a swarm up front: planner, router, critic, executor, memory manager, reviewer. Failures are emergent, no single agent is ever at fault, debugging is archaeology, and the demo never stabilizes into production.

A complex system designed from scratch does not get patched into working, it has to be restarted as a simple system, per John Gall's 1975 corollary in Systemantics. The migration platform that reached fifteen agents began as three boxes: discover, convert, validate, complete and working end to end. Every subsequent agent solved a measured problem: parsing legacy graphs got hard, so a parsing agent followed; business metadata kept surprising conversion, so a metadata agent followed; coordination between specialists strained, so the shared knowledge model arrived; certification needed multiple perspectives, so the reviewer council came last, not first. The council that looks most deliberate in an architecture diagram was, in production, the final addition, not the first.

In fig. Gall's Law applied to multi-agent design, working complexity is grown from a working simple system, never designed directly.

Solution: For every agent in an existing architecture, name the measured bottleneck that justified its existence: a latency number, a quality gap, a cost line, anything observed. If the honest answer for any agent is "the diagram looked incomplete without it," that agent is a Gall's Law violation waiting to surface as an incident.

Note: Gall does not forbid complexity. Both systems referenced across this series ended up genuinely complex and needed to. What Gall forbids is starting there. Complexity is a destination a system earns, never an address it launches from.

What Current Research Says About Multi-Agent Scaling

Three of these four laws now have direct, independent confirmation in 2024-2026 AI agent research, not just the historical record.

A 2025 study evaluating 180 multi-agent configurations across five architectures found that decentralized, independent-agent setups amplify errors 17.2 times compared to 4.4 times for centralized coordination, and that multi-agent communication overhead grows superlinearly as agent count increases, direct empirical confirmation of Brooks's Law in modern LLM systems. A 2026 technical analysis applying Amdahl's Law directly to AI-assisted engineering work concluded that the serial review and merge step, not the number of parallel agents, sets the ceiling on real throughput, the same conclusion the migration platform's certification corridor forced on this build. And on Gall's Law, two of the most-cited primary sources in agent engineering reached the identical conclusion from opposite starting points: Anthropic's December 2024 "Building Effective Agents" guide states plainly that teams should find the simplest solution possible and increase complexity only when needed, while Cognition's 2025 "Don't Build Multi-Agents" post argues single-agent architectures with full shared context outperform prematurely decomposed multi-agent ones. Both companies arrived there independently.

Conway's Law has no dedicated 2024-2026 AI-agent-specific study yet, though it remains one of the most repeatedly confirmed findings in general software engineering research, and nothing about agent-authoring teams suggests the underlying mechanism stops applying just because the system being designed is a set of agents rather than a set of services.

Where to start

Coordination, serial bottlenecks, team boundaries, and premature complexity rarely show up as a single bug report. They show up as a system that got wider without getting faster, and by the time that's obvious, the architecture is already load-bearing.

The shared knowledge model that resolves Brooks's Law here is the same evidence-based pattern detailed in The Complete AI Architecture and Why Enterprise AI Needs 18 Architectural Maps & One Unified Control Plane, applied here at the level of agent-to-agent coordination rather than governance tiers.

If your agent count is climbing and nobody has measured which conversations are actually necessary, talk to Tarento's Generative & Agentic AI team about what a coordination audit would find.