AI's Next Scaling Law Is Organizational
Most people still think of an agent as a more automated version of ChatGPT. The old request was, “Help me build this feature.” The new one is, “Help me finish this project.” At first, the difference seems incremental. The AI can work longer, use more tools, and execute more steps on its own.
But once subagents, Agent Teams, or other multi-agent systems enter the picture, something more fundamental changes. You are no longer working with one stronger AI. You are coordinating a group of AIs.
One agent investigates the problem. Another implements the solution. Another runs tests. Another reviews the work. They may operate with separate contexts, exchange messages, own different tasks, and combine their results later.
Our current view is simple: The end state of agents may not be the assistant. It may be the organization.
Anthropic ran an experiment in which 16 Claude agents worked together to build a Rust C compiler. Across nearly 2,000 Claude Code sessions, they produced roughly 100,000 lines of code and eventually reached the point where the compiler could compile the Linux kernel.
The obvious conclusion is that if 16 agents are this powerful, 160 should be even better.
That may be the wrong lesson.
The important question is not whether we can run more agents. That will become easier. The real question is why ten agents sometimes outperform one by a huge margin, while in other situations ten agents are actually worse.
A more useful conclusion is simple:
There is no useful scaling law based on agent count alone.
More Agents Is NOT All You Need.
Collective intelligence depends on something more complicated: Parallelism, Diversity, Topology, Verification, and Coordination.
Once agents are viewed this way, the problem stops being only about AI engineering. It becomes a much older question:
How should intelligence be organized?
Agents Are Not GPUs
The success of AI scaling laws trained us to think in a particular way.
If a model is not capable enough, add parameters. If performance is still improving, add data and compute. More resources often lead to better results.
It is natural to extend the same intuition to agents. If one agent is useful, ten should be better. If ten are useful, perhaps one hundred will be better still.
The problem is that agents are not GPUs.
GPUs do not persuade each other. Agents do. A GPU does not see another GPU make a mistake and decide to copy it. An agent can.
More importantly, 100 instances of the same model are not 100 truly independent thinkers. They share similar training, reasoning patterns, blind spots, linguistic habits, and often similar search behavior.
So:
Agent Count does not equal Independent Intelligence Count.
Adding agents creates more computation, but not necessarily more independent intelligence. If the agents use similar information and make similar mistakes, the system may simply reproduce the same judgment many times.
This distinction becomes even more important as agent systems grow.
What Actually Scales: Parallelism and Diversity
When deciding whether a task should use multiple agents, the first question should not be how difficult the task is.
It should be:
How much of the work can actually happen at the same time?
Suppose the task is to analyze the future of the Chinese EV industry. One agent can study BYD, another Tesla, another batteries, another pricing, and another regulation. Most of that work can happen in parallel.
Now consider a different task: talk to a client, revise a proposal based on the response, get confirmation, and then decide the final price.
One hundred agents will not make the final step happen earlier. The information required for it does not exist until the previous steps are complete.
This is the same basic constraint that appears in parallel computing. Some problems are wide. Others are deep. Research is often wide because many information-gathering tasks can happen independently. Planning and execution are often deep because each step depends on the state created by the previous one.
Agents introduce another constraint as well:
Coordination Cost.
The useful gain from adding agents is not the amount of computation created. It is the amount of useful parallel computation that remains after coordination costs are paid.
This is why a complex task is not automatically a good multi-agent task. A difficult but highly sequential problem may be better handled by one strong agent. A simpler task that requires examining fifty independent sources may be ideal for a swarm.
But parallelism is only part of the story.
The more important variable may be:
Diversity.
Imagine asking 20 agents to analyze a company. If all 20 use the same model, the same data, similar prompts, the same search tools, and the same analytical framework, the system may be far less diverse than it appears.
They are likely to make correlated mistakes.
If one agent has a blind spot, cloning it twenty times does not produce twenty complementary perspectives. It often produces twenty versions of the same blind spot.
This is why Epistemic Diversity matters more than Role Diversity.
Calling four agents Researcher, Critic, Writer, and Reviewer does not create four distinct minds. If they consume the same context and see the same evidence, those titles may amount to little more than four job badges attached to the same cognitive pattern.
Real diversity comes from giving agents different paths to knowledge.
For investment research, one agent might only read financial statements and management commentary. Another might focus entirely on customers. Another studies competitors. Another builds the strongest possible bearish case. A separate agent verifies factual claims. Only after that does a final agent synthesize the evidence.
Now the system has more than extra reasoning.
It has independent information channels.
The important question is no longer just:
“How many agents are there?”
It becomes:
How correlated are their errors?
A weaker agent with genuinely different information may be more valuable than another copy of the strongest model.
More Communication Can Make a System Worse
We tend to assume that good teamwork requires more communication.
That assumption is built into many agent systems. Agents share context, read each other’s outputs, and debate until they reach agreement.
But communication does not only transmit information.
It also transmits bias.
Imagine ten agents evaluating a claim. Six initially support A, while four support B. One agent supporting A produces an impressive report early in the process. The analysis is clear and persuasive, but one important data point is wrong.
Other agents read it and update their views. The group moves from six to four, to eight to two, then nine to one, and eventually everyone agrees.
The final result looks extremely strong because ten agents reached the same conclusion.
But the system may not have generated ten pieces of independent evidence. It may have allowed one error to spread through the network.
Consensus increased while independence disappeared.
This is why systems that simply share all available context with every agent deserve skepticism.
Good agent architectures may need deliberate:
Information Firewalls.
A reviewer does not always need to see the writer’s reasoning before reviewing the result. A bearish analyst may be more useful if they have not read the bullish conclusion first. A fact-checker may only need the claim, not the confidence or narrative surrounding it.
Science already uses similar structures through blind review. The point is not that less information is always better. The point is that some information contaminates independent judgment.
The same principle applies to agents.
This suggests that agent engineering may gradually move from prompt design toward network design.
Which agents can communicate? When do they communicate? What information do they exchange? Who can broadcast? Which agents must stay independent? When should their conclusions finally be combined?
In some systems, the best coordination strategy may actually begin with less coordination.
Let agents think independently first. Exchange information later. Synthesize at the end.
As Generation Gets Cheaper, Verification Gets More Valuable
Modern models can generate almost anything.
They can produce code, articles, strategies, ideas, hypotheses, and plans. If 100 options are needed instead of ten, the marginal cost is already small and still falling.
That creates a new bottleneck:
Who decides which output is actually good?
If 100 agents give you 100 strategies, your problem has not disappeared. It has changed from “I have no strategy” to “I do not know which strategy to trust.”
This is why the most important component of an agent swarm may not be the agent.
It may be the: Verifier.
Coding agents have developed quickly because software has unusually strong verification mechanisms. Code can compile. It can run. Tests can pass or fail. The environment provides immediate feedback.
That creates a powerful loop:
Generate, test, fix, test again.
Now ask an agent to design a five-year company strategy.
Where is the verifier?
Profit might take years to measure. Customer preferences change. Competitors react. Markets move. There is no immediate and stable objective function.
In domains like this, multiple agents create a dangerous shortcut:
Consensus as Verification.
Five agents agreeing feels reassuring. But if all five use similar models, similar sources, and influence each other during discussion, agreement may tell us very little.
This is why the long-term advantage of agent systems may not come from launching more agents.
That will become a commodity.
The advantage may come from:
Verification Infrastructure.
Software has tests. Research can use citations, source triangulation, and fact-checking. Data analysis can execute queries. Mathematics can use proof checking. Science can connect agents to simulations and experiments.
Strategy, forecasting, creativity, and management will require different mechanisms. These might include adversarial agents, historical backtests, simulations, external data, human review, or prediction markets.
Sometimes the correct conclusion will simply be that reliable automated verification does not exist yet.
We have become very good at scaling generation.
We are much worse at scaling verification.
The valuable system may not be the one that gives you 1,000 agents.
It may be the one that can tell you when those 1,000 agents are wrong.
From Orchestration to Coordination Engineering
This is why the phrase “Agent Orchestration” increasingly feels too narrow.
Orchestration suggests a workflow. Agent A finishes a task and hands it to Agent B. A router selects the next step. An aggregator combines the outputs.
That is useful engineering, but mature agent systems will need to solve a much larger problem.
Who knows what? Who should not know what? Who can make decisions? Who can challenge them? How are errors detected and isolated? How should compute be allocated? When should a new agent be created? When should one be removed? When is consensus useful? When should dissent be preserved? What belongs in collective memory?
These are not merely workflow questions.
They are questions of:
Organization Design.
A better term may be:
Coordination Engineering.
The frontier of agent systems may gradually shift from building smarter individuals to designing smarter organizations.
Consider an investor with a financial agent, an industry agent, a macro agent, a bull, a bear, a fact-checker, and a portfolio agent. The important skill is not writing seven perfect prompts.
It is deciding how those seven agents should function as a research team.
The same applies to content creation. A system can create a researcher, critic, fact-checker, and editor. What matters is whether they consume different evidence, remain independent at the right moments, and have clear authority over the final decision.
The same logic eventually reaches companies. If Finance Agents, Sales Agents, Legal Agents, and Product Agents become persistent participants in an organization, companies will need to define AI authority.
Who can approve a payment? Who can change a price? Who can contact a customer? Who has veto power? Which actions require human approval?
At that point, the discussion has moved far beyond chatbots.
Agent Swarms Are Reinventing the Organization
If the word “agent” is replaced with “person,” the underlying problem is ancient:
How can many limited individuals produce a system that is smarter than any one of them?
Companies are one answer. Markets are another. Science, universities, governments, and open-source communities are all experiments in organizing distributed intelligence.
They all deal with similar questions. How should information move? Who makes decisions? How do we use specialization? How do we preserve dissent? How do we correct errors before they become systemic?
This is why the best future agent architectures are unlikely to come only from computer science.
Distributed systems, network science, economics, game theory, organization theory, mechanism design, and sociology may all become part of agent engineering.
AI also changes one of the oldest constraints on organizational design:
Agents are cheap.
A company cannot hire fifty analysts for a three-hour research task and dismiss them immediately afterward. An AI system can.
A system can create twenty temporary red teams for one decision. It can assign an adversarial reviewer to every important conclusion. It can build a specialized organization for one problem and dissolve it when the problem is solved.
That may be the most important thing about agent swarms.
Organization itself becomes an on-demand computational resource.
We used to allocate CPUs.
Then GPUs.
The next abstraction may be to:
Allocate organizations.
The Next Scaling Law
If agents continue getting cheaper, everyone may eventually have access to dozens or hundreds of them.
At that point, having more agents will not be a meaningful advantage. Tools become commodities.
The advantage will come from knowing how to organize them.
When should one agent work alone? When should work run in parallel? When is an adversarial perspective necessary? When should information remain isolated? When should agents debate? When must a human make the final decision? Which tasks lack a reliable verifier and therefore should not be highly automated?
This will likely become a core form of AI literacy.
A good manager does not personally perform every task. They know how to decompose problems, build teams, structure information flows, and create accountability.
A sophisticated AI user may eventually do the same.
The key skill will be the ability to:
Design an intelligence architecture.
The real scaling law of agent swarms is not larger models. It is not more agents.
It is: Better independent information, better information flow, stronger verification, and better organizational design.
Agent Count is only the visible variable.
A system can create 10,000 agents, but if they all repeat the same mistake, it has created 10,000 echoes of one voice.
Alternatively, four agents can draw from different information sources, preserve cognitive independence, exchange information at the right moment, and rely on a strong verifier. Those four may already form a powerful collective intelligence system.
This suggests that the next scaling law of AI may not be about building a larger brain.
It may be about learning how to organize many imperfect brains.
For years, the AI industry has asked:
How do we build a smarter model?
Agent swarms force the industry to ask a harder question:
How do we build a smarter society of models?
The first is largely a machine-learning problem.
The second is about organizations, information, incentives, institutions, and power.
LLMs have made intelligent individuals cheap to create. Agent swarms now confront the industry with a much older problem:
Why do intelligent individuals sometimes form a system that is smarter than any one of them, while at other times they simply make a larger mistake together?
That is the real scaling law of Agent Swarms.