One Agent or Many? A Decision Framework from Production
Pull-quote: “Every agent you add buys parallelism or independence, and pays for it in coordination, state transfer, and new ways to fail.”
Default to one agent
Our default is one agent with good tools, and we require a named boundary before we split. That position comes from operating both architectures in production, not from taste. A second agent is not a free unit of helpfulness. It is a distributed system: state must transfer between contexts and loses fidelity on the way, coordination consumes tokens and latency, failures correlate because the agents share models and prompts, and every added participant multiplies the traces your evaluations have to cover. The teams that regret multi-agent builds are usually the ones that reached for an org chart when they needed context discipline.
Four questions before you split
Q1 Does the task fit one context, with discipline?
│ yes ──► one agent + tools
│ no
▼
Q2 Are the subtasks independent and parallelizable?
│ no ───► one agent, phased plan, externalized state
│ yes
▼
Q3 Must judgments be independent (consensus, review)?
│ yes ──► parallel agents + deterministic aggregator
│ no
▼
Q4 Do privileges or data domains need hard separation?
│ yes ──► split along that boundary, nowhere else
│ no ───► smallest specialist team + supervisorAsk them in order and stop at the first exit. The order matters because the early exits are cheaper to operate and far easier to evaluate.
The signals, and the first response
| Signal in production | What it looks like | First response |
|---|---|---|
| Context contention | The agent forgets constraints from earlier phases | Compaction and externalized state, before splitting |
| Tool confusion | Wrong tool picked from a large surface | Gate tools per phase. Route, do not split |
| Judgment correlation | One reasoning path behind a high-stakes call | Parallel independent agents, deterministic aggregation |
| Privilege mixing | One context can see data it should not | Split. Agents make clean security boundaries |
The first response to the two most common signals is not a second agent. Context contention is usually a compaction problem. Tool confusion is usually a gating problem: expose the six tools this phase needs, not the forty the platform has.
Two architectures, both correct
Consider two production systems with opposite answers. An analytics assistant that ships as a single agent working sixteen tools, because its questions reward one continuous line of reasoning over one context, with tools gated per step. And a screening pipeline that runs eight agents in parallel and aggregates their judgments, because consensus is only meaningful when the judgments are independent. That is a statistical requirement, not a throughput preference. Opposite architectures, and each can name its boundary: the first has none worth paying for, and the second’s is independence of judgment.
Design the split to be removable
One more constraint keeps a multi-agent decision honest: build the topology so it can collapse. Model capability keeps moving, and a decomposition that was necessary at one context length or reasoning tier becomes overhead at the next. If the business logic lives in the tools, the contracts, and the evaluation suite rather than in the choreography between agents, merging two agents back into one is a configuration change instead of a rewrite. Teams that wire domain logic into the coordination layer end up defending an org chart that no longer earns its coordination tax, because removing it would mean rebuilding everything it touches.
Closing
Add an agent when you can name the boundary it enforces: a privilege, a data domain, an independent judgment, genuinely parallel work. Write that boundary down in the design record, because it is also the test for removing the agent later. If the strongest argument is that the architecture diagram looks more impressive with more boxes, it is the wrong reason, and it will bill you for coordination every day it runs.