Parallel Execution
How to run multiple agents simultaneously for maximum speed
The Paradigm Shift
Human developers are scarce and expensive. You can't spin up five senior engineers at 2am to parallelize a feature. But agents? Agents are infinite. They're stateless AI processes that cost pennies per hour and can run 24/7.
Core Insight: Stop thinking about "how many agents can I afford?" Start thinking about "what's blocking me from running more agents?"
This isn't about replacing humans—it's about multiplying throughput. One human architect directs strategy while dozens of agents execute in parallel. That's the Fulcrum model.
When to Parallelize vs. When to Sequence
Parallelize When
- Tasks are independent: No shared state or output dependencies
- Different subsystems: Frontend, backend, database, infra work
- Research/exploration: Multiple approaches can be tried simultaneously
- Test coverage: Different test suites can run in parallel
- Documentation: Docs for different features don't conflict
Sequence When
- Data dependencies: Task B needs output from Task A
- Shared files: Multiple agents writing to the same file
- API contracts: Frontend waiting for backend to define the contract
- Schema migrations: Must be applied in order
Common mistake: Over-sequencing out of habit. "We always do backend first" isn't a dependency—it's a convention. Challenge every sequence.
Wave-Based Execution Pattern
Fulcrum organizes work into "waves" based on dependency analysis. Each wave executes fully in parallel, then the next wave begins:
┌─────────────────────────────────────────────────────────────────────────┐
│ WAVE 1 │
│ (No dependencies) │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Agent A │ │ Agent B │ │ Agent C │ │ Agent D │ │
│ │ Database │ │ Backend │ │ Frontend │ │ DevOps │ │
│ │ Schema │ │ Models │ │ Types │ │ Configs │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │ │
└─────────┼─────────────────┼─────────────────┼─────────────────┼──────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ WAVE 2 │
│ (Needs Wave 1 outputs) │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Agent E │ │ Agent F │ │ Agent G │ │
│ │ Backend │ │ Frontend │ │ API │ │
│ │ Services │ │ Components│ │ Client │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
└────────────────┼─────────────────┼─────────────────┼─────────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ WAVE 3 │
│ (Integration) │
│ │
│ ┌───────────────────────────────┐ │
│ │ Agent H │ │
│ │ Integration Tests │ │
│ └───────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘Example: Building a Feature with 3 Parallel Agents
Let's build a "User Notifications" feature. Traditional approach: one developer works through each layer sequentially. Fulcrum approach: three agents work simultaneously.
Step 1: Analyze and Plan
# Ask the orchestrator to analyze the task
You: Build a user notifications feature with email and in-app support
# Orchestrator identifies three independent tracks:
- Database: notification_preferences table, notifications table
- Backend: NotificationService, email integration, API endpoints
- Frontend: NotificationBell component, preferences UI, real-time updatesStep 2: Dispatch Parallel Agents
# Dispatch three agents simultaneously
/dispatch @backend-engineer "Create NotificationService with email integration.
- Add notification_preferences and notifications tables
- Implement send(), markRead(), getUserNotifications()
- Integrate SendGrid for email delivery"
/dispatch @frontend-engineer "Build notification UI components.
- NotificationBell with unread count badge
- NotificationDropdown with list of notifications
- NotificationPreferences settings page
- Use WebSocket for real-time updates"
/dispatch @devops-engineer "Set up notification infrastructure.
- Configure SendGrid API keys in secrets
- Set up WebSocket server for real-time
- Add notification-related monitoring/alerts"Step 3: Monitor Progress
# Check status of all running agents
/status
# Output:
┌────────────────────────────────────────────────────────┐
│ PARALLEL EXECUTION STATUS │
├────────────────────┬───────────┬───────────────────────┤
│ Agent │ Status │ Progress │
├────────────────────┼───────────┼───────────────────────┤
│ @backend-engineer │ Running │ NotificationService ✓ │
│ │ │ Email integration... │
├────────────────────┼───────────┼───────────────────────┤
│ @frontend-engineer │ Running │ NotificationBell ✓ │
│ │ │ Dropdown ✓ │
│ │ │ Preferences... │
├────────────────────┼───────────┼───────────────────────┤
│ @devops-engineer │ Complete │ All tasks done │
└────────────────────┴───────────┴───────────────────────┘Commands for Parallel Dispatch
| Command | Description | Example |
|---|---|---|
/dispatch | Send a task to a specific agent | /dispatch @backend "Build user API" |
/execute-work | Execute all ready work items | /execute-work --max-parallel 5 |
/status | Check status of all running agents | /status |
/wait | Wait for specific agents to complete | /wait @backend @frontend |
/cancel | Cancel a running agent | /cancel @backend |
Agent Mail Coordination
When agents run in parallel, they can't directly talk to each other. Agent Mail provides asynchronous coordination:
# Backend agent discovers the API shape
# It sends mail to frontend agent
agent-mail send @frontend-engineer "API contract finalized:
GET /api/notifications - returns { notifications: Notification[], unreadCount: number }
POST /api/notifications/:id/read - marks as read
WebSocket event: 'new-notification' with Notification payload"
# Frontend agent checks mail before integrating
agent-mail check
# Frontend agent acknowledges
agent-mail ack MSG-001 "Implementing against this contract"Best Practice: Have agents send mail proactively when they finalize something another agent might need. Don't wait to be asked.
Common Mail Patterns
- Contract Ready: "API shape finalized, see types.ts"
- Blocker Found: "Need database schema before I can proceed"
- Schema Changed: "Added new column, update your queries"
- Test Failure: "Your component breaks my integration test"
The Math That Matters
Key Opinion: 5 sequential 10-minute tasks = 50 minutes. 5 parallel tasks = 10 minutes. Always parallelize.
The math is simple but the implications are profound:
| Approach | 5 Tasks × 10 min each | Total Time | Speedup |
|---|---|---|---|
| Sequential | 10 + 10 + 10 + 10 + 10 | 50 minutes | 1x |
| Parallel (5 agents) | max(10, 10, 10, 10, 10) | 10 minutes | 5x |
In practice, the speedup is often even greater because:
- Agents don't get distracted or context-switch
- No communication overhead between agents (just mail)
- No waiting for reviews or approvals mid-task
- Failures in one track don't block other tracks
Anti-Patterns to Avoid
❌ Over-Sequencing
# Bad: Unnecessary sequential execution
/dispatch @backend "Build API"
/wait @backend
/dispatch @frontend "Build UI" # Why wait? Types could be mocked!
# Good: Parallel with contract
/dispatch @backend "Build API, send contract to @frontend via mail"
/dispatch @frontend "Build UI, check mail for API contract"❌ Shared File Conflicts
# Bad: Two agents editing the same file
/dispatch @agent-a "Add function foo() to utils.ts"
/dispatch @agent-b "Add function bar() to utils.ts" # Conflict!
# Good: Coordinate or separate
/dispatch @agent-a "Add function foo() to utils/foo.ts"
/dispatch @agent-b "Add function bar() to utils/bar.ts"❌ Ignoring Dependencies
# Bad: Frontend builds against undefined API
/dispatch @frontend "Build user profile page" # What API?
# Good: Define contract first or use stubs
/dispatch @frontend "Build user profile page using mock API.
Real API contract will arrive via agent mail."Next Steps
Parallel execution works best when agents have domain knowledge. Learn how to customize the Domain Expert for your specific business context.