Multi-Agent vs Single-Agent: When More Agents Make a Workflow Worse
Start with the same task and criteria
Compare cost, control and recovery
Original ROUTE-6 matrix and three scenarios
Architecture limits and pilot checks
$ choose-architecture --contract ROUTE-6
> bind: task / authority / outcome
> score: quality / cost / control / recovery
> route: workflow / one agent / multiple rolesMulti-agent vs single-agent is a decision about dividing work, not a contest between model counts. Compare architectures only after fixing the task, authority, response-time limit and method of verifying the result. A deterministic workflow with one agent at a narrow step is often simpler than several agents negotiating shared state. The original ROUTE-6 matrix below is illustrative design work, not a measured customer benchmark.
What are we comparing?
A single agent receives a goal, bounded tools and one state path. It may read, propose and verify sequentially. A multi-agent system assigns roles, such as researcher, executor and reviewer, to separate model-driven workers. Each handoff needs a contract, context transfer, conflict handling and recovery. A third candidate is a workflow with a narrow AI step: deterministic routing and permissions surround the model call. The number of agents alone predicts neither quality nor safety.
Shared decision criteria
Fix the same input, output and decision owner before comparing candidates. Score quality, latency, total cost of ownership, control, recovery and maintenance. Give each criterion a task-specific weight from 1 to 5, then rate each architecture from 1 to 5. Multiply and sum for discussion; hard constraints such as authorization remain separate gates. These are assumptions to test in a pilot, not performance claims.
| Criterion | What to inspect | Typical tradeoff |
|---|---|---|
| Quality | completeness, source, verified outcome | role review may help; handoffs may lose detail |
| Latency | time to verified result | parallelism helps only independent branches |
| Ownership cost | model calls, tools, logs and support | each role adds coordination |
| Control | authorization of each effect | more roles expand the permission surface |
| Recovery | retries, unknown outcomes, version conflicts | distributed state is harder to reconcile |
| Maintenance | prompts, tests and tool versions | each contract needs upkeep |
Original ROUTE-6 decision matrix
Weights follow quality / latency / cost / control / recovery / maintenance. Scores illustrate three hypothetical tasks and must be replaced by a local pilot. They are not evidence of real-world superiority.
| Scenario | Weights | Single agent | Multiple agents | Workflow + narrow AI | First candidate |
|---|---|---|---|---|---|
| Answer from an internal policy | 4 / 4 / 4 / 5 / 4 / 4 | 100 | 72 | 113 | workflow |
| Research independent sources | 5 / 3 / 2 / 4 / 3 / 3 | 83 | 88 | 72 | test parallel roles |
| CRM write after approval | 4 / 3 / 4 / 5 / 5 / 4 | 99 | 74 | 111 | workflow |
The first scenario values fixed retrieval and access control. Independent research may benefit from parallel branches when each brings primary sources and an arbiter checks conflicts. A CRM write depends on verified effect and approval, not the diversity of model reasoning. Re-score with actual tasks, including timeouts and failures.
When multiple agents hurt
A short sequential task gains handoff latency without useful parallelism. Agents reading the same weak evidence may repeat the same error despite different role labels. A reviewer can approve a stale draft if the shared object changes between steps. A timeout after an external write creates an unknown outcome: blindly retrying can duplicate the effect. More conversations between agents do not automatically make an independent audit.
Multiple roles are more plausible when branches are truly independent, output contracts are explicit and the final arbiter checks source provenance. For example, researchers can gather separate primary sources in parallel, while a verifier reconciles disagreements. The benefit must persist on new cases and under failure tests.
Tool and MCP boundaries
MCP can standardize access to tools and resources; it does not select the agent architecture or replace server-side authorization. Every call needs checks for actor, tenant, target, effect and tool version. See what MCP is, MCP server security, and tool schema design.
A prompt cannot be the sole control for significant writes. Use a separate approval gate, idempotency key, attempt record and destination read-back. An unknown result must enter reconciliation. The AI tool permission model details this boundary.
Run a fair pilot
Prepare representative normal and edge cases from the actual process, with sensitive data removed. Give each candidate the same input, authorized sources and scoring rubric. Measure time to a verified result and full ownership cost, including operations and incident review. Test empty tool output, inaccessible source, version conflict, forbidden target and a timeout after an external write. Evaluate recovery paths separately from happy-path answers.
If one agent handles the task with a clear trace, extra roles need a specific demonstrated benefit. If separate roles discover distinct errors on independent evidence, check whether that benefit survives new tasks. The architectural choice should follow observed constraints and outcomes.
Decision summary
Start with a workflow when steps are known and actions need strict control. Choose one agent when flexible work is needed with a small tool set and one owner of state. Consider multiple agents when independent parallel tasks, a measurable benefit and explicit handoff contracts all exist. For a broader project brief and vendor selection in Armenia, use the AI specialist in Armenia guide; this article supplies architecture criteria. You can also prepare a project brief with the task, constraints and required evidence of completion.
const options = scoreSameFixtures(candidates, weights);
return options.filter(x => x.authorized && x.recoversUnknownEffect).sort(byVerifiedBenefit)[0];