Single agent vs multi-agent
Splitting work across agents is a context and concurrency decision, not an organisational one. Every extra agent adds a handoff, and handoffs are where information is lost.
Short answer
Use one agent with a good tool set until something forces you off it. The two things that legitimately force you off are context, when the work cannot fit usefully in one window, and concurrency, when branches are genuinely independent and running them in sequence is too slow. Splitting for any other reason, particularly to mirror how a human team is organised, buys coordination overhead, duplicated context and a new class of failure in which a sub-agent returns a confident summary that has dropped the detail the caller needed.
Multi-agent designs are attractive on a whiteboard. The diagram looks like a team, each box has a clear job, and the whole thing reads as a serious architecture. That appeal is exactly why the decision deserves scrutiny, because most of the reasoning that leads to it is analogical rather than technical.
The technical case is narrower and much more defensible. An agent's working memory is its context window, and reading-heavy work fills it with material that is needed once and then in the way. Sending that work into a separate agent with a clean window, and receiving back only its conclusion, is a genuine architectural gain: it is context isolation, and it is the strongest single reason to add a second agent. The other genuine reason is parallelism, when several lines of enquiry really are independent.
Everything else is cost. Each additional agent means another context to populate, another trajectory to debug, another prompt to maintain, and a handoff where a rich intermediate state is compressed into a message. At the Professional level, questions in this area tend to present a plausible multi-agent design and a simpler alternative, and reward the candidate who can name what the split actually buys.
One agent vs Several agents, side by side
| One agent | Several agents | |
|---|---|---|
| What you gain | Nothing to coordinate. One history, one budget, one place to look when it goes wrong. | A clean window per line of work, and real parallelism where branches are independent |
| What you pay | One window has to hold everything the task touches | Coordination, duplicated context, and cost that scales with the fan-out |
| Typical failure | The window fills, recall degrades, and later reasoning misses earlier detail | A sub-agent returns a confident summary that omits what the caller actually needed |
| Debugging | One trajectory to read end to end | One trajectory per agent, plus the handoffs between them |
| Cost profile | Roughly linear in the length of the task | Multiplied by fan-out, and the orchestrator pays again to read every result |
| Where it wins | Most tasks, including many that look like they need a team | Read-heavy search, genuinely independent branches, work that must not share a window |
The constraint is the context window, not the org chart
The instinct to decompose by role comes from how humans organise, and it does not transfer. A model does not get tired, does not need a manager, and does not benefit from being told it is a specialist in a field it was not separately trained on.
What it does have is a finite window and finite attention across it. So the question that decides the architecture is not which roles exist but whether the work fits. If a single agent can hold the task, the tools and the evidence without its recall degrading, one agent is the answer regardless of how many named activities the task contains. If it cannot, the split should follow the shape of the context problem, which is usually not the shape of a job description.
Sub-agents as context isolation
The clearest legitimate use is delegation of reading-heavy work. Searching a large corpus, scanning a long log, reading through many files: all consume enormous context to produce a small conclusion, and all leave the window full of material that will never be needed again.
Delegating that to a sub-agent with its own clean window, which returns only its finding, keeps the main agent's context focused on the actual task. The saving is not merely token cost; it is the recall of the primary agent, which stays sharp because it never had to hold the raw material. This framing is also a useful test of a proposed split: if the sub-agent's value is not that it absorbs context the caller does not need, the split may not be buying anything.
Handoffs are the lossy part, so design the contract
When a sub-agent finishes, everything it saw is discarded and only its message survives. That compression is the point, and it is also the risk, because the sub-agent decides what mattered without knowing what the caller will need next.
So the return contract deserves the same care as an API contract. State what must come back, in what structure, with what evidence attached, and what to say when the answer is that nothing was found. A sub-agent that returns a fluent paragraph has given the orchestrator something that reads well and cannot be checked. One that returns findings with identifiers, quoted passages or file references lets the caller verify and go deeper without repeating the work.
Cost and latency multiply, and parallelism is conditional
A fan-out of five is not five times the reasoning at the same price. Each sub-agent needs its own instructions and context populated, does its own work, and returns a result the orchestrator then pays to read and reconcile. Token consumption in multi-agent designs is substantially higher than a single agent doing comparable work, and it should be priced deliberately rather than discovered.
Latency only improves where the branches are genuinely independent. If a later branch needs an earlier one's finding, you have a sequence wearing a parallel diagram, plus the coordination overhead. And the whole run is as slow as its slowest branch, so a single long straggler removes most of the benefit.
Evaluate the system, not the agents
A multi-agent design tempts you into measuring each agent, because each has a definable job. Component scores are useful for diagnosis and misleading as a headline, since a system of individually competent agents can still fail at the joins.
Measure the end-to-end outcome first: did the system produce the right result on a fixed set of realistic cases, at what cost and at what latency. Then, when that number moves, use per-agent traces and the handoff messages to find out where. The handoffs deserve particular attention, because that is where the failure is least visible: nothing errored, and the information simply stopped travelling.
How to choose
Reach for one agent when
- The task, its tools and its evidence fit in one window without recall degrading
- Steps depend on each other, so there is nothing genuinely parallel to exploit
- You need one trajectory you can read end to end when something goes wrong
- Cost and latency need to stay predictable
Reach for several agents when
- Reading-heavy work would fill the main window with material needed only once
- Branches are genuinely independent and running them in sequence is too slow
- Different parts of the work must not share a context, for isolation or access reasons
- You can state precisely what each sub-agent must return, and can afford the fan-out
Where candidates go wrong
Trap 1: model the human team
A researcher agent, a writer agent and a reviewer agent is an org chart rendered as software. It feels like decomposition and it usually is not, because the three share almost all their context and hand it between each other in compressed form. The give-away is that no step needed a separate window. Three roles that all reason over the same material are three prompts, and if the sequence is fixed you have described a workflow, which can be built without agents at all. Options that justify a split by naming roles, rather than by naming a context or concurrency constraint, are the distractor.
Trap 2: specialist prompts beat one general prompt
The reasoning is that a focused persona produces better work in its area. In practice, quality in a given area is far more responsive to the tools available and the evidence supplied than to a declared specialism, and splitting to obtain a persona pays coordination cost for a prompt change you could have made in one agent. Where the underlying problem is genuine, it is usually that one agent's tool surface has grown large enough to make selection unreliable. That is a surface problem with surface remedies: expose fewer tools per task, sharpen the descriptions, or defer loading. Adding agents to solve it is an expensive way to shrink a tool list.
Trap 3: more agents means faster
Only for independent branches. Where a branch consumes another's output, the work serialises anyway and you have added orchestration on top of it. Even with true independence, the run finishes when the slowest branch finishes, so wall-clock gain is bounded by the straggler rather than by the fan-out. There is a cost half to this too. Parallel branches populate their contexts at the same time, so peak spend rises sharply, and the orchestrator then pays again to read and reconcile every result. A design that is faster and more expensive can still be the right call, but the trade should be made deliberately.
Trap 4: the orchestrator can just re-read everything
When a summary turns out to have dropped something, the tempting fix is to have sub-agents return more, or to let the orchestrator go back over the raw material itself. Both re-create the context problem the split existed to solve, and the second one does it in the window you were most trying to protect. The better response is to fix the contract rather than the volume: have the sub-agent return structured findings with references, so the orchestrator can retrieve a specific item on demand instead of receiving everything by default. If the honest conclusion is that the caller needs all of it, the split was not buying context isolation and one agent is the simpler design.
How the exam tests it
Solution Design and Architecture is 17% of the CCAR-P blueprint, roughly 11 of the 63 scored questions, and it is the largest of the seven domains. Professional-level questions here tend to present a defensible-looking design with a simpler alternative alongside it, so being able to name what a split actually buys, and what it costs, is worth more than knowing the pattern vocabulary.
Common questions
When is a multi-agent design actually justified?
When the work cannot usefully fit in one context window, or when branches are genuinely independent and sequencing them is too slow. Context isolation is the strongest case: reading-heavy work goes into a clean window and returns only its conclusion, keeping the primary agent's recall intact.
Is a specialist agent per task better than one general agent?
Usually not. Quality in an area depends far more on the tools and evidence available than on a declared specialism, and splitting to obtain a persona pays coordination cost for something you could have changed in one prompt. If the real problem is an oversized tool surface, fix the surface.
What is the main failure mode of multi-agent systems?
Lossy handoffs. Everything a sub-agent saw is discarded when it finishes, so its summary decides what survives without knowing what the caller will need next. Nothing errors; the information simply stops travelling. Specify the return contract, including structure and references, rather than accepting fluent prose.
Does splitting into agents reduce cost?
No, it generally raises it. Each agent has its own context to populate and its own instructions, and the orchestrator pays again to read and reconcile every result. Multi-agent designs consume substantially more tokens than one agent doing comparable work, so the fan-out should be priced before it is built.
How should I evaluate a multi-agent system?
End to end first, on a fixed set of realistic cases, measuring outcome, cost and latency. Per-agent scores are useful for diagnosis but misleading as a headline, because individually competent agents can still fail at the joins. Inspect the handoff messages when the end-to-end number moves.
Practise this
Solution Design & Architecture is 17% of the CCAR-P blueprint, and the bank is weighted to match. Every option carries a written explanation, not just the correct one, so a distinction like this one is explained where you get it wrong.
See CCAR-POther CCAR-P distinctions
Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.