Multi-Agent Coordinator

Your agent for orchestrating complex workflows that span multiple specialized agents — managing task decomposition, inter-agent communication, parallel execution, and result synthesis.

When to Use This Agent

Choose Multi-Agent Coordinator when:

• Tasks require multiple specialized agents working together
• Complex workflows need parallel execution with dependency management
• Results from different agents need to be synthesized into a unified output
• Cross-cutting tasks span multiple domains (frontend + backend + testing)
• You need to orchestrate plan → implement → test → review workflows

Consider alternatives when:

• A single specialized agent can handle the task — use it directly
• You need simple sequential tasks — call agents one at a time
• You need architecture design — use an architect agent

Quick Start

Copy
# .claude/agents/multi-agent-coordinator.yml
name: Multi-Agent Coordinator
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
  - Task
description: Workflow orchestration agent for coordinating multiple specialized agents, managing dependencies, and synthesizing results

Example invocation:

claude "Implement the user notifications feature end-to-end — coordinate backend API development, frontend UI, database schema changes, and integration tests across the appropriate specialist agents"

Core Concepts

Coordination Patterns

Pattern	Use Case	Example
Sequential	Steps with dependencies	Plan → Implement → Test → Review
Parallel	Independent tasks	Frontend + Backend + Docs simultaneously
Fan-out/Fan-in	Parallel work + aggregation	Multiple file changes → unified PR
Pipeline	Data transformation chain	Analyze → Design → Build → Verify
Supervisor	Error handling + retry	Monitor agents, retry on failure

Task Decomposition

Complex Task: "Add user notification system"
│
├── Phase 1: Planning (Sequential)
│   └── Architect Agent → Design system, define interfaces
│
├── Phase 2: Implementation (Parallel)
│   ├── Backend Agent → API endpoints, service logic
│   ├── Frontend Agent → UI components, state management
│   └── Database Agent → Schema migration, queries
│
├── Phase 3: Integration (Sequential)
│   └── Integration Agent → Wire components, test connectivity
│
└── Phase 4: Quality (Parallel)
    ├── Test Agent → Write and run tests
    ├── Review Agent → Code review
    └── Doc Agent → Update documentation

Configuration

Parameter	Description	Default
execution_mode	Orchestration mode (sequential, parallel, adaptive)	adaptive
error_strategy	Error handling (fail-fast, retry, skip)	retry
max_parallel	Maximum parallel agent tasks	3
sync_points	Required checkpoints between phases	per-phase
result_synthesis	How to combine results (merge, report, unified-pr)	merge

Best Practices

1. Decompose tasks by domain, not by file. Split work by area of expertise (frontend, backend, database), not by individual files. Domain-aligned tasks are more coherent and reduce coordination overhead between agents.

2. Define clear interfaces between parallel tasks. Before launching parallel agents, agree on the interfaces (API contracts, data schemas, component props) that connect their work. This prevents integration failures when combining parallel results.

3. Use synchronization points between phases. Don't start the testing phase until all implementation is complete. Use explicit checkpoints where you verify that the previous phase's output meets the next phase's input requirements.

4. Handle agent failures gracefully. When one agent fails, decide whether to retry (transient error), skip (non-critical task), or abort (critical dependency). Don't let one failed agent block all other progress.

5. Synthesize results into a unified deliverable. After all agents complete, combine their outputs into a coherent whole — a single PR with logical commits, a unified test report, or a deployment-ready set of changes. Disconnected agent outputs create integration debt.

Common Issues

Parallel agents produce conflicting changes. Two agents modifying the same file create merge conflicts. Assign clear file ownership boundaries before launching parallel agents, and use a merge step after parallel execution to resolve any overlaps.

Coordination overhead exceeds the benefit of parallelization. For small tasks, the overhead of decomposing, coordinating, and synthesizing multi-agent work is more expensive than having one agent do everything. Use multi-agent coordination only for genuinely complex, multi-domain tasks.

Agent results are incompatible because they made different assumptions. The backend agent assumes REST while the frontend agent builds for GraphQL. Establish shared specifications and interfaces before starting parallel implementation to ensure all agents work toward the same design.