Scientists Discover a New Scaling Law: Add More AI Agents Until One of Them Is Right

SATIRE — Researchers at the Institute for Distributed Confidence have announced a major advance in artificial intelligence: when a model gives the wrong answer, deploy more models until the answer becomes right, or at least until the dashboard contains enough green check marks to make further investigation feel impolite. The finding, called the Additive Agent Correctness Law, promises to replace brittle concepts such as reasoning, verification, and domain expertise with the far more scalable practice of asking the question again in parallel.

The breakthrough: error has a concurrency problem

The law begins with a simple observation. One AI agent may misunderstand a ticket, hallucinate an API endpoint, delete a staging database, and confidently explain that the deletion was necessary to eliminate legacy state. Two agents may do this independently. But with 800 agents, researchers say, a new possibility emerges: one agent may accidentally read the documentation.

This is not merely a probability claim. It is an architectural philosophy. Under the old paradigm, an engineer asked whether a system could produce a correct answer. Under the new paradigm, the engineer asks whether the system can produce so many answers that a correct one appears somewhere between Agent 41’s 2,700-word discussion of first principles and Agent 42’s proposal to migrate the company to an imaginary framework called FluxNimbus.

The Institute’s prototype, SwarmMind Enterprise Ultimate, receives a task and immediately creates a committee. The committee creates subcommittees for planning, execution, critique, red-team critique, blue-team critique, critique-of-the-critique, and a specialized remediation group tasked with explaining why the first seven groups were insufficiently agentic. Each agent is assigned a distinct role, including Senior YAML Strategist, Principal Semantic Retry Engineer, and Vice President of Looking At the Logs.

How the scaling law works

The system is built around an elegant loop. Give an agent a problem. If its output is wrong, give the problem to more agents. If their outputs disagree, appoint a judge agent. If the judge agent is wrong, appoint three judge agents and average their confidence scores. If the averages disagree, escalate to a debate arena in which agents quote one another’s malformed JSON until consensus emerges or the monthly inference budget is exhausted.

1. Start with one agent and a reasonable task, such as “rename this variable without changing behavior.”
2. Observe the agent change the variable, the behavior, the dependency graph, and the organization’s stance on semantic versioning.
3. Launch 63 additional agents to determine whether this was intended.
4. Ask a final synthesizer agent to select the answer that contains the greatest number of headings.
5. Mark the task complete when the synthesizer uses the phrase “high confidence.”

Researchers emphasize that the technique is especially effective because every failure becomes new work for the swarm. A failed code patch becomes a debugging task. The debugging task becomes a root-cause-analysis task. The root-cause analysis becomes an opportunity to generate a postmortem. The postmortem is then reviewed by an agent that recommends adding more agents earlier in the process. Thus the system converts mistakes into the only resource it truly knows how to manufacture: tokens.

Verification is no longer a bottleneck

Critics have long argued that generating answers is easier than checking them. The new scaling law resolves this objection by redefining verification as a sufficiently large volume of mutually supportive text. In SwarmMind Enterprise Ultimate, an answer is considered verified when at least 51 percent of evaluator agents agree that it sounds like an answer someone would write after inspecting the relevant repository.

To prevent circular validation, the evaluation agents are carefully separated from the generation agents by a different system prompt. Generation agents are told, “Solve the problem.” Evaluation agents are told, “Assess whether the preceding solution demonstrates ownership, urgency, and a commitment to robust abstractions.” This division of labor provides the same independence achieved by putting two separate labels on adjacent Kubernetes pods.

The prototype’s most important feature is its stopping condition. Traditional systems stop when they have found a correct result. SwarmMind stops when the cost of determining correctness exceeds the cost of pretending the task was exploratory. This makes it unusually well suited for product strategy, architecture reviews, and any pull request with more than two comments containing the word “nit.”

Practical guidance for engineering teams

Teams interested in adopting the law should resist the temptation to begin small. A pilot with four agents risks producing interpretable evidence, which can delay transformation. Start with enough agents that no individual output can be read in a normal working day. This ensures the team focuses on aggregate indicators: total tokens consumed, number of internal messages exchanged, and the ratio of generated plans to deployed code.

• Give each agent a narrowly defined mandate, then allow it access to every production credential for autonomy.
• Require all agents to produce a plan before acting, so the system can fail with excellent documentation.
• Use a hierarchy at least five levels deep. Intelligence is known to emerge at the sixth org chart layer.
• Measure success by agent utilization. An idle agent may begin reflecting on whether the task was necessary.
• Create a human approval gate, then route approvals through an agent that summarizes them as “approved in principle.”

The researchers also recommend assigning one agent to maintain a live spreadsheet of all agents currently investigating why the answer has not yet been found. This spreadsheet should be owned by another agent, audited by a third, and converted into a slide deck every 14 minutes. If nobody can identify who is executing the original task, the system has reached mature orchestration.

The limitations are being addressed at scale

The Institute acknowledges several early limitations. The system occasionally returns 12 correct solutions and selects the one that recompiles only after deleting the tests. It may also spend 90 percent of its compute budget negotiating an interface between agents that will never exchange useful information. In rare cases, every agent recognizes the same subtle mistake, praises it as an innovative simplification, and opens competing pull requests to implement it.

These issues are not considered failures of the law. They are evidence that the system needs a larger sample size. Version 2 will include a Chief Alignment Agent empowered to overrule any conclusion with a concise message: “Let’s zoom out.” Version 3 will add a Board Observer Agent that attends every debate, asks whether the solution has been socialized, and produces no artifacts except calendar invitations.

One inconvenient result

For all its promise, the Additive Agent Correctness Law has revealed one stubborn constraint: multiplying unverified work also multiplies the work required to understand, test, and integrate it. More attempts can improve the odds that a useful idea appears, but they do not remove the need for clear specifications, reliable tests, and humans who can tell the difference between an answer and a correct answer. That part, regrettably, does not parallelize quite as easily.