Install any skill in seconds. Free to start, no credit card required.
Get Started Free →This skill should be used when designing or implementing systems with multiple AI agents that coordinate to accomplish tasks. Triggers on "multi-agent", "orchestrator", "sub-agent", "coordination", "delegation", "parallel agents", "sequential pipeline", "fan-out", "map-reduce", "spawn agents", "agent hierarchy".
.claude/skills/aiskillstore-building-multiagent-systems/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 30% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 53% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 85% | 0% |
| case-06 | ✓→✓ | = Same ✓ | 67% | 0% |
| case-07 | ✓→✓ | = Same ✓ | 87% | 0% |
Comprehensive architecture patterns for multi-agent systems where AI agents coordinate to accomplish complex tasks using tools. Language-agnostic and applicable across TypeScript, Python, Go, Rust, and other environments.
Before architecting any system, ask these six mandatory questions:
Every agent follows the four-layer architecture for testability, safety, and modularity:
| Layer | Name | Responsibility | |-------|------|----------------| | 1 | Reasoning (LLM) | Plans, critiques, decides which tools to call | | 2 | Orchestration | Validates, routes, enforces policy, spawns sub-agents | | 3 | Tool Bus | Schema validation, tool execution coordination | | 4 | Deterministic Adapters | File I/O, APIs, shell commands, database access |
Critical Rule: Everything below Layer 1 must be deterministic. No LLM calls in tools.
See references/four-layer-architecture.md for detailed implementation with code examples.
| Pattern | Purpose | |---------|---------| | Event-Sourcing | All state changes as events for audit trails and replay | | Hierarchical IDs | Encode delegation hierarchy (e.g., session.1.2) for cost aggregation | | Agent State Machines | Explicit states (idle → thinking → tool_execution → stopped) with invalid transition errors | | Communication | EventEmitter for state changes, promises for result collection |
Choose based on discovery question answers:
| Pattern | Use Case | Trade-offs | |---------|----------|------------| | Fan-Out/Fan-In | Parallel independent work | Fast but costly; watch for orphans | | Sequential Pipeline | Multi-stage transformations | Bottleneck at slowest stage | | Recursive Delegation | Hierarchical task breakdown | Must add depth limits | | Work-Stealing Queue | 1000+ tasks with load balancing | No built-in priority | | Map-Reduce | Cost optimization | Cheap map ($0.01), smart reduce ($0.15) | | Peer Collaboration | LLM council for bias reduction | Expensive (3N+1 calls), slow | | MAKER | Zero-error tasks (100K+ steps) | 5× cost but ~0% error rate |
See references/coordination-patterns.md for detailed implementations.
| Requirement | Recommended Pattern | |-------------|---------------------| | Parallel independent tasks | Fan-Out/Fan-In | | Each stage depends on previous | Sequential Pipeline | | Complex task decomposition | Recursive Delegation | | Large batch processing | Work-Stealing Queue | | Cost-sensitive analysis | Map-Reduce | | Need diverse perspectives | Peer Collaboration | | Zero error tolerance | MAKER |
For tasks requiring 100K+ steps with zero error tolerance (medical, financial, legal domains):
Cost comparison: Same cost as traditional approach, zero errors vs. 10+ errors.
See references/maker-pattern.md for full implementation with medical diagnosis example.
| Mechanism | Purpose | |-----------|---------| | Permission Inheritance | Children inherit subset of parent permissions (cannot escalate) | | Resource Locking | Acquire/release patterns for shared resources | | Rate Limiting | Token bucket algorithm across all agents | | Result Caching | Cache read-only, idempotent, expensive operations |
Sub-Agent as Tool Pattern: Wrap specialized agents as tools the parent can call, providing composable abstractions and natural lifecycle management.
See references/tool-coordination.md for implementations.
"Always stop children before stopping self." This prevents orphaned agents.
1. Get all child agents
2. Stop all children in parallel
3. Stop self
4. Cancel ongoing work
5. Flush eventsIf pause/resume unavailable, implement manual checkpointing: save agent state (messages, context, tool results), then restore later.
| Concern | Solution | |---------|----------| | Orphan Detection | Heartbeat monitoring every 30 seconds | | Cost Tracking | Hierarchical aggregation across agent tree | | Session Persistence | Project-level task store for cross-session work | | Checkpointing | Save after 10+ tools, $1.00 cost, or 5 minutes elapsed | | Self-Modification Safety | Blast radius assessment, branch isolation, test-first |
See references/production-hardening.md for detailed implementations.
A pull request orchestrator using Fan-Out/Fan-In:
When guiding implementation of multi-agent systems:
| Pitfall | Impact | |---------|--------| | Missing four-layer architecture | Untestable, unsafe, hard to debug | | LLM calls in tools (Layer 3-4) | Non-deterministic, can't unit test | | No schema-first tool design | Sub-agents can't discover tools | | Missing cascading stop | Orphaned agents consuming resources | | No permission inheritance | Sub-agents can escalate privileges | | No timeouts | Indefinite hangs waiting for sub-agents | | Unbounded concurrency | Resource exhaustion from too many agents | | Ignoring cost tracking | Budget surprises | | No partial-failure handling | One failure cascades to all agents | | Unpersisted state | Unrecoverable workflows on crash | | Uncoordinated tool access | Race conditions on shared resources | | Wrong model selection | Cost inefficiency (Sonnet for simple tasks) | | Self-modification without safety | Sub-agents break themselves | | No heartbeat monitoring | Can't detect orphans after parent crash |
Detailed implementations with code examples:
| File | Contents | |------|----------| | references/four-layer-architecture.md | Four-layer stack, deterministic boundary, schema-first tools | | references/coordination-patterns.md | Seven coordination patterns with code | | references/maker-pattern.md | MAKER implementation, voting, medical diagnosis example | | references/tool-coordination.md | Permission inheritance, locking, rate limiting, caching | | references/production-hardening.md | Cascading stop, orphan detection, cost tracking, checkpointing |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 29,308 | 31,604 | +8% | 1 | 1 | 0% | 4,885 | 6,329 | +30% | 0 | 0 | — |
case-02 | fail→fail | 32,104 | 29,978 | -7% | 1 | 1 | 0% | 5,081 | 7,518 | +48% | 0 | 0 | — |
case-03 | fail→fail | 33,509 | 27,368 | -18% | 1 | 1 | 0% | 5,503 | 6,911 | +26% | 0 | 0 | — |
case-04 | fail→fail | 16,690 | 14,769 | -12% | 1 | 1 | 0% | 2,632 | 4,632 | +76% | 0 | 0 | — |
case-05 | fail→pass | 38,918 | 16,578 | -57% | 1 | 1 | 0% | 3,005 | 4,596 | +53% | 0 | 0 | — |
case-06 | pass→pass | 15,078 | 14,275 | -5% | 1 | 1 | 0% | 2,413 | 4,039 | +67% | 0 | 0 | — |
case-07 | pass→pass | 15,707 | 15,514 | -1% | 1 | 1 | 0% | 2,498 | 4,670 | +87% | 0 | 0 | — |
case-08 | pass→pass | 50,923 | 19,454 | -62% | 1 | 1 | 0% | 3,167 | 5,300 | +67% | 0 | 0 | — |
case-09 | fail→pass | 16,081 | 15,552 | -3% | 1 | 1 | 0% | 2,334 | 4,314 | +85% | 0 | 0 | — |
case-10 | pass→pass | 14,175 | 22,381 | +58% | 1 | 1 | 0% | 2,301 | 6,026 | +162% | 0 | 0 | — |
case-11 | pass→pass | 14,743 | 12,916 | -12% | 1 | 1 | 0% | 1,917 | 3,882 | +103% | 0 | 0 | — |
case-12 | pass→pass | 21,499 | 17,140 | -20% | 1 | 1 | 0% | 3,220 | 4,673 | +45% | 0 | 0 | — |
case-13 | pass→pass | 18,061 | 16,307 | -10% | 1 | 1 | 0% | 2,957 | 4,696 | +59% | 0 | 0 | — |
case-14 | pass→pass | 15,774 | 15,855 | +1% | 1 | 1 | 0% | 2,624 | 4,537 | +73% | 0 | 0 | — |
case-15 | pass→pass | 17,016 | 11,704 | -31% | 1 | 1 | 0% | 2,654 | 3,865 | +46% | 0 | 0 | — |
case-16 | pass→pass | 14,184 | 14,015 | -1% | 1 | 1 | 0% | 2,225 | 4,214 | +89% | 0 | 0 | — |
case-17 | pass→pass | 16,461 | 18,439 | +12% | 1 | 1 | 0% | 2,621 | 5,209 | +99% | 0 | 0 | — |
case-18 | pass→pass | 19,642 | 18,504 | -6% | 1 | 1 | 0% | 3,006 | 5,014 | +67% | 0 | 0 | — |
case-19 | pass→pass | 15,704 | 18,394 | +17% | 1 | 1 | 0% | 2,462 | 5,016 | +104% | 0 | 0 | — |
case-20 | pass→pass | 15,091 | 13,414 | -11% | 1 | 1 | 0% | 2,359 | 4,025 | +71% | 0 | 0 | — |
case-21 | pass→pass | 16,594 | 11,333 | -32% | 1 | 1 | 0% | 2,874 | 3,891 | +35% | 0 | 0 | — |
case-22 | pass→pass | 38,164 | 16,570 | -57% | 1 | 1 | 0% | 3,751 | 5,386 | +44% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +14 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.