hierarchical-coordinator

name	hierarchical-coordinator
description	Prevent goal drift in long-running multi-agent workflows using a coordinator agent that validates outputs against original objectives at checkpoints. Use when orchestrating 3+ agents, multi-phase features, complex implementations, or any workflow where agents may lose sight of original requirements. Trigger keywords - "hierarchical", "coordinator", "anti-drift", "checkpoint", "validation", "goal-alignment", "decomposition", "phase-gate", "shared-state", "drift detection".
version	0.1.0
tags	["orchestration","hierarchical","coordinator","anti-drift","checkpoint","validation"]
keywords	["hierarchical","coordinator","anti-drift","checkpoint","validation","goal-alignment","decomposition","phase-gate","shared-state"]
plugin	multimodel
updated	"2026-01-28T00:00:00.000Z"

Hierarchical Coordinator

Version: 1.0.0 Purpose: Prevent goal drift in multi-agent workflows through coordinated checkpoint validation Status: Production Ready

Overview

Multi-agent workflows suffer from a fundamental problem: goal drift. As agents execute phases sequentially, each agent interprets its instructions through its own lens, gradually diverging from the original user intent. By phase 4 of a 6-phase workflow, the output may address a subtly different problem than what the user requested.

The Problem:

User Request: "Add pagination to the products API endpoint"

Phase 1 (Architect): Plans pagination with cursor-based approach
  Drift: None (directly from user request)

Phase 2 (Developer): Implements cursor pagination + adds sorting + filtering
  Drift: LOW (scope creep - sorting/filtering not requested)

Phase 3 (Tester): Writes tests for sorting and filtering, light coverage on pagination
  Drift: MEDIUM (testing unrequested features, under-testing requested ones)

Phase 4 (Reviewer): Reviews sorting/filtering implementation quality
  Drift: HIGH (reviewing features user never asked for)

Result: User gets pagination + unrequested sorting/filtering,
        but pagination edge cases are untested.

The Solution:

A coordinator agent sits above specialist agents, holding the original requirements as immutable context. After each phase, the coordinator validates the output against the original goals before allowing the next phase to proceed. If drift is detected, the coordinator issues corrective guidance.

                    +---------------------+
                    |    COORDINATOR      |
                    | Holds: Requirements |
                    | Holds: Success      |
                    |   Criteria          |
                    +---------------------+
                       |    |    |    |
              Validate | OK | OK | DRIFT
                       v    v    v    v
                    +----+ +----+ +----+ +----+
                    | P1 | | P2 | | P3 | | P3 |
                    | OK | | OK | | !! | | FIX|
                    +----+ +----+ +----+ +----+

When to Use This Skill:

• Workflows with 3+ agents executing sequentially
• Multi-phase feature implementations (plan, build, test, review)
• Complex refactoring tasks spanning multiple files or systems
• Any workflow where the final output must precisely match original requirements
• Long-running workflows (>15 minutes) where drift accumulates over time

When NOT to Use:

• Simple 1-2 agent workflows (overhead exceeds benefit)
• Parallel-only workflows (no sequential drift accumulation)
• Quick tasks (<5 minutes) where drift is unlikely

---

The Coordinator Pattern

Coordinator Role Definition

The coordinator is NOT a specialist. It does not write code, design architecture, or run tests. Its sole responsibility is goal alignment:

Coordinator Responsibilities:
  1. RECEIVE original requirements and success criteria from user
  2. DECOMPOSE task into phases with clear deliverables
  3. SPAWN specialist agents for each phase
  4. VALIDATE each phase output against original goals
  5. CORRECT drift before allowing next phase
  6. REPORT final alignment status to user

Coordinator Does NOT:
  - Write code (delegate to developer agent)
  - Design architecture (delegate to architect agent)
  - Run tests (delegate to tester agent)
  - Make subjective decisions (escalate to user)

Coordinator Initialization

Before any work begins, the coordinator captures the immutable context:

Step 0: Coordinator Initialization

Write: ai-docs/coordinator-context.md

  # Coordinator Context (IMMUTABLE)

  ## Original User Request
  "[Exact user request, verbatim]"

  ## Success Criteria
  1. [Specific, measurable criterion 1]
  2. [Specific, measurable criterion 2]
  3. [Specific, measurable criterion 3]

  ## Scope Boundaries
  IN SCOPE:
  - [What the user explicitly asked for]

  OUT OF SCOPE:
  - [What the user did NOT ask for]
  - [Adjacent features that seem related but were not requested]

  ## Phases
  Phase 1: [Name] - Deliverable: [specific output]
  Phase 2: [Name] - Deliverable: [specific output]
  Phase 3: [Name] - Deliverable: [specific output]
  Phase 4: [Name] - Deliverable: [specific output]

