Single agent or multi-agent? Use this decision matrix to know when to split

Last month we built an underwriting assistant for an insurance company. Someone on the team opened with: "This needs five agents, one reads documents, one checks policy rules, one calculates premiums, one writes responses, one orchestrates the whole thing." I suggested we first run the entire workflow as a single agent with a few tools. The single-agent version had higher accuracy, half the latency, and when something broke, we could see exactly where it failed.

We deleted that orchestrator agent.

Single agent vs. multi-agent: what we're comparing

A single agent is one LLM loop that decides which tool to call and when to stop. Multi-agent means multiple agents, each with its own prompt, context, and responsibilities, coordinating through messages to complete a task. The difference isn't in capability. It's in coordination.

Adding one agent doesn't just add one capability. It introduces a coordination cost. Context degrades when passed between agents. Each agent can misread the previous one's intent. Debugging shifts from tracing a single log to parsing a chain of messages where agents blame each other.

These costs are real. They show up in tokens, latency, and engineering time.

At Tenten, we operate by this principle: multi-agent isn't the default. It's worth the cost only when the division-of-labor payoff exceeds the coordination expense.

Coordination cost versus division-of-labor payoff

Based on our experience, the payoff matters in three situations.

First, parallelizable work. Say you're analyzing 20 competitor financial reports at once, completely independent. Spin up 20 sub-agents in parallel. The speed improvement is genuine, and coordination cost is nearly zero since they don't need to talk to each other.

Second, contexts that contaminate each other. When one agent has to be both a rigid compliance reviewer and creative copywriter, those two voices collide in the same conversation. Split them out. Each keeps a clean prompt. Quality holds up better.

Third, widely different tool sets. One connects to SQL, another to a drawing API, another runs a web scraper. A single agent with 40 tools wastes time on tool selection. Partitioning by tool family reduces the search space and cuts error rates.

In contrast, if your task is a linear sequence with strict ordering, splitting agents is almost always a bad trade. Linear work offers no parallelization benefit. You pay coordination cost and gain nothing in return. A single agent with tools, or deterministic code, runs faster and debugs cleanly.

The decision matrix

Here's the analysis as a table. Work through it row by row:

Your Scenario	Favors Single Agent	Favors Multi-Agent
Task structure	Linear, strict sequence	Parallelizable, independent sub-tasks
Context	Single role, single objective	Multiple roles contaminate each other
Tool count	~10 or fewer, cohesive	Many, across different domains
Latency requirement	Real-time, conversational	Acceptable as background batch
Error cost	High, needs per-step visibility	Tolerable with local retry
Team operations capability	Want simplicity, easy debugging	Can manage distributed state
Source of value	Accuracy and speed	Breadth and parallel throughput

Go through each row. If most factors favor the single-agent side, don't split. If more than half favor the multi-agent side, seriously consider it. If only one or two factors favor multi-agent, better tool design for a single agent usually solves it. Full orchestration isn't necessary.

A common mistake

A common mistake is confusing task steps with agent count. Steps are a process concern. Agent count is an architectural choice. They don't map 1:1. A single agent handling ten steps is normal and easy to maintain.

Another pattern to avoid is adding a coordinator agent to manage the others. We've hit this rock. The coordinator typically becomes the least stable part of the system because you're asking an LLM to make routing decisions that deterministic code could handle in a few lines. If you can hardcode it, don't delegate it to an agent.

Back to basics

In demos, multi-agent looks smart. Five agents messaging each other on screen, like a team in a meeting. Then you ship it, and you're debugging the message thread at 2 a.m., trying to explain to your customer why the premium calculation is wrong but unable to identify which agent broke it. Good architecture isn't measured by agent count. It's measured by whether it runs after launch and whether anyone wants to maintain it.

At Tenten, we almost always start with the smallest possible single agent. We only add agents one by one when coordination cost genuinely buys you parallelization, isolation, or specialized division of labor. Adding one more agent is never the default for us. It's a decision we have to be sold on by the numbers.