Skip to content
All articles

Hundreds of agents do not make an organization

  • Agentic AI
  • Organization
  • Research

Compute is easy to parallelize. Coherence is not. Experiments from Cursor, Anthropic and OpenAI are rediscovering what organization theory has known for decades, while running into a problem human organizations never had to solve: agents built from the same models can share the same mistakes.

Twenty agents, the throughput of two or three

In January 2026, Cursor described an experiment that looked less like an artificial intelligence demo than a familiar distributed-systems incident.

The team had peer agents working on the same project. Each agent inspected a shared file, picked a task, updated its status and used a lock to prevent two agents from claiming the same work. On paper, the mechanism was simple. In practice, agents held locks for too long, forgot to release them and sometimes tried to acquire locks they already owned. The mechanism meant to coordinate the work became work in its own right.

The result was stark. With twenty agents, Cursor observed effective throughput equivalent to only two or three. Most of the time was spent waiting.1

The problem was not the agents’ intelligence. It was their organization.

The episode is recent, but the idea is not. In 1975, Frederick Brooks famously argued that adding people to a late software project can make it later. The reason has less to do with individual competence than with dependencies, communication and integration costs.2 Agents are not exempt from that constraint. They simply let us reproduce it at a speed and scale that were previously difficult to observe.

What parallelizing really means

Not all work can be divided in the same way.

Some work consists of branches that can progress almost independently. Researching twenty companies, browsing a thousand documents, testing distinct hypotheses or running large batteries of cases are good candidates. Each branch can produce something useful without continuously waiting for the others.

Other work is coupled. One architecture decision changes the constraints on all the others. Two people rewriting the same section of a report interfere with each other. Several agents editing the same files must reconcile their changes. Adding executors does not make those dependencies disappear.

Amdahl’s law described this ceiling for parallel computing in 1967: the fraction that must remain serial eventually limits total speedup.3 The same intuition applies to work. One hundred people can inventory one hundred libraries in parallel. They cannot all rewrite the same page at the same time without someone eventually deciding which version survives.

This does not mean multi-agent systems perform poorly. Anthropic reported a 90.2% gain on its internal research evaluation with an Opus 4 lead agent and Sonnet 4 subagents compared with Opus 4 alone.4 The use case matters. These were breadth-first questions that naturally decompose into independent branches, such as identifying the board members of a large set of companies.

The cost is just as instructive. Anthropic reports that agents use roughly four times as many tokens as ordinary chat interactions, while its multi-agent research system uses about fifteen times as many. Token usage alone explained 80% of performance variance on BrowseComp. More importantly, Anthropic notes that coding usually contains fewer truly parallelizable tasks than research, and that domains requiring a shared context or involving many dependencies are a poor fit for this architecture.4

Claude Code’s documentation makes the same point in practical terms: for sequential tasks, concurrent edits to the same files or dependency-heavy work, a single session or subagents are often more effective.5

Multi-agent systems work, sometimes remarkably well. The real question is what work we give them.

Decomposition becomes the scarce product

A useful orchestrator is therefore more than a task dispatcher. Its essential job is to create a decomposition in which branches are independent enough for simultaneous execution to produce real throughput.

Anthropic’s compiler experiment makes the point unusually clearly. In February 2026, Nicholas Carlini described sixteen agents tasked with writing a C compiler in Rust capable of building the Linux kernel. After nearly 2,000 Claude Code sessions and about $20,000 in API costs, the agent team had produced roughly 100,000 lines of code and could compile Linux 6.9 for x86, ARM and RISC-V.6

The coordination mechanism was rudimentary. An agent claimed a task by creating a text file in a directory synchronized through git. Merge conflicts were frequent, but the agents could usually resolve them. The decisive lesson appeared elsewhere.

When kernel compilation surfaced as one large shared failure, every agent encountered the same bug, fixed it and risked overwriting the others’ changes. Sixteen agents were looking at the same problem sixteen times. Parallelism provided little value.

Anthropic then changed the structure of the problem. A harness compiled most of the kernel with GCC as a known reference, then distributed distinct remaining files to different agents for testing with the new compiler. The final objective had not changed. The work had become discriminating and divisible.6

