Google & MIT Research — Why Multi-Agent Systems Can Drop Performance by 70%

구글·MIT 연구 — 멀티에이전트 도입하면 성능 70% 떨어지는 이유

Google & MIT Research — Why Multi-Agent Systems Can Drop Performance by 70%

Lately, 'graph engineering'—weaving together multiple complex agents—has become a hot trend among AI developers. It feels like building a multi-agent system using tools like LangGraph should solve any complex task with ease, but the reality is a bit different. Recent joint research from Google and MIT revealed a shocking finding: designing systems by blindly adding agents can actually degrade performance by up to 70%.

A Warning from Google and MIT — Poison for Sequential Thinking

It might seem that more agents would lead to better handling of complex and difficult tasks, but that isn't the case in practice. A joint study by Google Research and the MIT Media Lab tested 180 different agent configurations and discovered that, depending on the design, efficiency can drop drastically.

The problem was particularly severe in sequential reasoning tasks, such as coding or precise planning, where the output of an earlier step affects the next. As multiple independent agents handed off work in sequence, minor errors snowballed with each step. Consequently, performance plummeted between 39% and 70% compared to using a single agent.

Conversely, parallel tasks—such as data collection or distributed processing, which can be handled independently without interference—yielded the opposite result. When using a centralized control graph structure that split roles among agents and aggregated results, performance improved by a staggering 81%.

Ultimately, the takeaway is that multi-agent systems aren't a universal solution. You must tailor your architecture based on whether the problem at hand requires careful, step-by-step sequential progression or whether it can be tackled in parallel.

Agent Diet — Reducing Unnecessary Chatter

Instead of complicating the architecture by increasing the number of agents, 'loop engineering'—meticulously refining the execution cycle within a single agent—is gaining traction as an alternative. Managing even one agent intelligently can lead to significantly more stable results for most complex tasks.

The key solution here is the 'AgentDiet' technique. It works by pruning unnecessary conversation history, redundant information, and expired context data in real-time as the agent utilizes tools. It’s similar to maintaining focus by discarding meaningless doodles and paperwork from your desk as you work.

Academic benchmark results show that applying this technique maintains 100% of the original performance while drastically reducing input token usage by 39.9% to 59.7%. This not only saves on token costs but also resolves the chronic issue of agents providing erratic responses due to bloated context windows.

The Trade-off Between State Management and Speed — LangGraph Latency

Many developers love LangGraph for its robust state persistence, as it meticulously tracks conversation data and task status across complex multi-agent setups. However, all that convenience comes with an unexpected performance cost.

Infrastructure benchmark data shows that LangGraph's internal coordination overhead introduces non-negligible latency in production environments. Based on P95 latency (the slowest cases), LangGraph recorded approximately 16.8 seconds, while AutoAgents, a high-performance Rust-based framework, clocked in at just 9.6 seconds.

The difference in throughput is also clear. AutoAgents handled 4.97 requests per second, showing an efficiency roughly 84% higher than LangGraph's 2.70 requests. While LangGraph’s base operating overhead is very light—at just a few milliseconds—the system as a whole becomes heavy when the process of tracking and coordinating multiple agent states becomes complex.

Ultimately, a poorly designed multi-agent graph can become a 'distributed monolith' that makes the entire service sluggish. For services where real-time response speed is critical, you need a balance: apply LangGraph selectively to core flows that strictly require state persistence rather than insisting on complex graph structures across the board.

When to Draw a Graph, When to Run a Loop

The criteria to remember when designing agent systems are clear: simplify the structure to match the nature of the task you are trying to solve.

For sequential reasoning tasks where the output of the first step serves as input for the next, it is far better to optimize a single-agent loop. It is more efficient to meticulously calibrate one smart agent to question itself and refine its own answers.

On the other hand, if you are running independent sub-tasks simultaneously and only need to collect the results at the end, that is when a multi-agent graph should come into play.

Before you start drawing complex system maps, why not try maximizing the efficiency of a single agent's loop first? Sometimes, a simple, uncluttered design is the most reliable formula for success.