The real question is rarely whether multi-agent AI is powerful. It is whether your business needs more than one agent at all, or whether one well-built agent handles the job just as well, for a fraction of the cost and a fraction of the ways it can break. A multi-agent system is a setup where two or more AI agents, each with its own role and often its own underlying model, work on the same job instead of one agent doing everything end to end, and the honest answer for most Cambodian SMEs is that they do not need one yet.
This is not an argument against multi-agent AI. It is an argument against reaching for it before the single-agent version has been tried and found wanting, because the cost and failure modes of adding a second and third agent are measurable and higher than most teams expect.
What is a multi-agent system, and how is it different from one smart agent?
A multi-agent system is a computational setup where multiple AI agents, each with a defined role, its own tools and sometimes its own model, coordinate within a shared environment to handle a job that would overload a single general-purpose agent. The idea behind multi-agent AI is the same one behind any specialized team: instead of one generalist doing research, drafting and checking, three specialists each do one part and hand off to the next.
A single agent, by contrast, keeps one continuous thread of reasoning and context from the first instruction to the last action. What makes it "single" is that one agent, not several separate ones, owns the whole decision chain. We cover that distinction, and what actually counts as an AI agent in the first place, in more depth elsewhere, because the word gets stretched to cover everything from a fixed decision tree to a fully autonomous system.
The practical difference shows up the moment something goes wrong. In a single agent, there is one place to look. In a multi-agent system, a mistake can originate in one agent and get amplified, misread or quietly accepted by the next one before a human ever sees it.
The three architectures worth knowing: supervisor, pipeline and swarm
Most multi-agent AI setups follow one of three patterns, and the pattern decides where the system is strong and where it breaks under pressure. This is the part of AI orchestration that actually matters for a business deciding how to wire agents together, more than which model sits behind each one.
A supervisor or router pattern puts one lead agent in charge: it reads the incoming request, classifies it, and delegates to specialist worker agents, either one after another or in parallel. A pipeline runs agents in a fixed order, each handing its output to the next, like a production line. A swarm lets agents talk to each other directly with no fixed hierarchy deciding who does what next.
| Architecture | How it works | Best for | Main failure risk |
|---|---|---|---|
| Supervisor or router | One lead agent classifies the request and delegates to specialist workers, in sequence or in parallel | Jobs with clearly separable sub-tasks: research, drafting, checking | The lead agent becomes a bottleneck, or a single point of failure for the whole job |
| Pipeline | Agents run in a fixed order, each handing its output to the next | Repeatable multi-step processes: intake, then processing, then reporting | One weak link anywhere in the chain stalls the entire pipeline |
| Swarm | Agents communicate directly, with no fixed hierarchy | Open-ended exploration where the shape of the task is not known in advance | Coordination chaos: agents overwrite each other's work, contradict each other, or loop |
For almost every Cambodian SME use case we see, a supervisor or a pipeline covers it. A swarm is the pattern research labs reach for when the task genuinely cannot be planned in advance, not the pattern a business needs for invoice processing or customer replies.
Does a multi-agent system actually perform better than one good agent?
A multi-agent system does not automatically outperform a single well-designed agent, and the two most-cited studies on the question point in different directions because they are measuring different kinds of tasks. Anthropic's own engineering team found that a lead agent (Claude Opus 4) coordinating subagents (Claude Sonnet 4) outperformed a single Opus 4 agent by 90.2 percent on an internal research evaluation, but at a real cost: a multi-agent system uses roughly 15 times the tokens of a single chat interaction, against roughly 4 times for one agent working alone (Anthropic, 2025).
That is a genuinely large performance gain, and Anthropic's own analysis found that token usage alone explained about 80 percent of the variance in how well a run performed, with the number of tool calls and the choice of model explaining most of the rest (Anthropic, 2025). In other words, a large share of the gain is simply paying for more thinking, spread across more agents, not a free improvement.
A Stanford study published in April 2026 found the opposite result on a different kind of task: under a fixed reasoning-token budget, single-agent systems consistently matched or outperformed multi-agent teams on multi-hop reasoning, because every handoff between agents risks losing some of the context the next agent needs (Dat Tran and Douwe Kiela, Stanford, April 2026).
Both findings are correct, for the tasks they tested. Anthropic's gain came from breadth-first research: pursuing several independent lines of inquiry in parallel, where splitting the work genuinely multiplies the ground covered. The Stanford result came from multi-hop reasoning: a chain of steps where each one depends on getting the previous one right, and a single continuous thread of context beats several agents passing summaries back and forth. Almost every task a Cambodian SME brings to us, invoice reconciliation, drafting a customer reply, checking a document against a policy, looks far more like the second kind than the first. That is the main reason we default new clients to one agent, not several.
What multi-agent complexity actually costs
What multi-agent complexity actually costs is best understood as a multiplier on top of whatever a single agent would have cost for the same job, not as a fixed add-on fee. Take a hypothetical three-agent setup for a Phnom Penh trading company: one agent reads supplier invoices, a second reconciles them against the accounting system, a third drafts a reply when a supplier disputes an amount. If the single-agent version of just the invoice-reading task would run at roughly 4 times the token cost of a plain chat reply, the full three-agent pipeline, with each agent passing context to the next and occasionally looping back to ask for clarification, lands closer to the 15 times multiplier Anthropic measured for multi-agent systems overall.
Put real numbers on that multiplier and the gap stops being abstract. A plain chat reply on a current mid-tier model runs at roughly $0.01 to $0.02 in API tokens. At 4 times that, the single invoice-reading agent costs roughly $0.04 to $0.08 per invoice. At 15 times, the full three-agent pipeline costs roughly $0.15 to $0.30 per invoice. For a trading company processing 2,000 supplier invoices a month, that is the difference between about $80 to $160 a month running the single agent and $300 to $600 a month running all three, before counting the engineering time to build and maintain the extra two. These are illustrative figures based on current Claude and GPT token pricing, not a quoted TechFlow client bill, but they are exactly the calculation worth running on paper before a project gets scoped as multi-agent by default.
Model choice adds a second lever. We route every agent's calls through OpenRouter's model routing so a client is never locked into one model's pricing or uptime, and so a cheaper model can handle the simple reconciliation step while a stronger one handles the supplier reply that needs actual judgment. That routing layer does not remove the multiplier. It just means the business is not paying a premium-model price for every step in the chain, only for the steps that need it.
None of this is a reason to avoid multi-agent systems. It is a reason to know the multiplier before committing to one, the same way a construction quote separates materials from labor before anyone signs off on a budget. Infrastructure is the other lever worth naming here: a straightforward agent or skill ships in 24 to 48 hours, a fuller autonomous agent in one to four weeks, and if a client's data has to stay on a sovereign or private-cloud server rather than a shared one, that typically adds four to eight weeks on top, independent of how many agents the final setup runs. That sovereign-hosting question matters more in Cambodia than the timeline alone suggests: the Law on Personal Data Protection is still a draft as of 2026, with the Ministry of Posts and Telecommunications (MPTC) running validation workshops through August 2026 rather than an enacted statute in force, so a business choosing where its agents' data sits today is getting ahead of the law, not satisfying it.
Why do most multi-agent systems fail in production?
Most multi-agent systems fail in production because of how the agents are specified and coordinated, not because the underlying language model is too weak. A 2025 study led by UC Berkeley researchers built the first systematic failure taxonomy for multi-agent LLM systems, analyzing over 1,600 annotated execution traces across seven popular frameworks, including AutoGen, ChatDev and CrewAI. The resulting taxonomy, MAST, documents 14 distinct failure modes across three categories: system design and specification issues, inter-agent misalignment, and task verification gaps, with inter-annotator agreement strong enough (Cohen's Kappa of 0.88) that the classification is not a matter of opinion (Cemri et al., UC Berkeley-led, 2025).
The pattern behind most of those failures is simple to state and hard to design around: agents hand off work without fully sharing the reasoning behind it, and the next agent in the chain inherits a decision it cannot see the logic for. The largest single category in the MAST taxonomy, system design and specification issues, covers the most preventable version of this: a role left ambiguous, a constraint never written down, two agents quietly given overlapping authority over the same decision. None of that requires a better model to fix. It requires writing the specification as carefully as the code.
"Actions carry implicit decisions, and conflicting decisions carry bad results." (Walden Yan, Cognition AI, June 2025)
Walden Yan's argument, published after his team tried and abandoned a multi-agent architecture for their own coding agent, is specifically about tasks where agents cannot fully share context with each other: the decision-making ends up too dispersed for any one agent, or any human reviewing the output, to reconstruct why the system did what it did. That is precisely the failure mode the MAST taxonomy's "inter-agent misalignment" category captures at scale. What catches these failures before they reach a client is rarely the model. It is the agent harness around it: the retry logic, the handoff format, the logging that lets a person see what each agent actually decided and why.
When does a business actually need more than one agent?
A business needs more than one agent only when a single task genuinely splits into parts that require different tools, different knowledge, or an independent check, not simply because the project feels large. Three signals are worth watching for, and we treat all three as necessary before we recommend splitting a job across agents rather than deepening one:
- A hard tool or knowledge boundary. One part of the job needs deep access to an accounting system, another needs fluent customer-facing language. Cramming both into one agent's instructions usually degrades both.
- A genuine need for independent verification. A second agent, deliberately kept separate from the first, checks its output against a different source before anything reaches a customer or a ledger. This is the one case where splitting the work is the whole point.
- Parallelizable volume that actually matters. The task is breadth-first, several independent lines of work that do not depend on each other's output, at a volume where running them one after another would meaningfully slow the business down.
A worked example of the second signal: a logistics client asks an agent to approve refunds under a set value automatically. We would not let that same agent also be the one that decides the value threshold was met. A second, narrower agent checks the claimed shipment status against the carrier's own record before any refund agent is allowed to act, specifically because the cost of one wrong automatic approval is higher than the time saved by skipping the check. It is the only one of the three we treat as close to a hard requirement, not a judgment call.
If none of the three apply, the honest move is to make the single agent better: a clearer instruction, a narrower scope, a better harness. Gartner's own research backs the caution: by 2028, agentic AI is expected to appear in roughly a third of enterprise software, up from under 1 percent in 2024, and over the same period Gartner predicts more than 40 percent of agentic AI projects will be canceled before they reach production, overwhelmingly because the project was scoped for complexity the task never actually had (Gartner, June 2025).
What does a realistic multi-agent setup look like for a Cambodian business?
A realistic multi-agent setup for a Cambodian business usually means two or three narrow agents wired together with an n8n automation layer, not a swarm of a dozen specialists talking to each other. Picture a Siem Reap tour operator running a supervisor pattern with one verification step built in by design: one agent reads incoming booking requests from Telegram and email and extracts the dates, group size and requested package. A second, kept deliberately separate, cross-checks that extraction against the actual availability calendar before anything is confirmed, because a wrong date confirmed to a customer costs more to fix than the system saved by automating it. A third drafts the reply in the customer's language and tone, but does not touch the calendar itself. Deloitte's enterprise research tracks the same shift toward deliberate, narrow agent deployments rather than broad ones: 25 percent of enterprises already using generative AI were expected to launch agentic pilots in 2025, growing to half of them by 2027 (Deloitte, 2025). In our own work, the pilots that stick tend to be scoped this narrowly from the start.
What we would do in your place
We would not build a Cambodian business's first AI project as a multi-agent system. Start with one well-harnessed agent against the single task that hurts the most, and add a second agent only when a named, observed limitation shows the first one needs a specialist partner or an independent check, not because multi-agent sounds more advanced in a pitch deck. A swarm of agents that argue amongst themselves is not sophistication, it is a support ticket waiting to happen, and we treat the number of agents as the last design decision in a project, never the first.
In practice, here are the three moves we would make in your place. First, map the one task currently costing the most time or the most mistakes, and describe it in one sentence, the way you would brief a new hire. Second, build and run one agent against that task alone, with a human reviewing its output for the first few weeks, before any conversation about a second agent happens. Third, only expand to a multi-agent setup once that first agent hits one of the three signals above, a real tool boundary, a genuine need for independent verification, or parallelizable volume that is actually slowing the business down.
We work through exactly this sequence with every AI agents client we take on from Phnom Penh, starting with a free one to two hour process-mapping audit and a costed plan within five business days, and we price the work at roughly 35 percent below what a European agency would charge for the same build, a positioning claim rather than a measured saving. If the task you are weighing sounds like it clears the bar for more than one agent, that free audit is the fastest way to find out before anyone writes a line of orchestration code. Book a call and bring the one-sentence description of the task with you.
Prefer to chat? Message our founder directly on Telegram (@maxgrolier), or book a call with the team.
Frequently asked questions
Is a multi-agent system the same thing as an AI agent team?
Yes, "multi-agent system" and "AI agent team" describe the same idea: several AI agents, each with a defined role, coordinating on one job instead of a single agent handling it end to end. "Multi-agent system" is the more precise technical term; "agent team" is the plain-language version of the same architecture.
How much more does a multi-agent setup cost to run than a single agent?
A multi-agent setup typically costs several times more in token usage than a single agent handling a comparable task, since each additional agent processes its own context and hands off work to the next. Anthropic's own measurements put a single agent at roughly 4 times the token cost of a plain chat reply, and a full multi-agent system at roughly 15 times, though the exact multiplier depends on how much the agents hand off to each other.
Can a multi-agent system use different AI models for different agents?
Yes, and it often should. Routing each agent's calls through a layer like OpenRouter lets a cheaper, faster model handle simple steps while a stronger model is reserved for the step that actually needs judgment, which keeps the overall token multiplier from applying at the most expensive model's price for every step in the chain.
Do we need a multi-agent system for a simple chatbot?
No. A simple chatbot that answers questions or books appointments is almost always better served by one well-harnessed agent. Multi-agent systems earn their added cost and complexity only when a task genuinely splits into parts needing different tools, different knowledge, or an independent check, which a simple chatbot rarely does.
How long does it take to build a basic multi-agent setup?
A narrow, two or three agent setup built around n8n and routed through OpenRouter typically takes one to four weeks once the task has been scoped, the same timeline we quote for a single autonomous agent, because the build effort scales with the complexity of each agent's job more than with the number of agents.
How do you monitor a multi-agent system once it is live?
Mostly through logging and a human spot-check, not a dashboard full of charts. Each agent's handoff, what it decided and what it passed to the next agent, should be logged in plain language so a person can read back through a run and see exactly where a decision was made. We treat that log as part of the agent harness around the system, not an optional add-on, because it is the fastest way to catch the inter-agent misalignment failures the MAST taxonomy describes before a client ever sees them.
Which framework should a Cambodian SME use: n8n, LangGraph or CrewAI?
For most Cambodian SMEs, n8n is the practical starting point: it is visual, self-hostable, and lets a non-engineer see how work moves between agents without reading code. LangGraph and CrewAI give a developer finer control over agent state and memory, which starts to matter once a setup grows past two or three agents, but that level of control is rarely the bottleneck on a first multi-agent build.