You do not parallelize an objective. You parallelize a structure of work.

In 1968, Melvin Conway observed that systems tend to reflect the communication structures of the organizations that build them.7 With agents, the reading can be reversed: the structure of the work should determine the structure of the team. Anthropic accordingly recommends partitioning edits so that each teammate owns a distinct set of files rather than making several agents compete over the same surfaces.5

Our own work leads us to an even more operational criterion. We parallelize operations whose order does not change the final result, such as fetching pages, extracting claims or attaching evidence. We serialize what depends on order, especially revision of shared state and final decisions. In one of our monitoring systems, a serial loop took roughly twelve minutes per monitored component, mostly because it kept rereading the same pages. The improvement came from a shared cache and page-level decomposition, not from a faster model.

Hierarchy comes back through the window

Cursor eventually abandoned its horizontal coordination scheme. The team separated responsibilities instead.

Planners explore the project and create tasks. Workers execute those tasks without continuously coordinating the rest of the team. At the end of each cycle, a judge decides whether another one should begin. This structure allowed Cursor to run hundreds of concurrent workers on the same codebase. In its browser experiment, they worked for nearly a week and wrote more than one million lines across roughly one thousand files.1

That volume is not a quality metric. Cursor says so itself about a separate Solid-to-React migration: the work passed early checks and CI, but still required careful review.1 What matters here is not the line count. It is the organizational change. A minimal hierarchy replaced a flat self-organizing system that spent too much of its capacity coordinating itself.

The MAST study, published at NeurIPS 2025, gives these failures a more systematic vocabulary. The authors assembled more than 1,600 traces from seven multi-agent frameworks and identified fourteen failure modes across system design, inter-agent misalignment, and verification and termination.8 The most common problems are strikingly ordinary: repeating steps, mismatches between reasoning and action, misunderstanding termination conditions, and failing to follow the specification. These are not primarily failures of intelligence. They are failures of system design.

A 2026 preprint, OrgAgent, pushes the organizational analogy further by structuring agents like a company, with governance, execution and compliance layers. On SQuAD 2.0 with GPT-OSS-120B, the hierarchical configuration improved performance by 102.73% over a flat multi-agent baseline while cutting token use by 74.52%.9 This is one benchmark and one model, not a universal law. It is still informative because the authors identify the conditions under which hierarchy helps most: stable skill assignment, controlled information flow and layered verification.

The connection to organization theory is difficult to miss. Herbert Simon described organization as a response to bounded rationality: divide the work, reduce the information each local actor must process, aggregate what needs to move upward, and formalize some decisions.10 Weber, for his part, analyzed bureaucracy in terms of technical advantages such as precision, continuity, knowledge of files and reduced friction.11

For agents, that logic can be translated into a small grammar of shared control:

OperatorOrganizational function
RoleRestrict the action space and clarify mandate
ProcedureMake executions comparable
Expected evidenceMake acceptance conditional on something verifiable
ApprovalIntroduce control before effect
Separation of rolesPrevent a producer from being the sole validator of its own output
AuditMake events replayable and explainable
EscalationRoute uncertainty to an authority able to decide

An organization does not assume infallible members. It creates rules that make their errors visible, localizable and correctable.

Too little structure creates conflict. Too much creates bureaucracy

The reverse movement matters just as much.

Cursor had introduced an integrator role for quality control and conflict resolution. The team later removed it. According to its postmortem, the role created more bottlenecks than it solved, while workers were already capable of handling many conflicts themselves.1

Cursor’s conclusion is precise: too little structure creates conflict, duplication and drift. Too much structure creates fragility.1

Organization theory knows this pathology as well. Robert Merton described goal displacement in 1940, when following procedure begins to replace the purpose the procedure was meant to serve.12 Adler and Borys later distinguished coercive formalization, which traps the worker inside a process, from enabling formalization, which equips the worker to act better.13

Agent harnesses face the same choice. A procedure can prescribe every step and multiply mandatory exchanges. Or it can define checkpoints and let execution remain flexible between them.

