Work Orchestration

Parallel execution, dependency waves, and automated dispatch

The Orchestration Model

Fulcrum's work orchestrator analyzes tasks, identifies dependencies, and dispatches agents in parallel waves. This isn't just automation—it's a fundamentally different way to execute software work.

Core Principle: Always maximize parallelism. Agents are free. The only thing that should ever block an agent is a real data dependency.

Wave-Based Execution

Work is organized into dependency waves. Each wave executes fully in parallel, and the next wave begins only when all dependencies are satisfied:

┌─────────────────────────────────────────────────────────────┐
│  WAVE 1 (Independent)                                       │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │ Database │  │ Frontend │  │ Backend  │  │  DevOps  │    │
│  │  Schema  │  │   Types  │  │   Types  │  │  Config  │    │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘    │
│       │             │             │             │           │
└───────┼─────────────┼─────────────┼─────────────┼───────────┘
        │             │             │             │
        ▼             ▼             ▼             ▼
┌─────────────────────────────────────────────────────────────┐
│  WAVE 2 (Depends on Wave 1)                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                  │
│  │ Backend  │  │ Frontend │  │   API    │                  │
│  │   API    │  │  Comps   │  │  Client  │                  │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘                  │
│       │             │             │                         │
└───────┼─────────────┼─────────────┼─────────────────────────┘
        │             │             │
        ▼             ▼             ▼
┌─────────────────────────────────────────────────────────────┐
│  WAVE 3 (Integration)                                       │
│  ┌──────────────────────────────────────────────┐          │
│  │           Integration Tests                   │          │
│  └──────────────────────────────────────────────┘          │
└─────────────────────────────────────────────────────────────┘

The /execute-work Command

The /execute-work command is your primary interface to the orchestrator:

# Execute all ready work items
/execute-work

# Execute specific beads
/execute-work BEAD-001 BEAD-002

# Execute with specific parallelism limit
/execute-work --max-parallel 4

What Happens When You Execute

Analysis: Orchestrator reads all pending Beads
Dependency Resolution: Builds a directed acyclic graph (DAG)
Wave Planning: Groups items into parallel execution waves
Dispatch: Spawns agents for Wave 1 items simultaneously
Monitoring: Tracks completion, handles failures, triggers next wave

Automatic dependency detection: The orchestrator infers dependencies from file paths, module imports, and explicit blocks relationships in Beads. You rarely need to declare dependencies manually.

Agent Mail

When agents run in parallel, they can't directly communicate (each has its own session). Agent Mail provides async coordination:

# Agent discovers something another agent needs to know
agent-mail send @frontend "API response shape changed, see api/types.ts"

# Agent checks for messages before starting work
agent-mail check

# Agent marks message as handled
agent-mail ack MSG-123

Common Agent Mail Patterns

Pattern	Use Case	Example
Schema Change	Database agent modifies schema	Notify backend and frontend to update types
API Contract	Backend finalizes endpoint	Notify frontend the contract is ready
Blocker Discovery	Agent finds unexpected dependency	Notify orchestrator to re-plan
Test Failure	QA finds critical issue	Notify relevant engineer to fix

Dependency Types

The orchestrator understands several dependency relationships:

blocks: Hard dependency—blocked item cannot start until blocker completes
related: Soft relationship—items may share context but can run in parallel
parent: Hierarchical—child items are subtasks of parent
discovered-from: Provenance—item was created during execution of another

# Example: Backend API blocks Frontend integration
{
  "id": "BEAD-frontend-api-client",
  "blocks": ["BEAD-backend-api"],
  "related": ["BEAD-api-types"]
}

Parallelism Strategy

Don't artificially limit parallelism. The default instinct from managing human teams is to limit work-in-progress. With agents, the opposite is true: maximize parallel execution, let dependencies be the only constraint.

When to Limit Parallelism

There are only three valid reasons to limit parallel agents:

API rate limits: External services throttle requests
Resource conflicts: Multiple agents writing to same file
Context budget: Running out of context window (rare)

Handling Failures

When an agent in a wave fails, the orchestrator:

Marks the Bead as blocked with failure reason
Continues executing other items in the wave
Skips dependent items in subsequent waves
Reports failure summary at the end

Execution Summary:
✓ Wave 1: 4/4 complete
✓ Wave 2: 2/3 complete
  ✗ BEAD-api-client failed: Type mismatch in response handler
  → Blocked: BEAD-integration-tests, BEAD-e2e-tests
✓ Wave 3: 1/1 complete (unaffected items)

Manual Orchestration

For complex scenarios, you can manually control execution:

# Hold a bead from automatic execution
bd hold BEAD-123 "Waiting for design review"

# Manually trigger a specific bead
bd trigger BEAD-123

# Re-run a failed bead after fixing issues
bd retry BEAD-123

# Skip a bead entirely
bd skip BEAD-123 "Descoped from sprint"

Next Steps

The orchestrator relies on Beads for work item tracking. Learn how Beads provide session persistence and dependency management.