This file is READ-ONLY during workflow execution.
No agent may modify it. Only the coordinator reads it.

Coordinator Execution Flow

Full Coordinator Workflow:

Step 1: Initialize coordinator context
  Write ai-docs/coordinator-context.md (requirements, criteria, scope)

Step 2: Initialize Tasks (all phases visible upfront)
  [ ] PHASE 1: [Architecture/Planning]
  [ ] CHECKPOINT 1: Validate Phase 1 alignment
  [ ] PHASE 2: [Implementation]
  [ ] CHECKPOINT 2: Validate Phase 2 alignment
  [ ] PHASE 3: [Testing]
  [ ] CHECKPOINT 3: Validate Phase 3 alignment
  [ ] PHASE 4: [Review]
  [ ] CHECKPOINT 4: Final alignment validation

Step 3: Execute Phase 1
  Task: specialist-agent
    Prompt: "Read ai-docs/coordinator-context.md for requirements.
             Execute Phase 1 deliverables."
    Output: [phase 1 artifacts]

Step 4: Checkpoint 1 (Coordinator validates)
  Read: Phase 1 output artifacts
  Read: ai-docs/coordinator-context.md (original requirements)
  Evaluate: Does output align with requirements?
  Write: ai-docs/checkpoint-1.md (validation result)

Step 5: Gate Decision
  If ALIGNED: Proceed to Phase 2
  If DRIFTED: Corrective action (see Anti-Drift Checkpoints)

Step 6-N: Repeat for each phase
  Execute phase -> Checkpoint -> Gate decision -> Next phase

---

Anti-Drift Checkpoints

What a Checkpoint Validates

Each checkpoint answers three questions:

Checkpoint Validation Questions:

1. COMPLETENESS: Does the output address ALL requirements?
   - Check each success criterion
   - Flag any missing deliverables
   - Score: N/M criteria addressed

2. RELEVANCE: Does the output ONLY address requirements?
   - Detect scope creep (unrequested features)
   - Detect tangential work (related but not requested)
   - Flag any out-of-scope additions

3. QUALITY: Does the output meet the expected standard?
   - Deliverable exists and is non-empty
   - Deliverable is actionable (next phase can use it)
   - No placeholder or stub content

Checkpoint Format

Structure every checkpoint evaluation consistently:

# Checkpoint [N]: Phase [Name] Validation

## Alignment Score: [ALIGNED | MINOR_DRIFT | MAJOR_DRIFT | OFF_TRACK]

## Completeness (Requirements Coverage)
- [x] Criterion 1: "Add pagination to products endpoint"
  Evidence: src/routes/products.ts implements cursor-based pagination
- [x] Criterion 2: "Support page size parameter"
  Evidence: Query parameter `limit` accepts 1-100 values
- [ ] Criterion 3: "Return total count in response"
  MISSING: Response does not include total record count

Score: 2/3 criteria met

## Relevance (Scope Adherence)
- OUT OF SCOPE: Added sorting by price (not requested)
  Files affected: src/routes/products.ts lines 45-67
- OUT OF SCOPE: Added filtering by category (not requested)
  Files affected: src/routes/products.ts lines 70-92

Score: 2 out-of-scope additions detected

## Quality
- Deliverable exists: Yes
- Actionable for next phase: Yes
- Placeholder content: None

## Verdict: MINOR_DRIFT
- Missing: Total count in response (Criterion 3)
- Extra: Sorting and filtering (not requested)

## Corrective Action
- ADD: Total count field in paginated response
- REMOVE: Sorting implementation (lines 45-67)
- REMOVE: Filtering implementation (lines 70-92)
- RE-FOCUS: Next phase should test pagination only

Drift Severity Levels

ALIGNED (No Drift):
  - All criteria addressed
  - No out-of-scope additions
  - Quality threshold met
  Action: Proceed to next phase

MINOR_DRIFT (Low Severity):
  - Most criteria addressed (>80%)
  - Small out-of-scope additions
  - Quality acceptable
  Action: Issue corrective guidance, proceed with adjustments

MAJOR_DRIFT (High Severity):
  - Significant criteria gaps (<80% addressed)
  - Large out-of-scope work
  - Quality concerns
  Action: Re-run phase with corrective instructions

OFF_TRACK (Critical):
  - Output does not address original requirements
  - Completely wrong direction
  - Fundamental misunderstanding
  Action: Escalate to user, re-evaluate approach

Corrective Actions

When drift is detected, the coordinator takes structured action:

Corrective Action Flow:

