What is the difference between single-agent and multi-agent architectures?

What you need to know

What multi-agent actually buys you

• Context isolation. A research sub-agent can read 150,000 tokens of documents and return a 600-token summary. The orchestrator's context stays small and focused.
• Specialisation. A sub-agent with only 4 SQL tools chooses tools more accurately than one agent holding 40 tools.
• Parallelism. "Compare these 6 vendors" can run 6 sub-agents at once, so wall-clock time is close to one vendor's, not six.

What it costs

• Tokens. Each sub-agent has its own system prompt, tools and reasoning. Total spend can be several times a single agent's.
• Coordination errors. The orchestrator must describe each sub-task precisely; a vague hand-off produces the wrong work.
• Latency floor. The overall run waits for the slowest branch.
• Debugging. A bug may sit in the hand-off between two transcripts.

Tools are the seam

In practice, a sub-agent is often exposed to the orchestrator as a tool: research_vendor(name, questions) that internally runs a whole loop and returns a summary. That keeps the orchestrator's view simple and makes the sub-agent testable on its own. The sibling course on agentic patterns covers the orchestration patterns in more depth.

A real-life example

A GitHub triage bot for a large open-source project starts as one agent with 22 tools — search, labels, comments, CI logs, code search, release notes. It mislabels about 1 in 8 issues, often by calling a code-search tool when it should read CI logs.

The team splits it: an orchestrator with three tools, each backed by a sub-agent — investigate_ci_failure (CI log tools only), find_duplicates (issue search only) and locate_code (code search only). Each sub-agent returns a short structured report. Mislabels fall to about 1 in 20, and a CI log of 90,000 tokens no longer sits in the orchestrator's context.

The cost: tokens per issue roughly doubled. For a project with 300 issues a day, that was worth it. For a small repository with 5 issues a day, the single agent was fine.

Follow-up questions to expect

• "How do agents share information?" — Through the orchestrator: sub-agents return structured results, and the orchestrator passes only what the next one needs. Shared state stores are possible but harder to reason about.
• "When is multi-agent a mistake?" — For linear tasks where each step needs the previous step's full context. Splitting them adds hand-off loss and cost with no parallelism.
• "How do you debug a multi-agent run?" — One trace ID across all agents, with each sub-agent's run as a child span.