Task Coordination Strategies

Task Coordination Strategies

Strategies for decomposing complex tasks into parallelizable units, designing dependency graphs, writing effective task descriptions, and monitoring workload across agent teams.

When to Use This Skill

• Breaking down a complex task for parallel execution
• Designing task dependency relationships (blockedBy/blocks)
• Writing task descriptions with clear acceptance criteria
• Monitoring and rebalancing workload across teammates
• Identifying the critical path in a multi-task workflow

Task Decomposition Strategies

By Layer

Split work by architectural layer:

• Frontend components
• Backend API endpoints
• Database migrations/models
• Test suites

Best for: Full-stack features, vertical slices

By Component

Split work by functional component:

• Authentication module
• User profile module
• Notification module

Best for: Microservices, modular architectures

By Concern

Split work by cross-cutting concern:

• Security review
• Performance review
• Architecture review

Best for: Code reviews, audits

By File Ownership

Split work by file/directory boundaries:

• src/components/ — Implementer 1
• src/api/ — Implementer 2
• src/utils/ — Implementer 3

Best for: Parallel implementation, conflict avoidance

Dependency Graph Design

Principles

1. Minimize chain depth — Prefer wide, shallow graphs over deep chains 2. Identify the critical path — The longest chain determines minimum completion time 3. Use blockedBy sparingly — Only add dependencies that are truly required 4. Avoid circular dependencies — Task A blocks B blocks A is a deadlock

Patterns

Independent (Best parallelism):

Task A ─┐
Task B ─┼─→ Integration
Task C ─┘

Sequential (Necessary dependencies):

Task A → Task B → Task C

Diamond (Mixed):

        ┌→ Task B ─┐
Task A ─┤          ├→ Task D
        └→ Task C ─┘

Using blockedBy/blocks

TaskCreate: { subject: "Build API endpoints" }         → Task #1
TaskCreate: { subject: "Build frontend components" }    → Task #2
TaskCreate: { subject: "Integration testing" }          → Task #3
TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] }  → #3 waits for #1 and #2

Task Description Best Practices

Every task should include:

1. Objective — What needs to be accomplished (1-2 sentences) 2. Owned Files — Explicit list of files/directories this teammate may modify 3. Requirements — Specific deliverables or behaviors expected 4. Interface Contracts — How this work connects to other teammates' work 5. Acceptance Criteria — How to verify the task is done correctly 6. Scope Boundaries — What is explicitly out of scope

Template

## Objective
Build the user authentication API endpoints.

## Owned Files
- src/api/auth.ts
- src/api/middleware/auth-middleware.ts
- src/types/auth.ts (shared — read only, do not modify)

## Requirements
- POST /api/login — accepts email/password, returns JWT
- POST /api/register — creates new user, returns JWT
- GET /api/me — returns current user profile (requires auth)

## Interface Contract
- Import User type from src/types/auth.ts (owned by implementer-1)
- Export AuthResponse type for frontend consumption

## Acceptance Criteria
- All endpoints return proper HTTP status codes
- JWT tokens expire after 24 hours
- Passwords are hashed with bcrypt

## Out of Scope
- OAuth/social login
- Password reset flow
- Rate limiting

Workload Monitoring

Indicators of Imbalance

Rebalancing Steps

1. Call TaskList to assess current state 2. Identify idle or overloaded teammates 3. Use TaskUpdate to reassign tasks 4. Use SendMessage to notify affected teammates 5. Monitor for improved throughput

Dependency Graph Patterns

Visual patterns for task dependency design with trade-offs.

Pattern 1: Fully Independent (Maximum Parallelism)

Task A ─┐
Task B ─┼─→ Final Integration
Task C ─┘

• Parallelism: Maximum — all tasks run simultaneously
• Risk: Integration may reveal incompatibilities late
• Use when: Tasks operate on completely separate files/modules
• TaskCreate: No blockedBy relationships; integration task blocked by all

Pattern 2: Sequential Chain (No Parallelism)

Task A → Task B → Task C → Task D

• Parallelism: None — each task waits for the previous
• Risk: Bottleneck at each step; one delay cascades
• Use when: Each task depends on the output of the previous (avoid if possible)
• TaskCreate: Each task blockedBy the previous

Pattern 3: Diamond (Shared Foundation)

           ┌→ Task B ─┐
Task A ──→ ┤          ├→ Task D
           └→ Task C ─┘

