Multi-Agent Orchestration

One agent, then more, only when earned

A single agent with good tools and a tight loop handles most tasks. Multi-agent earns its complexity when sub-tasks need genuinely different context or tools — a researcher agent browsing docs, a coder agent writing patches, a reviewer agent checking the diff — and cramming all three roles into one prompt makes it sloppy at everything. If one well-scoped agent still works, stay there; coordination between agents is a new failure surface, not a free upgrade.

Three shapes that cover most cases

• Orchestrator-worker: one agent plans and dispatches, workers execute narrow sub-tasks and report back. Easiest to debug — there's one place decisions get made.
• Pipeline: fixed hand-off order (research → draft → fact-check → format). Predictable, but rigid — bad fit when the next step genuinely depends on what the last one found.
• Peer debate/review: two agents critique each other's output before it ships. Catches more errors, costs roughly double the tokens — reserve it for high-stakes outputs.

The part that actually breaks: shared state

Chat history is not shared state. If Agent B needs to know what Agent A decided, write it down in a structured form — a task ledger, a scratchpad object, a database row — rather than trusting B to correctly infer it from a long transcript. Give each agent the narrowest context it needs, not the full history by default; narrower context means fewer ways for one agent's mistake to poison another's reasoning.

Remember this

• Default to one agent; split only when roles and tools genuinely diverge.
• Orchestrator-worker is the easiest shape to debug — start there.
• Shared state belongs in an explicit structure, not implied by chat history.