Stop Debating Multi-Agent vs Single Agent. Here's the Actual Decision Matrix.

First written in February 2026, when Savra ran a multi-agent architecture. We have since moved to a single agent with dynamically activated skills, and the reasons are in Don't Go Multi-Agent. This article aged better than the rest of that era, because its argument is that the pattern belongs to the query rather than to the system. What changed is the ratio: we found the 5% smaller and the coordination cost higher than estimated here.

Every architecture discussion online asks the same question:

Should I use a single agent or multi-agent?

It is the wrong question, and it produces bad answers in both directions. The useful version is narrower:

What execution pattern does this query need?

Most teams choose an architecture once and then push every request through it, which guarantees that some fraction of their traffic is running through the wrong shape.

Three patterns, and how often each is right

Those proportions are from our traffic and yours will differ, but the shape is the point: the cheap pattern covers most of the work and the expensive pattern is rare.

The decision flow

1Is this a simple query?
2    │
3    ├── YES ──► Unified + sequential (80%)
4    │           "What's my account status?"
5    │
6    └── NO
7        │
8        Does it need multiple lookups?
9        │
10        ├── YES ──► Unified + parallel tools (15%)
11        │           "Compare products A, B, and C"
12        │
13        └── NO
14            │
15            Does it need 5+ parallel LLM calls?
16            │
17            ├── YES ──► Multi-agent parallel (5%)
18            │           "Audit 5 competitors and synthesise"
19            │
20            └── NO ──► Unified + sequential

Four questions get you the same answer faster:

The second and third rows are the ones that decide most real cases, and they pull against each other. Independence is what makes parallel agents work; shared context is what makes them fail. If the tasks need to know what the other tasks found, you do not have parallel work, you have sequential work someone has drawn as a fan.

What each pattern looks like

Unified and sequential, about 80% of traffic:

1User: "What plan am I on?"
2
3Agent:
41. activate_skill("account")
52. get_current_plan()
63. Return the answer
7
8LLM calls: 1
9Latency: ~800ms

Unified with parallel tools, about 15%. One model call, several lookups overlapping inside it:

1User: "Compare our Q4 with competitors A and B"
2
3Agent:
41. activate_skill("analytics")
52. In parallel:
6   ├── search_kb("our Q4 revenue")
7   ├── web_search("competitor A Q4")
8   └── web_search("competitor B Q4")
93. Synthesise and return
10
11LLM calls: 1
12Latency: ~900ms

Note what that costs: one model call and 100ms more than the simple case, for three lookups instead of one. This is the pattern people skip past on their way to orchestration, and it is where most of the perceived need for multi-agent actually lives. Running independent tool calls concurrently is most of the win, and it costs an asyncio.gather.

Multi-agent parallel, about 5%. Genuinely independent reasoning, not just independent lookups:

1User: "Audit 5 competitors and compare strategies"
2
3Orchestrator:
41. Spawn 5 research sub-agents (parallel)
52. Each sub-agent:
6   - activate_skill("research")
7   - Deep analysis (multiple tool calls)
83. A synthesis agent combines the results
9
10LLM calls: 6+ (parallel)
11Latency: ~3-5s

Five separate chains of reasoning, each producing a judgement rather than a fact. That is what justifies the coordination cost.

Skills are not an architecture

This is the distinction the whole debate keeps losing.

1# Without skills, every tool is always loaded:
2agent = Agent(tools=[all_40_tools])   # 5,000+ tokens
3
4# With skills, tools load on demand:
5agent = Agent(tools=[activate_skill])  # 300 tokens
6# User asks about a PDF → loads the documents skill: +200 tokens
7# Total: 500 tokens

Dynamic tool loading answers the question "which tool definitions are in context right now". How many agents you run answers a different question entirely. Skills cut token cost identically under all three execution patterns, which means the token argument is not evidence for or against multi-agent at all.

A great deal of the case people make for orchestration is really a case for loading tools on demand, and it is available without any orchestration whatsoever.

What we would change

The framework held up. The numbers moved.

Working through it in practice, the 5% turned out to be smaller than 5%, and the coordination overhead on the cases that qualified was higher than this article assumed. Splitting conversation history across agents also costs retrieval quality on follow-up questions in a way we had not measured yet when this was written.

So the honest version today: start at unified and sequential, reach for parallel tools when a query needs several independent lookups, and treat parallel agents as something you justify per feature rather than adopt as a default. The routing layer that sits in front of a multi-agent system is the specific cost we had not priced when this was written.

FAQ

Is multi-agent or single agent better?
Neither. The pattern belongs to the query, not to the system. Forcing all traffic through one shape is the actual mistake.

What fraction of queries actually need multiple agents?
About 5% in our traffic, and we later found it smaller. Roughly 80% were single lookups.

Are skills an architecture?
No. Skills decide which tool definitions are in context. That is independent of how many agents you run.

How do you decide which pattern a query needs?
Simple lookup, sequential. Several independent lookups, parallel tools. Five or more independent chains of reasoning, parallel agents.