$npx -y skills add muratcankoylan/Agent-Skills-for-Context-Engineering --skill multi-agent-patternsThis skill should be used when designing multi-agent systems that need context isolation, supervisor or swarm coordination, explicit handoffs, parallel execution, or a decision on whether multiple agents are justified.
| 1 | # Multi-Agent Architecture Patterns |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## When to Activate |
| 6 | |
| 7 | Activate this skill when: |
| 8 | - Single-agent context limits constrain task complexity |
| 9 | - Tasks decompose naturally into parallel subtasks |
| 10 | - Different subtasks require different tool sets or system prompts |
| 11 | - Building systems that must handle multiple domains simultaneously |
| 12 | - Scaling agent capabilities beyond single-context limits |
| 13 | - Designing production agent systems with multiple specialized components |
| 14 | |
| 15 | Do not activate this skill for adjacent work owned by other skills: |
| 16 | - Deciding task-model fit, pipeline shape, or project-level cost before topology is known: `project-development`. |
| 17 | - Designing hosted sandboxes, warm pools, remote sessions, or background runtime infrastructure: `hosted-agents`. |
| 18 | - Sharing orchestrator state through KV-cache compaction in controlled runtimes: `latent-briefing`. |
| 19 | - Designing the tools each agent exposes: `tool-design`. |
| 20 | |
| 21 | ## Core Concepts |
| 22 | |
| 23 | Use multi-agent patterns when a single agent's context window cannot hold all task-relevant information. Context isolation is the primary benefit — each agent operates in a clean context without accumulated noise from other subtasks, preventing the telephone game problem where information degrades through repeated summarization. |
| 24 | |
| 25 | Choose among three dominant patterns based on coordination needs, not organizational metaphor: |
| 26 | |
| 27 | - **Supervisor/orchestrator** — Use for centralized control when tasks have clear decomposition and human oversight matters. A single coordinator delegates to specialists and synthesizes results. |
| 28 | - **Peer-to-peer/swarm** — Use for flexible exploration when rigid planning is counterproductive. Any agent can transfer control to any other through explicit handoff mechanisms. |
| 29 | - **Hierarchical** — Use for large-scale projects with layered abstraction (strategy, planning, execution). Each layer operates at a different level of detail with its own context structure. |
| 30 | |
| 31 | Design every multi-agent system around explicit coordination protocols, consensus mechanisms that resist sycophancy, and failure handling that prevents error propagation cascades. |
| 32 | |
| 33 | ## Detailed Topics |
| 34 | |
| 35 | ### Why Multi-Agent Architectures |
| 36 | |
| 37 | **The Context Bottleneck** |
| 38 | Reach for multi-agent architectures when a single agent's context fills with accumulated history, retrieved documents, and tool outputs to the point where performance degrades. Recognize three degradation signals: the lost-in-middle effect (attention weakens for mid-context content), attention scarcity (too many competing items), and context poisoning (irrelevant content displaces useful content). |
| 39 | |
| 40 | Partition work across multiple context windows so each agent operates in a clean context focused on its subtask. Aggregate results at a coordination layer without any single context bearing the full burden. |
| 41 | |
| 42 | **The Token Economics Reality** |
| 43 | Budget for substantially higher token costs. Production data shows multi-agent systems can cost far more tokens than single-agent chat (claim-multi-agent-token-multiplier): |
| 44 | |
| 45 | | Architecture | Token Multiplier | Use Case | |
| 46 | |--------------|------------------|----------| |
| 47 | | Single agent chat | Baseline | Simple queries | |
| 48 | | Single agent with tools | Higher than baseline | Tool-using tasks | |
| 49 | | Multi-agent system | Much higher than baseline | Complex research/coordination | |
| 50 | |
| 51 | Browsing-agent evaluation research suggests token usage, tool calls, and model choice dominate performance variance (claim-evaluation-browsecomp-variance). This supports measuring multi-agent setups against single-agent baselines instead of assuming extra agents help. |
| 52 | |
| 53 | Prioritize model selection alongside architecture design — upgrading to better models often provides larger performance gains than doubling token budgets. BrowseComp data shows that model quality improvements frequently outperform raw token increases. Treat model selection and multi-agent architecture as complementary strategies. |
| 54 | |
| 55 | **The Parallelization Argument** |
| 56 | Assign parallelizable subtasks to dedicated agents with fresh contexts rather than processing them sequentially in a single agent. A research task requiring searches across multiple independent sources, analysis of different documents, or comparison of competing approaches benefits from parallel execution. Total real-world time approaches the duration of the longest subtask rather than |