MINOR_DRIFT:
  1. Write corrective guidance to file:
     Write: ai-docs/correction-phase-N.md
       "Phase N produced minor drift:
        - Missing: [specific gaps]
        - Extra: [out-of-scope additions]
        Correction: [specific instructions for next agent]"

  2. Provide corrective context to next phase agent:
     Task: next-specialist
       Prompt: "Read ai-docs/coordinator-context.md for requirements.
                Read ai-docs/correction-phase-N.md for corrections.
                Execute Phase N+1 WITH corrections applied."

MAJOR_DRIFT:
  1. Write detailed correction:
     Write: ai-docs/correction-phase-N.md
       "Phase N produced major drift. Re-run required.
        Missing requirements: [list]
        Out-of-scope work to remove: [list]
        Specific re-run instructions: [detailed guidance]"

  2. Re-run the same phase with corrective instructions:
     Task: same-specialist
       Prompt: "Read ai-docs/coordinator-context.md for requirements.
                Read ai-docs/correction-phase-N.md for corrections.
                RE-DO Phase N following correction guidance."

  3. Re-validate at checkpoint (max 2 re-runs per phase)

OFF_TRACK:
  1. Stop workflow immediately
  2. Present user with:
     "Phase N output does not align with original requirements.

      Original request: [verbatim user request]
      Phase N produced: [summary of what was built]

      This appears to be a fundamental misalignment.
      How would you like to proceed?
      1. Provide clarified requirements
      2. Re-start from Phase 1
      3. Cancel workflow"

Maximum Drift Tolerance

Set limits to prevent infinite correction loops:

Drift Tolerance Limits:

Per-phase re-runs: Maximum 2
  After 2 re-runs of the same phase, escalate to user:
  "Phase N has been re-run twice but still shows drift.
   Manual review needed."

Consecutive minor drifts: Maximum 3
  If 3 phases in a row show MINOR_DRIFT, escalate:
  "Multiple consecutive phases showing drift.
   Requirements may need clarification."

Total workflow corrections: Maximum 5
  If 5 total corrections across all phases, pause:
  "Workflow has required 5 corrections.
   Recommend reviewing requirements before continuing."

---

Shared State via Tasks

Cross-Agent State Management

Tasks serves as the coordinator's shared state mechanism. Beyond progress tracking, it carries context between phases:

Tasks as Shared State:

Standard progress tracking:
  [ ] PHASE 1: Architecture planning
  [ ] PHASE 2: Implementation

Enhanced with coordinator state:
  [ ] PHASE 1: Architecture planning
  [ ] CHECKPOINT 1: Validate architecture alignment
  [ ] PHASE 2: Implementation
  [ ] CHECKPOINT 2: Validate implementation alignment
  [ ] DRIFT_CHECK: Overall alignment status

State Format Conventions

Use prefixed entries to distinguish state types:

Tasks State Prefixes:

PHASE:      - Standard phase tracking
CHECKPOINT: - Coordinator validation point
CONTEXT:    - Shared context between agents
DRIFT:      - Drift detection result
CORRECTION: - Corrective action applied

Example Tasks State:

  [x] PHASE 1: Architecture planning
  [x] CHECKPOINT 1: ALIGNED (3/3 criteria met)
  [x] CONTEXT: Architecture uses cursor-based pagination
  [x] PHASE 2: Implementation
  [x] CHECKPOINT 2: MINOR_DRIFT (2/3 criteria, scope creep detected)
  [x] CORRECTION: Removed sorting, added total count
  [->] PHASE 3: Testing
  [ ] CHECKPOINT 3: Validate test coverage
  [ ] PHASE 4: Code review
  [ ] CHECKPOINT 4: Final alignment check

Key Findings Propagation

The coordinator writes key findings that subsequent agents must read:

Pattern: Coordinator Writes, Next Agent Reads

After Checkpoint 1:
  Coordinator writes to ai-docs/phase-1-findings.md:
    "KEY_FINDINGS:
     - Architecture: cursor-based pagination with offset fallback
     - Data model: Products table has 50k+ rows
     - Constraint: Must maintain backward compatibility with v1 API
     - Decision: Use cursor over offset for performance

     CONTEXT FOR PHASE 2:
     - Implement cursor pagination as designed
     - Include total_count field in response
     - Do NOT add sorting or filtering (out of scope)
     - Maintain v1 API contract"

  Phase 2 agent reads this file before starting:
    Task: developer
      Prompt: "Read ai-docs/coordinator-context.md for requirements.
               Read ai-docs/phase-1-findings.md for architecture context.
               Implement pagination per architecture plan."

Clean State Between Phases

Prevent state pollution by keeping phase artifacts isolated:

State Isolation Pattern:

ai-docs/
  coordinator-context.md       # Immutable - original requirements
  phase-1-findings.md          # Phase 1 output + coordinator notes
  checkpoint-1.md              # Checkpoint 1 validation result
  phase-2-findings.md          # Phase 2 output + coordinator notes
  checkpoint-2.md              # Checkpoint 2 validation result
  correction-phase-2.md        # Correction applied (if drift)
  phase-3-findings.md          # Phase 3 output + coordinator notes
  checkpoint-3.md              # Checkpoint 3 validation result

