Multi-Agent Basics
Design orchestrator-worker architectures and coordinate multiple specialized agents.
Why Multiple Agents?
Single agents hit limits: context windows fill up, specialists outperform generalists, and some tasks benefit from parallel execution.
Multi-agent systems solve these limits by distributing work across specialized agents with clean handoffs.
The Orchestrator-Worker Pattern
The most common multi-agent architecture:
Orchestrator — receives the goal, breaks it into tasks, assigns tasks to workers, collects results, synthesizes the final output.
Workers — specialized agents that execute specific task types (research, writing, coding, analysis, etc.)
Workers don't need to know about each other — only the orchestrator needs the full picture.
Task Decomposition
The orchestrator's primary skill is decomposing a complex goal into independent subtasks. Good decomposition:
- Creates tasks with clear, testable completion criteria
- Minimizes dependencies between tasks (enables parallelism)
- Matches task type to worker specialization
- Handles failure: if worker A fails, can the goal still be achieved?
Communication Patterns
Request-response — orchestrator sends task, worker returns result. Simplest; works for most cases.
Streaming — worker streams output as it's generated. Better UX for long-running tasks.
Message queue — tasks published to a queue, workers pull and process. Best for high volume, decoupled systems.
Example: Research Report Agent
Orchestrator receives: "Write a competitive analysis of X vs Y."
It spawns:
- Worker A: research X (web search tool)
- Worker B: research Y (web search tool)
- Worker C: analyze financials (data tool)
Orchestrator receives all results, then uses a final synthesis agent to write the report.
Total time: parallel workers run simultaneously, so total time ≈ slowest worker, not sum of all workers.