Single-Agent vs. Multi-Agent Architectures

Single-Agent vs. Multi-Agent (Orchestrator/Sub-Agent) Architectures

A single agent handles the whole task in one continuous context — simplest to reason about, but its context window fills up with every intermediate tool result, which can crowd out the original goal on long tasks.

A multi-agent (orchestrator/sub-agent) architecture splits work: an orchestrator agent breaks a large goal into sub-tasks and dispatches each to a fresh sub-agent with its own clean context. Sub-agents return a summary, not their full transcript, back to the orchestrator. This trades added coordination complexity for context isolation — each sub-agent stays focused and the orchestrator's context doesn't balloon with implementation detail it doesn't need.

Exam-style signal: if a scenario describes context getting "crowded" or a task naturally decomposing into independent parallel pieces, multi-agent orchestration is the architecturally correct answer over one large single-agent loop.

Planning Before Acting

For any non-trivial multi-step task, an agent that plans explicitly before executing tends to outperform one that acts step-by-step with no upfront plan — the plan gives the agent (and a human reviewer) a checkpoint to catch a flawed approach before tool calls start mutating real state.

This is why many production agent architectures separate a planning phase (produce a task list, optionally get human approval) from an execution phase (work through the list, one item at a time, updating status as it goes) — rather than interleaving reasoning and irreversible actions from the first turn.