Single agent vs. multi-agent: When to use which
Seven agents on the slide deck. One in six decisions contradicts itself in production. Multi-agent isn't the default answer. This article breaks down the real tradeoffs: communication costs, information loss, debugging overhead. You'll get a matrix showing when a single agent is actually cheaper, more stable, and more trustworthy.
By
Tenten AI 研究團隊
應用 AI
Published
March 10, 2026
Read time
6 分鐘
Last quarter, we helped an insurance company fix a disaster. Their tech team built what they thought was the right move: a seven-agent underwriting assistant. A planner agent, a retrieval agent, a pricing agent, a compliance agent, a recommendation-writer agent, an approval agent, and an orchestrator on top. The architecture looked impressive on paper.
Two weeks after launch, a single underwriting decision took 40 seconds on average. One in six came back with contradictory recommendations: the pricing agent used rate version A while the recommendation-writer agent cited version B. Users stopped trusting it.
We scrapped it and rebuilt as a single agent with three tool functions. Response time dropped to 9 seconds. Contradictions nearly disappeared. Same set of requirements, two-thirds less code.
This is not an argument that multi-agent is useless. It is that most teams make the choice between single agent and multi-agent wrong from the start.
Start with a definition you can use
A single agent is an LLM with a set of tools and memory that decides within one reasoning loop which tool to call next. Multi-agent systems deploy multiple independent agents, each with its own prompt, tools, and context, that work together through message passing or a central orchestrator.
The key difference is whether context stays shared or gets divided. A single agent sees the full context from start to finish. Multi-agent systems deliberately split context across different roles. Division creates focus but also creates information gaps. That rate contradiction we saw earlier? That is information loss at work.
Where the 'multi-agent is always better' idea comes from
The idea rests on an intuitive comparison: specialized teams outperform one person doing everything, so AI should specialize too. It sounds plausible, but it misses something critical. Human division of labor works because communication overhead is relatively low and everyone brings common sense to fill gaps. Communication between LLM agents is shockingly expensive. Every handoff requires serializing context back to text, tokens grow, latency accumulates, and information leaks at each step.
Specialization saves effort in the human world. In the LLM world, it usually costs more. Each additional agent adds a prompt to maintain, another hallucination risk, and another handoff where information can vanish. Debugging a three-agent system is not three times harder than debugging a single agent. It is closer to nine times harder, because errors propagate across agent boundaries and you have to trace multiple logs at once to find where things broke.
When single agent actually wins
Start with a single agent and split only if you have a clear reason. Single agent almost always wins in these cases:
The task is linear and each step depends on the previous one. Underwriting, quoting, approval. Processes where every step needs the prior result. Dividing context only creates gaps; it does not create efficiency.
You need low latency and instant response. Customer service copilot, real-time sales lookups. Users will not wait for three handoffs. Each additional agent costs two to three seconds.
Your team is early-stage and requirements are still shifting. A single agent has low cognitive overhead. Change the prompt and behavior changes. With multi-agent, change one thing and you often have to re-validate the entire collaboration chain.
When multi-agent actually makes sense
Multi-agent has its place. It is just not most places. Watch for these three situations:
Subtasks can run in parallel and do not need each other's intermediate results. Financial, legal, and market due diligence on an acquisition target, all at once, then combined at the end. That fan-out and fan-in pattern is where multi-agent gets real parallelization gains.
Context is too large for a single window or needs isolation for security. A research task that reads hundreds of documents. Distribute retrieval across multiple subagents that compress and report back. That solves context dilution, not division of labor.
Subtasks need very different tool permissions or personas. An agent that can write to production databases and one that can only read public data should be isolated for security. Here, multi-agent is a security boundary, not a performance choice.
| Criterion | Favor Single Agent | Favor Multi-Agent |
|---|---|---|
| Step Dependencies | Linear, tightly coupled | Parallelizable, independent |
| Latency Requirements | Real-time response needed | Batch acceptable, longer waits OK |
| Context Size | Fits in a single window | Exceeds window or needs isolation |
| Tools/Permissions | One shared set works | Different permission boundaries needed |
| Team Maturity | Early-stage, shifting requirements | Stable process, collaboration investment justified |
| Debug Overhead | Want to minimize | Equipped to maintain multiple logs |
Take a single agent as far as it goes. Measure exactly where it breaks, latency, context bloat, or tool conflicts. When you can point at the specific bottleneck, split out an agent for that one. Do not split for architecture alone.
When we build agentic workflows for clients, we almost always start with one agent, ship it to production, watch how people use it, then decide whether to grow a second agent based on actual bottlenecks. Seven agents working together looks good in a demo, but what actually handles thousands of requests a day and keeps users coming back is usually that quiet, cheap, easy-to-debug single agent.
One stuck workflow
is enough to begin
Tell us what the team does today, where it breaks down, and what a better working day should look like.