Each phase agent reads:
  1. coordinator-context.md (always - original requirements)
  2. phase-N-1-findings.md (previous phase output)
  3. correction-phase-N-1.md (if corrections were applied)

Each phase agent writes:
  1. Its own artifacts (code, tests, docs)
  2. Brief summary for coordinator to validate

---

Phase Gate Pattern

Gate Definition

A phase gate is a formal decision point between workflow stages. The coordinator evaluates gate criteria and determines the next action:

Phase Gate Structure:

  +----------+     +----------+     +----------+
  | Phase N  | --> |   GATE   | --> | Phase    |
  | Execute  |     | Evaluate |     | N+1      |
  +----------+     +----------+     +----------+
                        |
                   +---------+
                   | PROCEED |  All criteria met
                   | RETRY   |  Criteria gaps, re-run phase
                   | ABORT   |  Critical failure, stop workflow
                   +---------+

Gate Criteria

Every gate evaluates three dimensions:

Gate Criteria:

1. DELIVERABLES PRESENT
   - All expected output files exist
   - Files are non-empty and well-formed
   - No placeholder or TODO content

2. QUALITY THRESHOLD MET
   - Code compiles / tests pass (if applicable)
   - Architecture is sound (no obvious anti-patterns)
   - Output is actionable for next phase

3. DRIFT CHECK PASSED
   - Checkpoint validation score is ALIGNED or MINOR_DRIFT
   - No OFF_TRACK or unresolved MAJOR_DRIFT
   - Corrective actions applied (if any)

Gate passes when ALL THREE dimensions are satisfied.

Gate Actions

PROCEED:
  All criteria met. Move to next phase.
  Log: "Gate N passed. Proceeding to Phase N+1."
  TaskUpdate: Mark CHECKPOINT N as completed.

RETRY:
  One or more criteria not met, but recoverable.
  Log: "Gate N failed. Re-running Phase N with corrections."
  Write: correction file with specific guidance.
  Re-execute Phase N (max 2 retries per gate).
  Re-evaluate gate after retry.

ABORT:
  Critical failure or max retries exceeded.
  Log: "Gate N failed after 2 retries. Aborting workflow."
  Save partial results.
  Present user with:
    "Workflow stopped at Phase N gate.
     Reason: [specific failure]
     Partial results saved to ai-docs/
     Options: Provide clarification, restart, or cancel."

Integration with Quality Gates Skill

The phase gate pattern extends the quality-gates skill with drift awareness:

Quality Gates + Phase Gates:

Standard Quality Gate (from quality-gates skill):
  - Issue severity classification
  - Iteration loop with max retries
  - User approval for expensive operations

Phase Gate (adds coordinator validation):
  - All quality gate criteria PLUS
  - Drift check against original requirements
  - Scope adherence validation
  - Cross-phase context propagation

Combined Flow:
  Phase N completes
    -> Quality Gate: Are there CRITICAL issues? (quality-gates)
    -> Phase Gate: Does output align with requirements? (coordinator)
    -> Both pass: Proceed
    -> Quality fails: Fix issues, re-validate
    -> Drift detected: Corrective action, re-validate
    -> Both fail: Fix both, re-run phase

---

Task Decomposition Patterns

How to Break Down Complex Tasks

The coordinator decomposes tasks based on natural phase boundaries:

Decomposition Principles:

1. EACH PHASE HAS ONE CLEAR DELIVERABLE
   Good:  "Phase 2: Implement pagination endpoint"
   Bad:   "Phase 2: Implement pagination and update docs and add tests"

2. PHASES FOLLOW NATURAL WORKFLOW ORDER
   Plan -> Build -> Test -> Review -> Accept

3. PHASES HAVE CLEAR INPUTS AND OUTPUTS
   Phase 2 Input: Architecture plan (from Phase 1)
   Phase 2 Output: Implementation files (for Phase 3)

4. PHASES ARE AGENT-ASSIGNABLE
   Each phase maps to one specialist agent type
   Phase 1: architect, Phase 2: developer, Phase 3: tester

Phase Dependency Management

Dependency Types:

SEQUENTIAL (Phase B needs Phase A output):
  Phase 1: Architecture -> Phase 2: Implementation
  Coordinator validates between phases.

  +----+  checkpoint  +----+  checkpoint  +----+
  | P1 | -----------> | P2 | -----------> | P3 |
  +----+              +----+              +----+