That is the direction we take in our own work. Between two checkpoints, the agent retains freedom of execution. At the checkpoint, it must produce the expected evidence, and that evidence must be checked by a distinct verifier. We do not prescribe how the model must think. We prescribe what must be demonstrated before it proceeds, and who is allowed to accept that demonstration.

This distinction is not merely stylistic. Work presented at EMNLP 2024 found that stricter output-format constraints can measurably degrade model reasoning performance.14 Conversely, research on process supervision shows the value of evaluating intermediate steps rather than waiting only for a final answer.15

A coordination function therefore deserves to exist only if it removes more collisions than it creates waiting.

The rule applies to a lock, a planner, an admission queue, an arbiter, shared memory, human review or a test. Every layer has to justify its coordination cost.

The agent-specific trap: clones do not make a committee

Human organizations have already encountered almost everything described so far. One difficulty is more specific to agent systems: their members can be close variants of the same models and can therefore share the same errors.

Condorcet’s jury theorem starts from an appealing intuition. If voters are independent and each is slightly more likely than chance to be correct, the majority becomes more reliable as the group grows.16 Both assumptions matter: competence and independence.

Independence cannot be taken for granted with language models.

In 2026, Guneet Kohli at Apple evaluated a panel of nine frontier models from seven different model families. On the tasks studied, those nine judges provided only about two effective independent votes. Their errors were correlated enough that the best individual judge matched or outperformed the full panel across the tested conditions. The paper’s conclusion is straightforward: scaling a panel is not a substitute for genuinely independent evaluation.17

The result needs to be read carefully. The study already uses seven different model families. It does not directly measure nine instances of the same model. Turning it into a universal number for model clones would therefore be unjustified. What it does establish is more general: counting voters is not the same as counting independent information.

A Fudan preprint released in May 2026 reports another effect. In a homogeneous multi-agent system driven by the same LLM, performance can improve as more agents are added and then decline after an optimum. On an abstract algebra benchmark using Llama-3.1-70B, the authors report 72.55% at four agents and 64.71% at eight, while token cost grows sharply with system size.18 This is a preprint and a specific architecture. The result is nevertheless consistent with a simple point: plurality does not automatically create collective intelligence.

Chen and colleagues had already observed a related effect in 2024 for compound systems based on repeated model calls and majority voting. More calls can initially help and later hurt, because additional votes improve easy questions but can reinforce the wrong answer on difficult ones.19

Cognition states the objection more radically: actions carry implicit decisions. If subagents make incompatible decisions without sharing their full traces, the final integrator may receive pieces that cannot be reconciled cleanly.20

The answer is not to abandon parallelism. It is to reserve parallelism for work that can actually be separated, and to manufacture independence where verification is the goal.

A producer and its verifier should not simply be the same instance in another conversational turn. Better still, all verifiers should not be of the same type. Executing code, querying a primary source, applying a business rule, or corroborating across documents create different failure modes from those of a second generative judge. Disagreement between verifiers then becomes useful evidence to escalate rather than noise to average away.

Counting how many sources or agents agree is not the same as measuring their independence. This is an active research problem for us, and we believe it is one of the missing metrics in multi-agent systems.

There is no single good organization model

It would be tempting to conclude that the answer is simply more hierarchy. That would replace one mistake with another.

Highly controlled structures work well when the main objective is precision of execution: apply a procedure, check compliance, consolidate a deliverable, execute work whose roles are known in advance. They are less suitable when value comes from exploration: designing an architecture, developing a strategy, or finding the cause of an unknown bug.

Organization theory has described this tension for decades. Burns and Stalker contrasted mechanistic and organic structures. Mintzberg distinguished, among other forms, machine bureaucracy from adhocracy. March formalized the tension between exploiting what an organization already knows and exploring new possibilities.21

Toyota’s product development system offers another useful intuition. Set-based concurrent engineering keeps several alternatives alive long enough to compare them instead of choosing one early and defending it through iteration.22 Reinertsen, in turn, emphasizes limiting work in progress and pulling work according to available capacity rather than pushing an ever-growing queue into the system.23

Agent systems are already rediscovering these forms without always naming them.

Google’s Co-Scientist, published in Nature in May 2026, keeps multiple hypotheses alive as they are generated, criticized, ranked through tournament-style comparison and evolved. Coordination is not a central plan dictating every step. It structures competition among alternatives before experimental validation.24

