.webp)
The clouds outside the window are half-hidden, and the 15-degree temperature feels a bit chilly—typical mid-March in Shanghai. Yesterday, I was still testing a supposedly “disruptive” multi-agent framework. After running dozens of test iterations, watching the tokens burn madly in the backend and the increasingly ridiculous output results, I silently clicked close.
Just then, I came across a long article in the latest issue of Towards Data Science, discussing the fatal flaws of current Multi-Agent Systems. It felt like a refreshing splash of cold water. This might also be the bucket of cold water that the current AI application layer needs most urgently.
Stop Believing in “Strength in Numbers”
I previously read a set of data produced by the Google DeepMind team. To figure out how multi-agent systems actually operate, they ran 180 different configurations across several large language model families. In the end, they arrived at a chilling conclusion: simply stacking multiple LLM Agents together not only fails to produce emergent intelligence but leads to an error amplification effect of up to 17.2 times.
What does this mean?
Many developers currently have the illusion that using a framework to string together a few prompt engineering tricks, letting several AI characters greet each other in the code, will enable seamless collaboration. Frankly speaking, without a rigorous engineering topology, this loose structure—often called a “bag of agents”—is nothing more than a mutually validating hallucination.
Imagine the simplest customer service ticket processing scenario.
Agent 1 is responsible for extracting the customer’s intent. While scanning, it slightly misreads “billing dispute” as “billing inquiry.” Immediately following this, Agent 2 follows this error to retrieve a standard reply template from the database. Once Agent 3 gets the template, it starts furiously polishing it, writing a long paragraph of eloquent but useless fluff. Finally, Agent 4 confidently sends the email to the customer.
This is exactly how the dominoes fall. No single node in the system experienced a catastrophic crash, but with every handoff, the minor deviation was infinitely amplified. What gets outputted in the end is highly confident nonsense.
The More Collaborative, the Stupider?
(Facepalm) There’s actually a rather ironic logical contradiction hidden here.
We desperately increase the number of Agents, initially aiming to make the system smarter, right? But that research clearly points out that the benefits brought by this coordination quickly plateau after exceeding 4 Agents. Beyond this number, the computational resources the system consumes on “communication” and “alignment” will far outweigh the value they generate in solving actual problems.
Especially in tasks that have strict sequential orders and highly depend on state context, a multi-agent architecture will almost inevitably drag down overall performance. This is exactly like the current management state in some large companies: when encountering a slightly complex issue, they create a massive group chat of dozens of people. It looks impressive, but in the end, not only is the problem unsolved, but it also adds a pile of meeting minutes that require back-and-forth confirmation.
The research mentions that if a centralized coordination mechanism is introduced, this error can be forcefully suppressed to around 4.4 times, because it acts as a circuit breaker, intercepting the spread of errors in time. But in actual development, many teams can’t even be bothered to build centralized routing.
Let Traditional Microservices Teach Us a Lesson
To be blunt, the architectural design of many AI application-layer products right now might not even reach the level of internet microservices from a decade ago.
Just do a lateral comparison. Grab any backend developer and ask them—when they build a microservices architecture, their first reaction is definitely state decoupling and strict API contracts, accompanied by reliable circuit breaking and fault tolerance mechanisms. No matter which service crashes, the entire system can still maintain basic operations, or at worst, gracefully degrade.
But on the AI side, an enterprise-grade workflow platform recently pushed by a certain tech giant heavily promotes a no-code drag-and-drop generation of Agent matrices. Look at its demo interface: four or five avatars connected by lines talking automatically, taking turns completing tasks. The visual effect is absolutely top-notch.
However, this design lacks strictly defined functional planes. What Agents exchange is extremely fragile and highly ambiguous natural language. How should I put it… this purely language-based interaction method is actually terrifying in enterprise-grade scenarios where the fault tolerance is extremely low. The memories of these models often get mixed up, and contexts easily pollute one another. As soon as a single node produces an erratic response due to temperature parameter fluctuations, the entire process completely collapses.
I chatted with a friend who works in backend architecture about this before, and I think his remark was spot on: the future core barrier won’t be how many models you can call in parallel, but whether the scheduling engine you design can manage these uncontrollable agents as obediently as Kubernetes manages containers.
Sometimes I Wonder, Have We Gone Astray?
Putting aside these hardcore technical metrics, I sometimes wonder: if we spend massive amounts of expensive computing power just having AI explain to another AI what it actually wants to do, is this really the most economical solution?
According to DeepMind, if a single model can already achieve a benchmark score of over 45% on a task, or if the task requires extremely frequent calls to external tools, then we actually don’t need multi-agent systems at all. A sufficiently capable single Agent wrapped in the most traditional, rigid Python code is highly likely to be much more stable than a bunch of Agents holding a meeting.
It’s also possible that I’m overthinking it. After all, technological evolution has its own rhythm. Perhaps when foundation models cross another magnitude next year, and even inference costs drop to one percent of what they are now, these so-called topological challenges will be brute-forced by compute. 🤷♀️
But at least at the current stage, I still believe that engineering rigor should come before flashy collaboration concepts.
Having said all this, I don’t really have a distinctly clear conclusion either. I just feel that when everyone is fanatic about a new concept, keeping a critical eye never hurts.
The rain seems to have stopped, and the sky outside the window is slightly brighter. Let’s wrap it up here for today.
References:
- Why Your Multi-Agent System is Failing: Escaping the 17x Error Trap of the “Bag of Agents”
- Google DeepMind Challenges Multi-Agent System Assumptions
- Scalable agent architecture for distributed training – Google DeepMind
—— Lyra Celest @ Turbulence τ.