• Parallelism: B and C run in parallel after A completes
• Risk: A is a bottleneck; D must wait for both B and C
• Use when: B and C both need output from A (e.g., shared types)
• TaskCreate: B and C blockedBy A; D blockedBy B and C

Pattern 4: Fork-Join (Phased Parallelism)

Phase 1:  A1, A2, A3  (parallel)
          ────────────
Phase 2:  B1, B2      (parallel, after phase 1)
          ────────────
Phase 3:  C1          (after phase 2)

• Parallelism: Within each phase, tasks are parallel
• Risk: Phase boundaries add synchronization delays
• Use when: Natural phases with dependencies (build → test → deploy)
• TaskCreate: Phase 2 tasks blockedBy all Phase 1 tasks

Pattern 5: Pipeline (Streaming)

Task A ──→ Task B ──→ Task C
  └──→ Task D ──→ Task E

• Parallelism: Two parallel chains
• Risk: Chains may diverge in approach
• Use when: Two independent feature branches from a common starting point
• TaskCreate: B blockedBy A; D blockedBy A; C blockedBy B; E blockedBy D

Anti-Patterns

Circular Dependency (Deadlock)

Task A → Task B → Task C → Task A  ✗ DEADLOCK

Fix: Extract shared dependency into a separate task that all three depend on.

Unnecessary Dependencies

Task A → Task B → Task C
(where B doesn't actually need A's output)

Fix: Remove the blockedBy relationship; let B run independently.

Star Pattern (Single Bottleneck)

     ┌→ B
A →  ├→ C  → F
     ├→ D
     └→ E

Fix: If A is slow, all downstream tasks are delayed. Try to parallelize A's work.

Task Decomposition Examples

Practical examples of decomposing features into parallelizable tasks with clear ownership.

Example 1: User Authentication Feature

Feature Description

Add email/password authentication with login, registration, and profile pages.

Decomposition (Vertical Slices)

Stream 1: Login Flow (implementer-1)

• Owned files: src/pages/login.tsx, src/api/login.ts, tests/login.test.ts
• Requirements: Login form, API endpoint, input validation, error handling
• Interface: Imports AuthResponse from src/types/auth.ts

Stream 2: Registration Flow (implementer-2)

• Owned files: src/pages/register.tsx, src/api/register.ts, tests/register.test.ts
• Requirements: Registration form, API endpoint, email validation, password strength
• Interface: Imports AuthResponse from src/types/auth.ts

Stream 3: Shared Infrastructure (implementer-3)

• Owned files: src/types/auth.ts, src/middleware/auth.ts, src/utils/jwt.ts
• Requirements: Type definitions, JWT middleware, token utilities
• Dependencies: None (other streams depend on this)

Dependency Graph

Stream 3 (types/middleware) ──→ Stream 1 (login)
                             └→ Stream 2 (registration)

Example 2: REST API Endpoints

Feature Description

Add CRUD endpoints for a new "Projects" resource.

Decomposition (By Layer)

Stream 1: Data Layer (implementer-1)

• Owned files: src/models/project.ts, src/migrations/add-projects.ts, src/repositories/project-repo.ts
• Requirements: Schema definition, migration, repository pattern
• Dependencies: None

Stream 2: Business Logic (implementer-2)

• Owned files: src/services/project-service.ts, src/validators/project-validator.ts
• Requirements: CRUD operations, validation rules, business logic
• Dependencies: Blocked by Stream 1 (needs model/repository)

Stream 3: API Layer (implementer-3)

• Owned files: src/routes/projects.ts, src/controllers/project-controller.ts
• Requirements: REST endpoints, request parsing, response formatting
• Dependencies: Blocked by Stream 2 (needs service layer)

Task Template

## Task: {Stream Name}

### Objective

{1-2 sentence description of what to build}

### Owned Files

- {file1} — {purpose}
- {file2} — {purpose}

### Requirements

1. {Specific deliverable 1}
2. {Specific deliverable 2}
3. {Specific deliverable 3}

### Interface Contract

- Exports: {types/functions this stream provides}
- Imports: {types/functions this stream consumes from other streams}

### Acceptance Criteria

- [ ] {Verifiable criterion 1}
- [ ] {Verifiable criterion 2}
- [ ] {Verifiable criterion 3}

### Out of Scope

- {Explicitly excluded work}