# Single-Agent vs Multi-Agent

Whether one agent handles a task end-to-end or several specialized agents coordinate — a tradeoff of simplicity against parallelism and isolation.

## Why the CCAR-P exam tests this

CCAR-P tests resisting premature multi-agent complexity and recognizing the token/coordination cost each extra agent adds.

## Definition

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

- **orchestrator-worker-topology** — Single-vs-multi is whether to split at all; orchestrator-worker is a specific shape the split can take.
- **workflow-vs-agent** — Workflow-vs-agent decides if you need agency; single-vs-multi decides how many agents once you do.

## Related

- orchestrator-worker-topology
- workflow-vs-agent
- agentic-loop
- context-management
- model-selection

---

Source: Claude Cert Prep — an independent, unofficial CCAR-P study resource (domain P1). Not affiliated with Anthropic.