Claude Code’s documentation recommends a similar pattern for debugging: different teammates can test competing hypotheses and actively try to falsify one another’s ideas, reducing the anchoring that comes with sequential investigation.5

We therefore treat these as two regimes built on the same underlying control layer. In a control regime, roles and validation checkpoints dominate. In an exploration regime, agents pull available work, several hypotheses coexist, and weaker alternatives are progressively eliminated. Logging, verification and human review remain present in both.

The form of coordination should follow the nature of the task, not the number of available agents.

A single process can also change regimes. Exploration can remain broad before a decision, then execution can become strict once the decision has been made. Integration, in turn, often benefits from being separated from the production flow. You do not redraw the map while walking on it.

Machine production is already outgrowing human absorption

This is no longer only a problem for agent laboratories.

On September 6, 2026, OpenAI published a snapshot of agent use inside its own research organization. By mid-August, it measured 3.1 agent-workdays of runtime for every human workday. The median researcher by agent usage was consuming more than $600 of inference per day at API prices, while the 90th percentile exceeded $7,000.25

Those numbers do not mean that three agent days equal three human days. OpenAI explicitly warns that execution volume is difficult to interpret. It also notes that agents still require significant human steering, especially as tasks become more complex.25

The direction is nevertheless clear. In June 2026, OpenAI had already reported that users at the 99th percentile internally were regularly generating more than sixty hours of Codex agent turns per day, distributed across several agents running in parallel.26

As execution becomes cheaper, the constraint moves toward everything that is harder to parallelize: problem definition, integration, verification, arbitration and acceptance.

It is the same dynamic we described in August when discussing verification. Output can scale much faster than the amount of judgment available to absorb it.27 A system that escalates too many cases does not solve the problem either. It simply transfers it to a decision-maker who eventually becomes saturated and may start approving by reflex.

The right unit of escalation is therefore not a generic high-risk alert. It is an instructed case file: what is being claimed, the evidence supporting it, the active contradictions, the reason for escalation and the available options. The human should not have to redo the agent’s work. They should be able to arbitrate the case that has been prepared for them.

The relevant KPI is not “how many agents?”

Agent count is a measure of installed capacity. It says little about useful throughput.

An agentic team should instead track a few simple measures:

  1. Independent work rate. What proportion of tasks can progress without waiting for another task?
  2. Waiting ratio. How much time is spent waiting for a lock, merge, decision or resource? In Cursor’s first experiment, throughput of two or three agents out of twenty launched suggests that waiting consumed most of the available capacity.1
  3. Collision rate. How much work is discarded, redone or reconciled?
  4. Effective number of independent voices. How much distinct information is gained when the system multiplies judges? Apple’s panel is a reminder that nine nominal votes can contain far less than nine independent signals.17
  5. Integration time per unit produced. What does it cost to absorb one more output?
  6. Human review time relative to human time saved. Has automation removed work, or merely moved it?

These measures reveal an organizational ceiling. Beyond a certain number of agents, adding production no longer shortens delivery because integration, decision or review becomes the limiting factor.

Claude Code’s current recommendation is telling: start with three to five teammates for most workflows, then scale up only when the work genuinely benefits from simultaneous execution. Its documentation even notes that three focused teammates often outperform five scattered ones.5

The right number of agents is not a target. It is a consequence of the decomposition.

Multi-agent systems are a work-organization problem

Model progress will make it increasingly cheap to create a massive software workforce. Launching ten agents, then one hundred, then more will become easy.

What remains scarce is the ability to give them admissible work, to make branches independent where possible, to serialize decisions where necessary, to build genuinely independent verification, and finally to accept or reject what they produce cleanly.

An organization is not a number of executors. It is the grammar that connects them.

That is why, at Cercle, we do not think of the Beyond Core as one more orchestrator. We design it as an organizational layer: roles and rights, expected evidence by claim type, separation between production and verification, a replayable log, and escalation to a human review package when the system should no longer decide on its own.28

There may be many Companions. The organization lives in the rules that connect them.

