Single-Agent vs Multi-Agent
Also: one agent vs many · multi-agent systems · agent count decision
Whether one agent handles a task end-to-end or several specialized agents coordinate — a tradeoff of simplicity against parallelism and isolation.
Why CCAR-P tests this
CCAR-P tests resisting premature multi-agent complexity and recognizing the token/coordination cost each extra agent adds.
A single-agent design keeps one agent, one context, one loop. It's simpler to build, debug, and reason about, and it keeps all task context in one place — usually the right default.
A multi-agent design splits work across agents (e.g., an orchestrator plus workers). It shines when subtasks are parallelizable or need isolated context so one subtask's clutter doesn't pollute another's window. The cost is real: multiple agents multiply token usage, add coordination and hand-off failure modes, and make behavior harder to trace.
Choose multi-agent only when a single agent hits a concrete wall — context window pressure, a need for genuine parallelism, or cleanly separable specializations. Remember that subagents start without the parent's context, so every hand-off must be explicit. If you can't name the specific limit multi-agent solves, stay single.
Exam trap
Treating more agents as inherently more capable — extra agents mostly multiply cost and coordination risk, and the exam expects a single agent unless a concrete limit forces the split.
Commonly confused with
Related concepts
Independent, unofficial study material from Claude Cert Prep. Not affiliated with Anthropic.