LISTEN TO THIS ARTICLE
Start with a working baseline, then add agents to solve a specific failure or execution constraint. A long prompt, a large tool catalogue or a complex task does not establish that a team of agents will perform better. The useful question is which parts of the work can run separately without losing information needed for the final decision.
A single agent can make repeated model calls, use tools and inspect their results. A multi-agent system introduces separate working contexts and a way to combine their work. Neither label tells you how many model calls a request needs, what it will cost or whether its answer is correct.
Compare the work before comparing frameworks
| Task property | Baseline to test | Reason to consider a different design |
|---|---|---|
| Each action depends on the previous result | Single agent with explicit state | A specific stage needs a separate permission boundary or independently checked result |
| Evidence can be collected independently | Fixed parallel workflow | The required subtasks vary enough to justify an orchestrator |
| Distinct requests need different tools | Router with focused tool access | A request genuinely spans several specialties |
| Conflicting evidence needs reconciliation | Explicit evidence comparison | Separate reviewers catch errors that the baseline misses on held-out cases |
| The task is already a predictable procedure | Deterministic workflow | Model-directed choices improve a measured outcome |
These are starting hypotheses, not benchmark results. Try tool filtering, better retrieval and clearer stopping rules before attributing a baseline failure to agent count. Our MCP server architecture guide covers the tool and permission boundary; adding specialist prompts does not enforce access control.
Add an agent when you can name the work it owns and the evidence it must return.
What the research supports
Google's scaling study compares single-agent and several multi-agent architectures across financial analysis, browsing, planning and tool-use tasks. Its results depend on task structure and coordination design. The authors report benefits on decomposable workloads and losses on the sequential planning benchmark. Their research explanation also describes coordination costs in tool-heavy tasks.
That evidence supports testing decomposition. It does not supply a universal context length or tool count at which every application should switch architectures. Nor can its measured error-amplification ratios be multiplied by an unrelated application's error rate to predict that application's failures. You need matching definitions, denominators and observations before transferring such a calculation.
Anthropic's engineering guide distinguishes fixed workflows from model-directed agents and describes routing, parallelisation and orchestrator-worker patterns. Its recommendation to add complexity when justified is a useful implementation discipline. It is not proof that a particular framework will be fastest on your workload.
The MAST study examines failures involving system design, communication between agents and task verification. Use those categories when reading traces. Agreement between workers is insufficient if they share the same mistaken source or the final checker never examines the underlying evidence.
Worked case: investigating a failed customer import
Consider an assistant that investigates a failed data import and drafts a support response. This is a proposed architecture exercise, not a report of production measurements. The assistant may read a permitted customer's import log, current product documentation and an incident feed. It may draft a reply, but sending it requires approval.
Build the baseline around the actual sequence: identify the import, retrieve its failure record, check the relevant documentation, then explain the likely cause with evidence. If the log says a required field is missing, the next useful lookup depends on that result. Splitting those dependent steps across agents adds a handoff without creating independent work.
Now consider an ambiguous failure. Documentation review and incident-feed inspection can proceed independently once the product version and failure details are known. Test a fixed parallel workflow first. Give each branch the same request identifier and relevant version, require source references, and combine the returned evidence before drafting the response.
An orchestrator becomes a candidate if the investigation regularly needs different branches that cannot be selected by simple routing. Require it to record why each branch is needed. A worker returning a plausible diagnosis without the referenced log or document should produce an incomplete investigation, not an automatic success.
Keep the permission check in the tool service. Each branch receives access only to authorised records; a specialised role description is not a security boundary. Assign approval for the final outbound response explicitly. If a tool call times out after an external action, determine whether the action happened before retrying it.
Run an architecture comparison you can use
Freeze a set of representative requests and their expected outcomes. Separate routine cases, ambiguous cases and deliberate failures. Use the same source snapshot, tool behaviour, access rules and acceptance criteria for every candidate. Where you change the model or budget, record that change so it is not mistaken for an orchestration improvement.
| Proposed test | Evidence to retain | What makes the result unacceptable |
|---|---|---|
| Straightforward missing-field failure | Retrieved log, cited documentation and final draft | Unsupported explanation or an unnecessary investigation loop |
| Documentation conflicts with an incident report | Both sources, version checks and final uncertainty statement | One source silently discarded |
| Requested record belongs to another customer | Access decision and tool trace | Any unauthorised record returned |
| A worker returns an unsupported diagnosis | Worker evidence and final verification decision | Unsupported diagnosis accepted as established fact |
| A branch times out | Timeout, cancellation and recovery trace | Duplicate external action or unreported missing evidence |
| Several requests arrive together | Queue time, completion time and total spend | Limits exceeded or results assigned to the wrong request |
Measure accepted task completion, total cost including failed attempts, end-to-end latency and human correction effort. Keep failure counts beside rates and examine individual traces; an average can conceal a serious permission failure. Repeat stochastic runs with a recorded configuration and report variation. Use the agent evaluation checklist for the acceptance record and the agent cost guide for whole-task accounting.
Make the decision explicit
Write down the failure the change is meant to fix, the smallest candidate that fixes it, and the conditions for keeping it. For the import assistant, that might mean keeping parallel evidence collection only if it improves accepted completion or response time within the agreed spend limit, without weakening access checks or increasing unsupported diagnoses. Set those limits from the service requirements before inspecting the comparison results.
Judge the complete task. Fast workers are little help if their combined answer is wrong.
Keep the baseline available during rollout. Review new failure examples when models, tools or source data change. Agent count is an implementation choice that can change with the evidence; it need not become a permanent commitment to a framework.