Multi-agent orchestration

A single agent is one model instance running the tool-call loop covered earlier in this domain. Multi-agent orchestration means multiple separate loop instances, each with its own system prompt and tool set, coordinating on one overall task — typically through one of two shapes:

Both are real, shipped patterns — not academic. The orchestrator-worker shape shows up in deep-research-style products where independent sub-questions can genuinely be investigated in parallel; the handoff shape shows up in support systems where one broad "front door" agent routes to narrower specialists.

Splitting pays off when the sub-tasks are genuinely independent (so they can run in parallel and cut wall-clock time) or genuinely require different tool sets and system prompts that would otherwise have to coexist awkwardly in one bloated prompt. A single agent trying to be simultaneously an expert at SQL query generation, customer tone, and refund policy has three different jobs crammed into one prompt — the model's attention is split across three concerns whenever it's really only doing one of them at a time. Specializing that into three agents, each with a tight prompt and a narrow tool catalog, often measurably improves reliability on each individual job.

Multi-agent systems multiply, not add, several costs: token spend (each agent's own context, tools, and reasoning all get billed independently — a research system with an orchestrator and four workers can burn several times the tokens of one agent doing the whole task serially), latency (coordination round-trips between agents), and debuggability (a wrong final answer now requires figuring out which of N agents' outputs was actually the problem, versus reading one transcript). If the "specialization" a second agent would provide is really just "a different paragraph of the same system prompt," a single agent with a well-organized prompt is almost always the better first attempt.

Single-agent systems fail in ways covered elsewhere in this domain — bad tool calls, hallucinated arguments, stale context. Multi-agent systems fail in those same ways per agent, plus new failure modes that only exist because there's more than one: an orchestrator that hands a worker an ambiguous sub-task and can't tell the resulting answer is wrong because it never had the detail to check; two agents each holding slightly different, un-synced context about the same user; a handoff that drops the reason for the handoff, so the receiving agent restarts the conversation from nothing. These are genuinely harder to catch than a single bad tool call, because the bug isn't in any one agent's logic — it's in the coordination between them.

Start with one agent. Split only when you can name the specific, concrete thing splitting buys you — parallel wall-clock time on genuinely independent sub-tasks, or a prompt that's grown so overloaded it's measurably hurting reliability on its own job — not because multi-agent sounds more sophisticated. The complexity cost is real and compounds; it should be paid for something specific, not by default.