multi-agent-patternslisted

# Multi-Agent Architecture Patterns Multi-agent architectures distribute work across multiple language model instances, each with its own context window. When designed well, this distribution enables capabilities beyond single-agent limits. When designed poorly, it introduces coordination overhead that negates benefits. The critical insight is that sub-agents exist primarily to isolate context, not to anthropomorphize role division. ## When to Use - Single-agent context limits constrain task complexity - Tasks decompose naturally into parallel subtasks - Different subtasks require different tool sets or system prompts - Building systems that must handle multiple domains simultaneously - Scaling agent capabilities beyond single-context limits - Designing production agent systems with multiple specialized components ## When NOT to Use - Agent memory or persistence across sessions (use memory-systems) - Tool design or tool interfaces (use tool-design) - Hosted agent infrastructure or sandboxed VMs (use hosted-agents) - BDI cognitive models or mental state modeling (use bdi-mental-states) - Simple tasks that fit within a single context window (no need for multi-agent) ## Decision Tree ``` Do you need multiple agents? │ ├─ Single-agent context limits reached? │ ├─ YES → Continue │ └─ NO → Single agent is simpler and cheaper; stay with it │ ├─ How should agents coordinate? │ ├─ Central control needed? → Supervisor/Orchestrator │ │ ├─ Need strict workflow control? → Supe