PARALLEL (Phases are independent):
  Phase 3a: Unit tests (for module A)
  Phase 3b: Unit tests (for module B)
  Both run simultaneously, coordinator validates after both complete.

  +----+  checkpoint  +-----+  checkpoint  +----+
  | P2 | -----------> | P3a | -----------> | P4 |
  +----+         |    +-----+    |         +----+
                 |    +-----+    |
                 +--> | P3b | ---+
                      +-----+

CONDITIONAL (Phase depends on checkpoint result):
  If Checkpoint 2 = ALIGNED: Proceed to Phase 3
  If Checkpoint 2 = MINOR_DRIFT: Run Phase 2.5 (corrections)
  If Checkpoint 2 = MAJOR_DRIFT: Re-run Phase 2

  +----+  checkpoint  +------+  +----+
  | P2 | -----------> | GATE | -| P3 |  (if aligned)
  +----+              +------+  +----+
                         |
                      +------+
                      | P2.5 |  (if minor drift)
                      +------+
                         |
                      +------+
                      | P2*  |  (if major drift, re-run)
                      +------+

Example Decompositions

Feature Implementation (4 phases):

Task: "Add user authentication with JWT"

Phase 1: Architecture Planning
  Agent: architect
  Input: User requirements
  Output: ai-docs/auth-architecture.md
  Checkpoint: Does plan cover all auth requirements?

