Strategy Agents

Overview

Strategy agents form the planning layer of your AI team. They translate business needs into actionable technical work, make architectural decisions, and coordinate execution across engineering agents. Think of them as your senior leadership team—they don't write code, but they ensure the right code gets written.

Product Manager

The Product Manager agent handles the discovery and requirements phase. It interviews stakeholders (you), identifies user needs, and produces structured documentation that engineering agents can execute against.

When to Engage

• Starting a new feature or product initiative
• Refining vague requirements into specific acceptance criteria
• Prioritizing a backlog of work
• Creating user stories from high-level goals
• Validating feature ideas before committing engineering time

Responsibilities

Key Skills

• inception-facilitator — Multi-phase product discovery for greenfield projects
• brainstorming — Creative exploration before implementation
• documentation-writer — Structured technical documentation

Invoking the Product Manager

# Start product discovery for a new feature
@product-manager Start discovery for a user notification system.
We need to alert users about important events in real-time.

# Create a PRD from existing ideas
@product-manager Create a PRD for the checkout optimization project.
Focus on reducing cart abandonment by 20%.

# Generate user stories from requirements
@product-manager Break down the PRD into user stories with acceptance criteria.

Example Outputs

# Generated PRD structure (docs/requirements/checkout-optimization.md)
├── Problem Statement
├── User Personas
├── Success Metrics
├── Functional Requirements
│   ├── FR-001: One-click checkout
│   ├── FR-002: Guest checkout flow
│   └── FR-003: Payment method memory
├── Non-Functional Requirements
├── Out of Scope
└── Open Questions

Tech Lead

The Tech Lead agent makes architectural decisions, establishes technical standards, and ensures code quality across the codebase. It bridges the gap between product requirements and technical implementation.

When to Engage

• Making significant architectural decisions
• Evaluating technology choices or trade-offs
• Establishing coding standards or review criteria
• Addressing technical debt strategically
• Reviewing complex PRs or system designs

Responsibilities

Key Skills

• platform-architect — Cloud deployment and infrastructure patterns
• design-reviewer — Technical design document review
• code-reviewer — Code quality and security review
• documentation-writer — ADRs and technical documentation

Invoking the Tech Lead

# Create an Architecture Decision Record
@tech-lead Create an ADR for choosing between REST and GraphQL
for our public API. We expect 1000+ req/s and need real-time subscriptions.

# Review a technical design
@tech-lead Review the authentication system design in docs/designs/auth.md
Check for security issues and scalability concerns.

# Address technical debt
@tech-lead Analyze technical debt in src/legacy/ and create a 
prioritized remediation plan with effort estimates.

Example Outputs

# Generated ADR (docs/decisions/ADR-007-api-protocol.md)
├── Title: Use GraphQL for Public API
├── Status: Accepted
├── Context: High-traffic API with real-time requirements
├── Decision: GraphQL with subscriptions over WebSocket
├── Consequences:
│   ├── Pro: Native subscription support
│   ├── Pro: Client-driven queries reduce over-fetching
│   ├── Con: Learning curve for team
│   └── Con: Caching complexity
└── Alternatives Considered:
    ├── REST with SSE
    └── gRPC with streaming

Work Orchestrator

The Work Orchestrator coordinates execution across all agents. It analyzes dependencies, dispatches work in parallel where possible, and tracks progress through the Beads system. Think of it as your project manager and CI/CD system combined.

When to Engage

• Executing a multi-step implementation plan
• Coordinating work across multiple agents
• Tracking progress on complex features
• Parallelizing independent tasks
• Managing dependencies between work items

Key Commands

Invoking the Work Orchestrator

# Execute an implementation plan
/execute-work docs/plans/checkout-optimization.md

# List current work items
bd list

# Check status of specific work
bd show BEAD-2024-001

# Dispatch parallel tasks manually
@work-orchestrator Execute these tasks in parallel:
1. @frontend-engineer: Build checkout form component
2. @backend-engineer: Create payment processing endpoint
3. @qa-backend: Write API integration tests

Dependency Analysis

The Work Orchestrator automatically analyzes task dependencies to maximize parallelization. Independent tasks run simultaneously, while dependent tasks wait for their prerequisites.

# Example dependency graph analysis
Task Analysis for: Checkout Optimization
─────────────────────────────────────────
Phase 1 (parallel):
  ├── [DB] Create orders table migration
  ├── [BE] Scaffold payment service
  └── [FE] Create checkout form skeleton

Phase 2 (depends on Phase 1):
  ├── [BE] Implement payment endpoints ← depends on DB, BE scaffold
  └── [FE] Build form validation ← depends on FE skeleton

Phase 3 (depends on Phase 2):
  ├── [FE] Integrate with payment API ← depends on BE endpoints, FE form
  └── [QA] Write E2E tests ← depends on FE integration

Estimated parallelization: 60% of tasks
Sequential critical path: 4 steps

Strategy Flow

The recommended flow for any significant feature follows this sequence:

┌─────────────────────────────────────────────────────────────────┐
│  1. PRODUCT MANAGER                                              │
│     ↳ Discovery → PRD → User Stories                            │
│     Output: docs/requirements/feature-name.md                    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│  2. TECH LEAD                                                    │
│     ↳ Architecture Review → ADRs → Technical Spec               │
│     Output: docs/decisions/ADR-xxx.md, docs/specs/feature.md    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│  3. WORK ORCHESTRATOR                                            │
│     ↳ Dependency Analysis → Work Items → Parallel Dispatch      │
│     Output: .beads/work-items/, execution logs                  │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│  4. ENGINEERING AGENTS                                           │
│     ↳ Implementation per specialty (parallelized)               │
│     Output: Code changes, tests, documentation                  │
└─────────────────────────────────────────────────────────────────┘

Common Patterns

Pattern: Quick Feature Validation

# When you're unsure if a feature is worth building
@product-manager Quick validation: Should we add dark mode?
Estimate effort vs. user impact. Keep analysis under 5 minutes.

Pattern: Architecture Spike

# When you need to explore technical options before committing
@tech-lead Architecture spike: Evaluate caching strategies for our API.
Options to consider: Redis, Memcached, CDN, in-memory.
Time-box: 30 minutes. Output: recommendation with trade-offs.

Pattern: Parallel Feature Development

# When multiple features can be developed simultaneously
@work-orchestrator Set up parallel development:
Feature A: User profiles (owned by @frontend-engineer)
Feature B: API rate limiting (owned by @backend-engineer)
Feature C: Database indexing (owned by @database-engineer)
Track dependencies and alert on blockers.