The question is no longer “how many agents can we launch?” It becomes: how many changes can our organization absorb without losing coherence?

Sources

  1. Wilson Lin, Cursor, Scaling long-running autonomous coding, January 14, 2026. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975. ↩

  3. Gene M. Amdahl, Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities, AFIPS, 1967, https://doi.org/10.1145/1465482.1465560. ↩

  4. Anthropic Engineering, How we built our multi-agent research system, June 13, 2025. ↩ ↩2

  5. Anthropic, Orchestrate teams of Claude Code sessions, documentation accessed September 15, 2026. ↩ ↩2 ↩3 ↩4

  6. Nicholas Carlini, Anthropic Engineering, Building a C compiler with a team of parallel Claudes, February 5, 2026. ↩ ↩2

  7. Melvin E. Conway, How Do Committees Invent?, Datamation, April 1968. ↩

  8. Mert Cemri, Melissa Z. Pan, Shuyi Yang et al., Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025. ↩

  9. Yiru Wang, Xinyue Shen, Yaohui Han et al., OrgAgent: Organize Your Multi-Agent System like a Company, arXiv preprint, April 1, 2026. ↩

  10. Herbert A. Simon, Administrative Behavior, 1947; The Sciences of the Artificial, 1969. ↩

  11. Max Weber, Wirtschaft und Gesellschaft, 1922; English reference translation in H. H. Gerth and C. Wright Mills, From Max Weber, 1946. ↩

  12. Robert K. Merton, Bureaucratic Structure and Personality, Social Forces, 18(4), 1940. ↩

  13. Paul S. Adler and Bryan Borys, Two Types of Bureaucracy: Enabling and Coercive, Administrative Science Quarterly, 41(1), 1996. ↩

  14. Zhi Rui Tam et al., Let Me Speak Freely? A Study On The Impact Of Format Restrictions On Large Language Model Performance, EMNLP Industry Track, 2024. ↩

  15. Hunter Lightman et al., Let’s Verify Step by Step, ICLR 2024. ↩

  16. Nicolas de Condorcet, Essai sur l’application de l’analyse à la probabilité des décisions rendues à la pluralité des voix, 1785. ↩

  17. Guneet Kohli, Apple Machine Learning Research, Nine Judges, Two Effective Votes: Correlated Errors Undermine LLM Evaluation Panels, preprint, May 2026. ↩ ↩2

  18. Jialing Li, Zhouhong Gu, Yin Cai and Hongwei Feng, Scaling Behavior of Single LLM-Driven Multi-Agent Systems, arXiv preprint, May 30, 2026. ↩

  19. Lingjiao Chen et al., Are More LLM Calls All You Need? Towards the Scaling Properties of Compound AI Systems, NeurIPS 2024. ↩

  20. Walden Yan, Cognition, Don’t Build Multi-Agents, June 12, 2025. ↩

  21. Tom Burns and G. M. Stalker, The Management of Innovation, 1961; Henry Mintzberg, The Structuring of Organizations, 1979; James G. March, Exploration and Exploitation in Organizational Learning, Organization Science, 2(1), 1991. ↩

  22. Allen C. Ward, Jeffrey K. Liker, John J. Cristiano and Durward K. Sobek II, The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster, Sloan Management Review, 36(3), 1995; Durward K. Sobek II, Allen C. Ward and Jeffrey K. Liker, Toyota’s Principles of Set-Based Concurrent Engineering, Sloan Management Review, 40(2), 1999. ↩

  23. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas, 2009; John D. C. Little, A Proof for the Queuing Formula L = λW, Operations Research, 9(3), 1961. ↩

  24. Juraj Gottweis et al., Accelerating scientific discovery with Co-Scientist, Nature 655, 487-496, 2026, DOI 10.1038/s41586-026-10644-y. ↩

  25. OpenAI, Research acceleration: the view inside OpenAI, September 6, 2026. ↩ ↩2

  26. OpenAI, How agents are transforming work, June 25, 2026. ↩

  27. Cercle, When generating costs nothing, verifying becomes the problem, August 21, 2026. ↩

  28. Cercle, Investing in Cercle, sections “An architecture in four parts” and “The Companions”, accessed September 15, 2026. ↩