Multiple Agents: It Might Just Be a Token Business
The number of agents is not the number of intelligences. Ten agents relaying the same words isn't an AI organization — it's a long API call chain. I say this while actually running six client systems on 400,000 won a month of fixed costs.
Watching the AI industry these days, the phrase “multi-agent” gets used strangely often.
There's a planning agent, an analysis agent, a development agent, a review agent, and then a manager agent that manages those agents.
On screen it looks like several AI employees collaborating inside one organization.
But I see much of this structure as closer to the sales tactics of AI companies than to technical innovation.
Of course, this isn't to say multi-agent itself is useless.
If a problem requires systems with different permissions, parallel independent exploration, or one model cross-checking another's output, multiple agents can be rational.
The problem is splitting into agents even work that never needed dividing.
Say there's a task one strong model could finish alone — reading the material with sufficient context, judging, using tools, verifying the result.
And yet this gets divided into five stages:
planning agent, research agent, analysis agent, writing agent, review agent.
Like that.
The agents aren't even genuinely different intelligences.
Often it's the same LLM with a few different lines of prompt, the next agent re-reading what the previous one produced.
Yet to the user, this is presented as “a system where five AI experts collaborate.”
I think we have to ask questions here.
Why was this split into multiple agents?
How much did accuracy actually rise over a single agent?
How much did the failure rate fall?
Did task time shrink?
Including token usage and API costs, did the economics actually improve?
How was the problem solved of early-stage errors propagating down a long chain?
And above all:
is it genuinely better than solving the same problem with one well-designed agent?
If these questions can't be answered with numbers, the number of agents is not technical prowess.
If anything, it may have increased system complexity, increased call counts, increased costs, and multiplied the places to debug.
There is a recurring delusion in the AI industry:
that a complex architecture is a more intelligent architecture.
But software is the opposite by nature.
If the same problem can be solved with fewer components, at lower cost, more stably — that is the better system.
The same goes for AI.
Ten agents do not mean ten times the intelligence.
If ten agents are relaying the same words to each other, that is not an AI organization — it is just a long API call chain.
So when I look at AI products from now on, I think we should look at something other than “how many agents.”
How cheaply and how accurately does this system solve the customer's actual problem?
In the end, that is all that matters.
One agent or ten — the customer doesn't care.
What the customer wants is their problem solved.
But the moment a tech company starts selling agent counts and complex org charts instead of problem-solving ability, technology stops being a product and becomes theater.
So watching much of the fashionable multi-agent structure these days, I think:
is it not one AI being dressed up to look like many, and sold that way?
For multi-agent to be technology, it must first prove itself.
Is it more accurate?
Is it faster?
Is it cheaper?
Is it more stable?
If not, the number of agents is not the number of innovations.
It may just be the number of API calls stamped on the invoice.
I say this having actually run these things extensively.
I say this while actually generating revenue.
I say this while actually solving customers' problems.
I say this while actually running six client companies simultaneously on 400,000 won a month in fixed costs.
I see much of the current multi-agent craze as closer to marketing complexity than technical necessity.
If you split the same model into several roles, spend more API calls and tokens, and then claim performance improved, you must first equalize the compute before comparing.
Remarkably, recent research shows that when compared that way, single agents catch up to or even beat multi-agent setups.
The number of agents is not the number of intelligences.
The reason I develop fast is not that I type code fast.
It's that I don't build unnecessary structure in the first place.
Whether ten agents are needed,
whether a complex pipeline is needed,
whether a feature truly must be split — I look at that first.
Most problems resolve far more simply than expected.
In the end, development speed splits
not on how fast you build,
but on how fast you judge what not to build.