Multi-Agent Coordination Pattern
Extracted from CloudOps-Runbooks operational experience. Describes the coordination philosophy that informs ADLC's agent model.
Why Specialised Agents?
A single agent attempting architecture review, cost analysis, security compliance, and deployment simultaneously produces shallow results. Specialised agents with clear boundaries produce deeper analysis within their domain while a coordination layer ensures consistency.
Design Principles
- Separation of concerns — each agent owns a single domain (architecture, testing, cost, security, deployment)
- Parallel execution where possible — independent analyses run concurrently, not sequentially
- Human-in-the-loop gates — high-impact decisions (production deployment, cost commitments) require explicit approval
- Quality gate ordering — validation must pass before parallel analysis begins
The coordination pattern described here maps directly onto ADLC's constitutional agent team: product-owner fills the Management role, cloud-architect fills the Architect role, and the specialist agents (infrastructure-engineer, qa-engineer, security-compliance-engineer, observability-engineer) fill the Domain roles.
Coordination Layout
The pattern uses role-based specialisation across three layers. Strategic agents govern and approve. Execution agents implement and validate. The Delivery layer confirms business value and executes safe production changes.
Agent Responsibilities
| Agent | Domain | Key Outputs |
|---|---|---|
| Management | Strategic oversight, approval gates | Go/no-go decisions, executive summaries |
| Development | Implementation, performance | Working code, integration tests |
| Architect | Multi-account design, security compliance | Architecture decisions, compliance validation |
| Test/QA | Coverage enforcement, benchmarking | Test reports, coverage metrics |
| Cost/FinOps | Financial analysis, optimization | Cost analysis, savings recommendations |
| Deploy | Production safety, rollback | Deployment plans, health checks |
Coordination Patterns
Pattern 1: Parallel Analysis
After the quality gate passes, independent analyses (Architect and Cost) run concurrently. Both results feed into the Management approval before deployment proceeds.
Pattern 2: Sequential Quality Gates
For risk-sensitive changes, each gate must pass before the next begins. A failure at any gate halts the pipeline.
Pattern 3: Strategic Mission
Full coordination for high-impact initiatives:
- Setup (Phase 1): Management defines objectives, Cost establishes baseline, Architect validates feasibility
- Execution (Phase 2): Development implements, Test validates, Deploy prepares
- Delivery (Phase 3): Management reviews, Cost validates impact, Deploy executes
Approval Matrix
| Change Type | Required Approvals | Rationale |
|---|---|---|
| Production changes | Management | Business continuity risk |
| Cost impact above threshold | Management + Cost | Financial commitment |
| Security changes | Management + Architect | Compliance obligation |
| Architecture changes | Management + Architect | Long-term maintainability |
Bypassing approval gates is the most consequential anti-pattern in multi-agent coordination. A single unapproved deployment can produce an uncontrolled blast radius across all accounts. The STANDALONE_EXECUTION anti-pattern specifically tracks agents that skip PO+CA coordination and proceed directly to production changes.
Anti-Patterns
| Anti-Pattern | Description | Consequence |
|---|---|---|
| Sequential masquerading as parallel | Running agents one-at-a-time | Wastes time, loses parallelism benefit |
| Bypassing quality gates | Skipping validation to save time | Undetected failures reach production |
| Technical-only focus | Missing business value quantification | Cannot justify investment |
| Approval gate bypass | Deploying without oversight | Uncontrolled blast radius |
| Over-engineering | Building new when enhancing existing works | Unnecessary complexity |
Safety Controls
- Default dry-run: Destructive operations require explicit confirmation
- Automated rollback triggers: Error rate threshold, latency degradation, availability drop
- Rate limiting: API throttling to prevent resource exhaustion
- Audit trails: Complete operation logging
Use the Safety Controls list as a pre-deployment checklist. The task validate command runs the profile connectivity check and the task sso-status command verifies SSO health before any operation touches a production account.
Applicability to ADLC
This pattern directly informs ADLC's agent team structure:
product-owner→ Management agent role (requirements, prioritisation)cloud-architect→ Architect agent role (design, security)- Specialist agents → Domain agents (infrastructure, QA, security, observability)
The key insight: coordination overhead is an investment, not waste. The approval gates and parallel execution patterns prevent the most expensive failures — those discovered in production.
Origin: CloudOps-Runbooks agent coordination experience. Adapted for ADLC framework-level guidance.