Phase 2: Implementation
  Agent: developer
  Input: Architecture plan
  Output: src/auth/*.ts files
  Checkpoint: Does implementation match architecture?

Phase 3: Testing
  Agent: tester
  Input: Implementation files
  Output: tests/auth/*.test.ts files
  Checkpoint: Do tests cover all auth requirements?

Phase 4: Code Review
  Agent: reviewer
  Input: All source and test files
  Output: ai-docs/auth-review.md
  Checkpoint: Does review focus on auth requirements?

Complex Refactoring (5 phases):

Task: "Migrate database from MySQL to PostgreSQL"

Phase 1: Impact Analysis
  Agent: analyst
  Input: Current codebase
  Output: ai-docs/migration-impact.md
  Checkpoint: Are all affected files identified?

Phase 2: Schema Migration
  Agent: developer
  Input: Impact analysis
  Output: migration scripts, new schema files
  Checkpoint: Does schema preserve all data relationships?

Phase 3: Code Migration
  Agent: developer
  Input: Schema changes, impact analysis
  Output: Updated source files
  Checkpoint: Do code changes align with schema migration?

Phase 4: Testing
  Agent: tester
  Input: Migrated code
  Output: Test suite for new database layer
  Checkpoint: Do tests verify data integrity post-migration?

Phase 5: Validation
  Agent: reviewer
  Input: All migration artifacts
  Output: Migration validation report
  Checkpoint: Final alignment with migration requirements

Multi-Agent Code Review (3 phases with parallel):

Task: "Review authentication module for security issues"

Phase 1: Context Gathering
  Agent: analyst
  Input: Auth module source files
  Output: ai-docs/review-context.md
  Checkpoint: Is all relevant code captured?

Phase 2: Parallel Review (3 agents simultaneously)
  Agent A: security-reviewer (focus: vulnerabilities)
  Agent B: code-reviewer (focus: quality)
  Agent C: architecture-reviewer (focus: design)
  Output: 3 review reports
  Checkpoint: Do all reviews address auth security?

Phase 3: Consolidation
  Agent: coordinator (self)
  Input: 3 review reports + original requirements
  Output: Consolidated review with consensus
  Checkpoint: Final report covers all security requirements

---

Best Practices

Do:

• Initialize coordinator context BEFORE any agent execution
• Write immutable requirements file (no agent may modify it)
• Validate at EVERY phase boundary (not just at the end)
• Use structured checkpoint format (consistent, parseable)
• Propagate key findings to next phase via files
• Set maximum re-runs per phase (2) and total corrections (5)
• Keep coordinator lightweight (validate, don't implement)
• Use file-based communication between coordinator and agents
• Track drift history across phases to detect patterns

Don't:

• Skip checkpoints for "simple" phases (drift is subtle)
• Let the coordinator write code or make implementation decisions
• Re-run phases indefinitely (set limits, then escalate)
• Embed all requirements in Task prompts (use file references)
• Ignore MINOR_DRIFT (it accumulates across phases)
• Over-decompose into too many micro-phases (5-7 phases is typical)
• Use the coordinator for 1-2 agent workflows (unnecessary overhead)
• Modify the coordinator-context.md during execution
• Batch all checkpoints at the end (validate between each phase)

Overhead Considerations:

Coordinator Overhead:

Per checkpoint: ~30s (read artifacts, validate, write result)
Per correction: ~1-3 min (write guidance, re-run phase)

Workflow overhead estimate:
  4-phase workflow: 4 checkpoints x 30s = 2 min overhead
  With 1 correction: 2 min + 2 min = 4 min overhead
  With 2 corrections: 2 min + 4 min = 6 min overhead

Break-even analysis:
  Without coordinator: 15 min workflow, 30% chance of drift
  With coordinator: 17-21 min workflow, <5% chance of drift

  Value: 2-6 min overhead prevents 30-60 min rework from drift

Anti-Patterns:

Over-Decomposition:
  10+ phases for a simple feature
  Problem: More checkpoints than actual work
  Fix: Combine related phases (plan+design, implement+refactor)

Coordinator as Bottleneck:
  Coordinator does extensive analysis at each checkpoint
  Problem: 5+ min per checkpoint, workflow stalls
  Fix: Keep checkpoints lightweight (30s validation, not deep analysis)

Checkpoint Theater:
  Checkpoints always pass without real validation
  Problem: Drift goes undetected, false sense of alignment
  Fix: Check specific criteria against specific artifacts

Scope Creep in Corrections:
  Corrections add new requirements not in original request
  Problem: Coordinator itself introduces drift
  Fix: Corrections only reference original coordinator-context.md

---

Examples

Example 1: 4-Phase Feature Implementation with Coordinator

Scenario: User requests "Add pagination to the products API endpoint with cursor-based navigation and total count in response"

Execution:

Step 0: Coordinator Initialization

Write: ai-docs/coordinator-context.md
  # Coordinator Context (IMMUTABLE)

  ## Original User Request
  "Add pagination to the products API endpoint with cursor-based
   navigation and total count in response"

  ## Success Criteria
  1. Products endpoint supports cursor-based pagination
  2. Response includes total_count field
  3. Page size is configurable via query parameter
  4. Backward compatible with existing v1 API

  ## Scope Boundaries
  IN SCOPE: Pagination, cursor navigation, total count, page size
  OUT OF SCOPE: Sorting, filtering, search, new endpoints

Tasks:
  [ ] PHASE 1: Architecture planning
  [ ] CHECKPOINT 1: Validate architecture alignment
  [ ] PHASE 2: Implementation
  [ ] CHECKPOINT 2: Validate implementation alignment
  [ ] PHASE 3: Testing
  [ ] CHECKPOINT 3: Validate test coverage alignment
  [ ] PHASE 4: Code review
  [ ] CHECKPOINT 4: Final alignment validation

---

Step 1: PHASE 1 - Architecture Planning
  Task: architect
    Prompt: "Read ai-docs/coordinator-context.md.
             Design pagination architecture for products endpoint."
    Output: ai-docs/pagination-architecture.md
    Return: "Architecture plan complete. Cursor-based with total count."

Step 2: CHECKPOINT 1
  Coordinator reads ai-docs/pagination-architecture.md
  Validates against ai-docs/coordinator-context.md

  Result:
    Criterion 1: Cursor pagination designed      [MET]
    Criterion 2: Total count field planned        [MET]
    Criterion 3: Page size parameter defined      [MET]
    Criterion 4: v1 backward compat addressed     [MET]
    Out-of-scope additions: None

  Verdict: ALIGNED (4/4 criteria, no drift)
  Action: PROCEED to Phase 2

  Write: ai-docs/checkpoint-1.md
  Write: ai-docs/phase-1-findings.md

---

Step 3: PHASE 2 - Implementation
  Task: developer
    Prompt: "Read ai-docs/coordinator-context.md.
             Read ai-docs/phase-1-findings.md.
             Implement pagination per architecture plan."
    Output: src/routes/products.ts (modified)
    Return: "Implementation complete. Pagination with cursor and total count."

Step 4: CHECKPOINT 2
  Coordinator reads implementation diff
  Validates against requirements

  Result:
    Criterion 1: Cursor pagination implemented    [MET]
    Criterion 2: Total count field present         [MET]
    Criterion 3: Page size parameter works         [MET]
    Criterion 4: v1 backward compat maintained     [MET]
    Out-of-scope: Added sorting by createdAt       [DRIFT]

  Verdict: MINOR_DRIFT (4/4 criteria met, but scope creep)

  Corrective Action:
    Write: ai-docs/correction-phase-2.md
      "Remove sorting by createdAt (lines 45-52).
       Not in original requirements. Keep focus on pagination."

  Note to Phase 3:
    Write: ai-docs/phase-2-findings.md
      "Implementation complete with correction applied.
       CONTEXT: Sorting code removed. Test pagination only."

---

Step 5: PHASE 3 - Testing
  Task: tester
    Prompt: "Read ai-docs/coordinator-context.md.
             Read ai-docs/phase-2-findings.md.
             Write tests for pagination implementation."
    Output: tests/products-pagination.test.ts
    Return: "20 tests covering cursor pagination, total count, page size."

Step 6: CHECKPOINT 3
  Coordinator reads test file
  Validates test coverage against requirements

  Result:
    Criterion 1: Cursor pagination tests          [MET] (8 tests)
    Criterion 2: Total count tests                 [MET] (4 tests)
    Criterion 3: Page size tests                   [MET] (5 tests)
    Criterion 4: Backward compat tests             [MET] (3 tests)
    Out-of-scope tests: None

  Verdict: ALIGNED (4/4 criteria, all tests on-target)
  Action: PROCEED to Phase 4

---

Step 7: PHASE 4 - Code Review
  Task: reviewer
    Prompt: "Read ai-docs/coordinator-context.md.
             Review pagination implementation and tests."
    Output: ai-docs/pagination-review.md
    Return: "Review complete. 1 MEDIUM issue found."

Step 8: CHECKPOINT 4 (Final)
  Coordinator validates review focused on requirements

  Verdict: ALIGNED
  Action: Workflow complete

  Final Report:
    "Pagination feature implemented and validated.
     4/4 success criteria met.
     1 drift correction applied (Phase 2: removed scope creep).
     1 MEDIUM review issue to address.
     Total checkpoints: 4 (3 ALIGNED, 1 MINOR_DRIFT corrected)"

---

Example 2: Multi-Agent Code Review with Drift Detection

Scenario: User requests "Review the auth module for SQL injection vulnerabilities"

Execution:

Step 0: Coordinator Initialization

Write: ai-docs/coordinator-context.md
  ## Original User Request
  "Review the auth module for SQL injection vulnerabilities"

  ## Success Criteria
  1. All database queries in auth module are analyzed
  2. SQL injection vectors identified (if any)
  3. Remediation recommendations provided for each finding
  4. Risk severity classified per finding

  ## Scope
  IN SCOPE: SQL injection in auth module only
  OUT OF SCOPE: XSS, CSRF, other modules, general code quality

Tasks:
  [ ] PHASE 1: Gather auth module context
  [ ] CHECKPOINT 1: Validate context completeness
  [ ] PHASE 2a: Security reviewer (SQL injection focus)
  [ ] PHASE 2b: Code reviewer (query pattern analysis)
  [ ] CHECKPOINT 2: Validate reviews address SQL injection
  [ ] PHASE 3: Consolidation
  [ ] CHECKPOINT 3: Final alignment

---

Step 1: PHASE 1 - Context Gathering
  Task: analyst
    Output: ai-docs/auth-review-context.md (all auth DB queries)

  CHECKPOINT 1: ALIGNED (all auth queries captured)

---

Step 2: PHASE 2 - Parallel Review
  Task A: security-reviewer
    Prompt: "Focus on SQL injection vulnerabilities ONLY."
    Output: ai-docs/security-review.md

  Task B: code-reviewer
    Prompt: "Analyze query patterns for injection risks ONLY."
    Output: ai-docs/query-review.md

  CHECKPOINT 2:
    Security review: Focused on SQL injection         [ALIGNED]
    Code review: Focused on SQL injection             [ALIGNED]
    BUT code reviewer also flagged N+1 query issues   [MINOR_DRIFT]

    Verdict: MINOR_DRIFT
    Correction: "Phase 3 consolidation should exclude N+1 query findings.
                 Focus consolidation on SQL injection only."

---

Step 3: PHASE 3 - Consolidation (with correction applied)
  Coordinator consolidates reviews, excluding off-topic findings

  CHECKPOINT 3: ALIGNED
    Consolidated report covers SQL injection only
    All queries analyzed, findings classified by severity

  Final Report:
    "Auth module SQL injection review complete.
     3 queries analyzed, 1 injection risk found (HIGH severity).
     Remediation: Use parameterized query in login endpoint.
     1 drift correction applied (excluded off-topic findings)."

---

Example 3: Complex Refactoring with Checkpoint Validation

Scenario: User requests "Refactor the payment module to use the Strategy pattern for payment providers"

Execution:

Step 0: Coordinator Initialization

Write: ai-docs/coordinator-context.md
  ## Original User Request
  "Refactor payment module to use Strategy pattern for payment providers"

  ## Success Criteria
  1. PaymentStrategy interface defined
  2. Each provider implements PaymentStrategy
  3. PaymentService uses strategy injection (no switch/case)
  4. All existing tests pass after refactoring
  5. No behavior change (pure refactoring)

  ## Scope
  IN SCOPE: Strategy pattern refactoring of payment providers
  OUT OF SCOPE: New payment providers, API changes, new features

Tasks:
  [ ] PHASE 1: Impact analysis
  [ ] CHECKPOINT 1: Validate analysis completeness
  [ ] PHASE 2: Interface design
  [ ] CHECKPOINT 2: Validate Strategy pattern correctness
  [ ] PHASE 3: Implementation
  [ ] CHECKPOINT 3: Validate refactoring alignment
  [ ] PHASE 4: Test validation
  [ ] CHECKPOINT 4: Verify no behavior change
  [ ] PHASE 5: Final review
  [ ] CHECKPOINT 5: Final alignment

---

PHASE 1: Impact Analysis
  Agent: analyst
  Output: 8 files affected, 3 payment providers, 45 tests
  CHECKPOINT 1: ALIGNED

PHASE 2: Interface Design
  Agent: architect
  Output: PaymentStrategy interface + provider contracts
  CHECKPOINT 2: ALIGNED

PHASE 3: Implementation
  Agent: developer
  Output: Refactored files with Strategy pattern
  CHECKPOINT 3:
    Criterion 1: PaymentStrategy interface defined        [MET]
    Criterion 2: Providers implement interface             [MET]
    Criterion 3: No switch/case in PaymentService          [MET]
    Criterion 4: (Tested in Phase 4)                       [PENDING]
    Criterion 5: No behavior change                        [CONCERN]
      Developer added a retry mechanism to StripeStrategy
      This is a BEHAVIOR CHANGE (not pure refactoring)

    Verdict: MAJOR_DRIFT
    Action: Re-run Phase 3

    Correction: "Remove retry mechanism from StripeStrategy.
                 This is a behavior change, not a refactoring.
                 Pure refactoring only: same behavior, new structure."

  PHASE 3 (Re-run):
    Agent: developer (with correction)
    Output: Clean refactoring without behavior changes
    CHECKPOINT 3 (Re-validate): ALIGNED

PHASE 4: Test Validation
  Agent: tester
  Output: All 45 tests pass, no behavior changes detected
  CHECKPOINT 4: ALIGNED

PHASE 5: Final Review
  Agent: reviewer
  Output: Clean Strategy pattern implementation
  CHECKPOINT 5: ALIGNED

Final Report:
  "Payment module refactored to Strategy pattern.
   5/5 success criteria met.
   1 major drift corrected (Phase 3: removed behavior change).
   All 45 existing tests pass. No behavior changes."

---

Troubleshooting

Problem: Coordinator context file gets modified during execution

Cause: An agent edited coordinator-context.md

Solution: Make the file explicitly immutable in instructions

In every agent prompt, include:
  "WARNING: Do NOT modify ai-docs/coordinator-context.md.
   This file contains immutable requirements."

Validation: Coordinator can checksum the file after each phase
  to detect unauthorized modifications.

---

Problem: Checkpoints always pass (no drift detected)

Cause: Checkpoint validation is too superficial

Solution: Check specific criteria against specific artifacts

Superficial (catches nothing):
  "Does this output look correct?" -> "Yes"

Specific (catches drift):
  "Criterion 2 requires total_count in response.
   Search implementation for 'total_count' or 'totalCount'.
   Found: No. DRIFT DETECTED."

---

Problem: Too many corrections, workflow takes too long

Cause: Requirements are ambiguous, causing repeated drift

Solution: Pause and clarify requirements with user

After 3+ corrections:
  "Requirements may be ambiguous. Found drift in phases 2, 3, and 4.

   Current understanding:
   - [coordinator's interpretation]

   Is this correct, or should requirements be clarified?"

---

Problem: Coordinator adds scope during corrections

Cause: Corrective actions introduce new requirements

Solution: Corrections must only reference original coordinator-context.md

Correction validation rule:
  Every corrective instruction must trace back to a specific
  criterion in coordinator-context.md.

  "Remove sorting" -> traces to OUT OF SCOPE list
  "Add caching" -> does NOT trace to any criterion -> INVALID

---

Summary

The hierarchical coordinator prevents goal drift through:

• Immutable context (requirements captured once, never modified)
• Phase decomposition (complex tasks split into agent-assignable phases)
• Checkpoint validation (structured alignment check after each phase)
• Drift detection (ALIGNED, MINOR_DRIFT, MAJOR_DRIFT, OFF_TRACK)
• Corrective actions (specific guidance to fix drift before next phase)
• Phase gates (formal proceed/retry/abort decisions)
• Shared state (Tasks + files for cross-agent context)
• Escalation limits (max re-runs and corrections before user intervention)

The overhead is 2-6 minutes per workflow, but prevents 30-60 minutes of rework from undetected drift. Use this pattern for any workflow with 3+ agents where the final output must precisely match the original request.

---

Inspired By:

• claude-flow queen-worker hierarchy (simplified for Claude Code plugins)
• /implement command multi-phase workflows
• /review command validation patterns
• quality-gates skill (extended with drift awareness)
• task-orchestration skill (enhanced with coordinator state)