This result comes from a set of experiments that tested four distinct coordination architectures against the same task using the same underlying model: a single agent working alone, a hierarchical system with a coordinator delegating to specialists, a swarm of concurrent agents operating on a shared filesystem, and the sequential pipeline described above. The results were monotonically correlated with coordination complexity. The single agent scored twenty-eight out of twenty-eight. The hierarchical system scored eighteen. The swarm scored nine. The pipeline scored zero. The same intelligence, the same task, the same tools. The only variable was how the work was organized, and that variable accounted for the difference between perfect and worthless.
These experiments are worth examining in some detail, not because they represent the state of the art in multi-agent systems, which will have advanced considerably by the time you read this, but because the failure modes they reveal are structural rather than technological. They arise from information-theoretic constraints that operate regardless of how capable the individual agents become, and understanding those constraints is the difference between using AI tools effectively and producing expensive, confident garbage.
The most common explanation for why AI produces poor software is that the models are not good enough yet. This explanation is comforting because it implies the problem will solve itself. Models will improve, context windows will expand, reasoning capabilities will deepen, and the failures that plague current implementations will recede like bugs in a maturing codebase. There is some truth in this view; the models are in fact improving rapidly, and many of today’s specific failure modes will not survive contact with next year’s releases. The trouble with this explanation is that it accounts for the wrong failures.
The experiments described above were not conducted with weak models. They used frontier language models capable of building the entire system correctly when given the opportunity to do so without coordination overhead. The failures did not arise from the model’s inability to write correct code. They arose from the way coordination between agents, and between agents and evaluation mechanisms, introduced systematic distortions that degraded the quality of the overall output. These distortions have names in information theory. They have known properties. And they do not get better when the underlying model improves, because they are properties of the coordination architecture, not the model.
Consider what happened in the hierarchical experiment, the architecture that scored eighteen out of twenty-eight. A root agent was given the task and instructed to decompose it, delegate subtasks to leaf agents, and integrate the results. Instead of delegating, the root agent implemented the entire system itself, effectively defecting from the hierarchical architecture and operating as a single agent within a hierarchical frame. This was a rational decision: the root agent judged, correctly, that delegation would introduce communication overhead and reduce the quality of the output. The resulting implementation scored eighteen rather than twenty-eight because the hierarchical infrastructure imposed constraints, per-agent iteration limits, reduced context, that the root agent could not escape even after choosing not to delegate. The architecture designed to improve quality through division of labor actively prevented the quality that a single agent could have achieved.
The swarm experiment, scoring nine out of twenty-eight, revealed a different class of failure. Eight agents operated concurrently on a shared filesystem, self-assigning tasks from a shared board, with no central coordinator. They built five of the seven required services, which sounds like reasonable progress until you examine the integration points. Every service boundary was incompatible. Half the agents used snake_case naming; the other half used camelCase. Error response shapes differed between services. Type definitions were inconsistent. The Event Service contained two incompatible type systems within the same service, written by different agents who had both contributed to the same files without reading each other’s work. The agents produced a hundred and fifty-two files, nearly two and a half times what the single agent needed, and none of the cross-service integrations worked. Volume without coherence. Parallelism without shared conventions. The architecture generated enormous output and no value, because the output could not be composed into a functioning system.
• • •
The pipeline experiment, the one that scored zero, is the most instructive failure of the four because it demonstrates a phenomenon that anyone who has worked in a large organization will recognize immediately, transplanted into a system with no human psychology, no ego, no office politics, and no career incentives. The pipeline had eleven stages: diagnose, decompose, architect, locate, execute, test, verify, review, and several stages of sub-decomposition. Each stage was a gate. The output of one stage became the input of the next, and the next stage could approve it, reject it, or escalate it. The system was designed to ensure quality through progressive refinement, with each gate filtering out errors and enforcing standards.
In a separate run of a similar pipeline architecture on a more complex version of the task, the code review stage rejected seven of eight submissions, an eighty-seven percent rejection rate. Four of those rejections contained zero factual issues. The reviewer identified no bugs, no logical errors, no security vulnerabilities, nothing that would prevent the code from working. Instead, each rejection listed between fifteen and twenty-three subjective objections: naming preferences, structural opinions, stylistic disagreements. The Event Service was designed five times, went through three complete architectural iterations, cost nearly twelve dollars of the fifty-dollar budget, and ultimately was rejected for reasons that had nothing to do with whether it functioned correctly.
The verification stages were equally revealing. Nine verification runs all reported the same result: the code compiled successfully, zero tests were executed, zero tests passed, zero tests failed. The verification mechanism certified correctness without testing anything. It consumed pipeline slots, generated approval artifacts, and provided zero information about whether the code worked. Downstream stages treated this certification as evidence of quality and conditioned their behavior accordingly. The system had, without anyone designing it to, independently invented the compliance audit.
The researchers attempted six distinct countermeasures to address these dysfunctions. They classified reviewer objections into factual and subjective categories, hoping that surfacing the distinction would reduce baseless rejections. They added perspective-shift prompts that asked reviewers to reconsider after factual bugs were fixed. They implemented a two-level escalation system with a project-level arbiter instructed to be pragmatic and an architect-level arbiter instructed to force approval when necessary. They added scoped sub-pass reviews to prevent scope creep. They added anti-bikeshedding directives that explicitly told reviewers not to reject over naming conventions. They added Lyapunov stability monitoring to detect when the pipeline was thrashing.
All six countermeasures failed. The classification mechanism correctly identified that rejections had zero factual basis, but the pipeline still treated rejection as a binary gate. The escalation system produced a governance conflict: the project arbiter rejected a component and the architect arbiter force-approved the same component twenty-eight seconds later, each operating rationally within their own frame, producing contradictory outcomes on identical evidence. The anti-bikeshedding directives were issued as prompts, but the architectural incentive to reject, the reviewer’s being evaluated on whether it caught problems, overwhelmed the prompt’s instruction not to invent problems where none existed. The stability monitor detected oscillation but did not halt execution.
The Availability Service entered a backward spiral: build, test, verify, review, reject, re-architect, rebuild, reject again, re-architect again, rebuild again, budget exceeded. Total cost for that single component: nearly eighteen dollars, the highest of any service, consumed entirely by the process of disagreeing about an implementation that the underlying model could have built correctly in one pass.
• • •
The countermeasures failed because they addressed individual agent behavior while the dysfunction was a property of the system’s architecture. Telling a reviewer not to bikeshed is a prompt-level intervention. The incentive to bikeshed is structural: a reviewer who approves code that later fails appears negligent, while a reviewer who rejects code appears rigorous regardless of whether the objections have merit. The incentive is an emergent property of the architecture, specifically of the fact that evaluation and production are asymmetrically punished. The agents were individually following locally rational strategies that produced globally irrational outcomes, and no amount of additional instruction to the individual agents could change the structural incentive.
This pattern, locally rational behavior producing globally dysfunctional outcomes through structural incentives, is what organizational theorists have studied in human institutions for decades. What makes the AI experiments significant is that they demonstrate the pattern in a system with no human participants. The pipeline contains no ego, no career anxiety, no desire to appear competent or to protect territory. The agents are instances of the same model, running with the same weights, differing only in their position within the architecture and the prompts that define their role. The dysfunction emerges from the architecture itself: from the fact that compressing a high-dimensional code artifact into a low-dimensional review verdict loses information, from the fact that selection pressure at each gate optimizes the gate metric rather than the final objective, from the fact that adding coordination layers between a capable agent and its task cannot add information but can lose it.
These are theorems. The principle is intuitive: every time information passes through a processing step, some of it is lost, and no subsequent processing can recover what was lost. The Data Processing Inequality states that for any processing chain, the information available at the output is at most equal to the information available at the input, and in practice is strictly less. Every gate in the pipeline compresses the rich, high-dimensional information of the actual code into a low-dimensional verdict: approve, reject, escalate. Every subsequent stage operates on that compressed signal, not on the original code. The information lost at each compression cannot be recovered by processing the compressed signal more carefully, adding more sophisticated reviewers, or building more elaborate governance hierarchies. The information is gone. This is why the single agent, operating with full context and no coordination overhead, outperformed every multi-agent architecture. It was the only configuration in which no information was lost to compression between stages.
Crawford-Sobel’s theory of strategic communication provides the second piece of the explanation. When two parties have different goals, each message between them carries less information than it would if their goals were aligned. When two parties have even slightly different incentive functions, communication between them degrades in predictable ways. A reviewer whose role is to find problems and an implementer whose role is to ship code have structurally different incentive functions, even when both are instances of the same model pursuing the same nominal objective. The reviewer’s incentive function rewards rejection, appearing thorough, and punishes approval, risking blame. The implementer’s incentive function rewards approval, making progress, and punishes rejection, requiring rework.
These incentive differences are consequences of the architectural roles themselves, and they produce signal degradation at every communication boundary. The twenty-eight-second governance conflict, in which two arbiters reached opposite conclusions on the same evidence, is Crawford-Sobel degradation operating within the governance architecture designed to correct Crawford-Sobel degradation in the review process. The cure contained the disease.
• • •
There is a tempting response to these findings, which is to conclude that multi-agent architectures are premature and that single-agent approaches are simply better. This conclusion is half right and worth qualifying carefully. For tasks that fit within a single agent’s context window, a single agent with full context does in fact outperform every multi-agent alternative tested. This is a strong finding, and it is likely to remain true for some time: the information-theoretic constraints that cause multi-agent degradation are permanent features of any architecture that divides work across agents with separate context, and increasing model capability does not address them. The argument for multi-agent architectures has never been that they are better for tasks a single agent can handle. It is that some tasks exceed what any single agent can hold in context, and for those tasks, the question is not whether to divide the work but how to divide it in ways that minimize the information loss.
The experiments suggest that the answer has more to do with the design of the coordination mechanism than with the number of agents or the sophistication of the prompts. The swarm architecture, despite scoring only nine out of twenty-eight, demonstrated something the pipeline did not: it produced working services, just not interoperable ones. The failure was at the boundaries, in the absence of shared conventions and interface contracts, not in the individual components. A swarm with mechanical coordination guarantees, where shared conventions are enforced by the environment rather than negotiated through dialogue, would address the specific failure mode without introducing the evaluation-stage dysfunctions that consumed the pipeline. The pipeline failed precisely because it tried to ensure quality through agent-to-agent evaluation, which is the mechanism most susceptible to the information-theoretic degradations described above. An architecture that replaces evaluation with mechanical verification, pass/fail tests rather than subjective review, removes the primary channel through which dysfunction enters the system.
This is not a speculative claim. The researchers tested a fifth configuration: a contract-first architecture in which agents communicated through typed interface contracts and mechanical test verification rather than through subjective review. The result was instructive in a different way. The system did not reproduce the bikeshedding, the verification theater, or the governance conflicts. It produced a new dysfunction instead: specification perfectionism. The contract-generation phase entered its own oscillation, producing increasingly elaborate specifications, six hundred and seven lines of JSON for a four-function module, while consuming the budget that should have been allocated to implementation. The dysfunction migrated from the evaluation phase to the specification phase. It changed form without disappearing.
This finding is the one that elevates the research from an engineering case study to something closer to a physical law. Dysfunction in coordination systems is a structural property that emerges from the interaction of compression, selection, and proxy optimization, and it manifests wherever there is a measurable intermediate representation that can be optimized at the expense of the final objective. The form of the dysfunction depends on the architecture. The existence of the dysfunction does not. Any system that coordinates work through intermediate artifacts, whether those artifacts are review verdicts, test suites, specification documents, or Jira tickets, creates a surface on which Goodhart’s Law can operate, and Goodhart’s Law states that the optimization of any proxy metric eventually diverges from the optimization of the actual objective.
• • •
The practical implication of all of this for the working engineer is straightforward, even if the information theory behind it is not. The failure modes of AI-assisted development are failures of coordination design: how work is divided, how quality is assessed, how information flows between components, and what incentives the architecture creates for the agents operating within it. These are the same failures that plague human engineering organizations, manifesting through different surface symptoms but driven by the same underlying forces. The METR developers were slower because the cognitive architecture of their interaction with the tools, the pattern of generating, reviewing, accepting, rejecting, and revising, introduced coordination overhead that consumed the productivity gain. The pipeline agents failed because the pipeline turned code production into a negotiation, and negotiations have costs that compound with each additional party and each additional gate.
Understanding these failure modes is what separates engineering from what the industry has begun to call “vibe coding,” the practice of interacting with AI tools on the basis of intuition, adjusting prompts until the output looks right, and treating the resulting code as production-worthy because it appears to function. Vibe coding fails for the same reason that building without load calculations fails: not because the individual components are necessarily wrong, but because the absence of structural understanding means there is no way to predict which failures will occur, no way to detect them before they compound, and no way to design the process so that they are prevented rather than discovered.
The engineer who understands information loss at coordination boundaries, proxy optimization in evaluation systems, and the structural impossibility of quality-through-review-gates does not need to memorize a list of anti-patterns. They can derive the anti-patterns from the physics, and they can design architectures that avoid them by construction rather than by vigilance.
The physics does not care whether the agents are silicon or carbon. It does not care whether the coordination architecture was designed by a systems researcher or emerged from a decade of organizational accretion. The constraints are mathematical, the degradation is predictable, and the solutions are structural. An engineer who understands why the pipeline consumed its budget arguing with itself can look at a human organization’s review process and see the same forces operating through different surface symptoms. An engineer who does not understand the forces will build the same pipeline, in code or in org charts, and be surprised each time when it produces the same result.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Canary Islands
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
