Day 41 (Bonus): The Orchestrator + Worker Pattern
One coordinates, others execute. Orchestrator never does specialist work. Workers never coordinate. Strict separation is what makes it reliable. Most reliable pattern.
Hey, it's G.
Day 41 of the Claude Code series.
Phase 5: Multi-Agent Systems continues.
Day 40 was about designing multi-agent systems from scratch.
Day 41 is about the specific pattern that shows up in almost every reliable multi-agent setup.
The orchestrator and worker pattern.
Once I understood this pattern properly it became the default way I think about any task too big for one session.
It's not complicated.
It's just disciplined.
The Problem (Agents That Try to Do Everything)
You set up a multi-agent system.
One agent to coordinate.
Multiple agents to execute.
Sounds good.
What Actually Happens
The orchestrator starts coordinating.
Then it sees a small API issue.
"I'll just fix this myself real quick."
Now it's writing code.
Now it's distracted from coordination.
Now it's lost track of which workers have completed and which are waiting.
Or the opposite:
A worker finishes its piece.
Sees that another worker is blocked.
"I'll just help them out."
Now the worker is coordinating.
Now it's outside its scope.
Now you have unclear ownership and conflicts.
When an agent tries to both coordinate and execute, it does both worse.
The Concept (One Coordinates, Others Execute)
The orchestrator and worker pattern is simple:
One agent coordinates.
Multiple agents execute.
The Orchestrator
Never does the actual work.
It reads the task.
Breaks it into pieces.
Assigns each piece to the right worker.
Monitors progress.
Synthesizes results.
Its entire job is coordination.
The Workers
Never coordinate.
Each one receives a clear task.
Executes it within defined boundaries.
Reports back.
Workers don't talk to each other.
They talk only to the orchestrator.
Why This Separation Matters
Cognitive load.
When an agent tries to both coordinate and execute:
- The orchestrator writing code starts making architectural decisions based on implementation details it's seeing mid-task
- The worker that also coordinates loses focus on the specific job it was assigned
Separation keeps each agent sharp at exactly one thing.
The Engineering Team Parallel
This maps directly to how good engineering teams work.
A tech lead who also writes all the code?
Bottleneck.
A tech lead who coordinates clearly and trusts specialists to execute?
Force multiplier.
Same pattern. Same results.
Three Roles in the Pattern
Orchestrator
Reads the full task
Breaks into worker assignments
Assigns with clear scope and interface specs
Waits for worker completion
Validates worker output
Handles blockers and re-assignments
Synthesizes final result
Coordinates. Never executes.
Worker (One Per Piece of Work)
Receives one clear assignment
Executes within defined boundaries
Reports completion with what was produced
Never assigns work to other agents
Executes. Never coordinates.
Reviewer (Optional But Recommended)
Receives completed work from all workers
Checks for consistency and quality
Reports issues back to orchestrator
Never modifies — reports only
Quality gate. Read-only.
What Makes a Good Orchestrator Prompt
The orchestrator is only as good as its initial assignment.
Three things every orchestrator prompt needs:
1. The Full Task
What the end result should look like.
Not just "build a feature."
"Build a team billing dashboard showing seats, usage, and subscription management."
2. The Worker Roster
Which workers are available and what each one does.
Workers available:
- api-agent: API routes and TypeScript types
- frontend-agent: UI components and pages
- test-agent: tests for completed code
- docs-agent: documentation updates
3. The Sequencing Rules
Which workers can run in parallel and which must wait.
Constraints:
- api-agent must complete before frontend-agent starts
- test-agent runs after both api and frontend complete
- docs-agent runs last
Clear task. Clear roster. Clear sequence.
That's what the orchestrator needs.
How to Implement It
Step 1: Define the Orchestrator Agent
touch .claude/agents/orchestrator.md
---
name: orchestrator
description: Coordinates multi-agent workflows. Use when
a task is too large for one session or requires
parallel specialist work. Breaks tasks into
worker assignments, monitors completion,
synthesizes results. Never does specialist work.
tools: Read, Bash, Glob, Grep
---
You are a coordination specialist. You never write
application code, tests, or documentation yourself.
Your workflow for every task:
## Step 1 — Understand
Read the full task. Identify all deliverables.
Ask clarifying questions before assigning anything.
## Step 2 — Break Down
List every piece of work needed.
For each piece identify:
- Which worker owns it
- What input it needs
- What output it produces
- Whether it depends on another worker's output
## Step 3 — Assign
Present the assignment plan before executing.
Wait for approval if the task is complex.
Then assign workers in the right sequence.
## Step 4 — Monitor
After each worker reports completion:
- Verify the output matches the assignment
- Check for any blockers or missing pieces
- Flag conflicts before moving to dependent workers
## Step 5 — Synthesize
When all workers complete:
- Combine outputs into a coherent summary
- List everything that was produced
- Flag anything that needs human review
- Report total: files created, tests written, docs updated
## Workers Available
- api-agent: API routes and TypeScript types
- frontend-agent: UI components and pages
- test-agent: tests for completed code
- docs-agent: documentation updates
- security-reviewer: security-only review, read-only
- performance-reviewer: performance-only review, read-only
## Rules
- Never write application code yourself
- Never skip the planning step
- Always verify worker output before proceeding
- If a worker reports a blocker — stop and report to human
Do not try to resolve it yourself
Notice the tools:
Read, Bash, Glob, Grep
No Write. No Edit.
Can't write code. Can only coordinate.
Step 2: The Orchestration Prompt
claude
Use the orchestrator agent to manage this task:
Task: [describe the full task]
Workers available:
- api-agent
- frontend-agent
- test-agent
- docs-agent
Expected output: [what done looks like]
Constraints:
- api-agent must complete before frontend-agent starts
- test-agent runs after both api and frontend complete
- docs-agent runs last
Orchestrator: present your assignment plan
before executing anything.
The orchestrator plans before executing.
Not the other way around.
Step 3: Review the Plan Before Execution
The orchestrator presents:
Worker 1: api-agent
Assignment: build POST /api/[feature] and types
Input: feature spec from issue #65
Output: route file + TypeScript interfaces
Depends on: nothing — runs first
Worker 2: frontend-agent
Assignment: build /app/[feature]/page.tsx
Input: TypeScript interfaces from api-agent
Output: page component with all states
Depends on: api-agent completion
Worker 3: test-agent
Assignment: tests for all new files
Input: completed files from workers 1 + 2
Output: test suite, all passing
Depends on: both workers complete
Ready to execute? (y/n)
You review.
You approve.
Then execution starts.
Yes — proceed with the plan.
30 seconds of review.
Saves 30 minutes of fixing wrong assumptions.
Step 4: Monitor With Checkpoints
After each worker reports completion:
Orchestrator: verify api-agent output.
Did it produce all required files?
Are the TypeScript interfaces exported correctly?
Any issues before we proceed to frontend-agent?
If all good:
Orchestrator: proceed to frontend-agent.
If there's an issue:
Orchestrator: api-agent is missing the TypeScript
interface for InvitationStatus.
Re-assign: api-agent to add InvitationStatus to
/types/invitation.ts before we continue.
Verify before proceeding.
Catch issues early.
The Reviewer Pattern (Add Quality Gates)
After all workers complete:
After all workers complete their assignments,
use security-reviewer to check all new files
before we consider this done.
If security-reviewer finds Critical issues:
- Orchestrator assigns fixes back to the relevant worker
- Worker fixes and reports back
- Security-reviewer re-checks the fixed files
Only mark complete when security-reviewer is clean.
Quality gate at the end.
Nothing ships without review.
Complete Real Example (Team Billing Dashboard)
Full orchestrator + worker session from task to shipped.
Kick Off the Orchestrator
cd ~/projects/my-app
claude
Use the orchestrator agent to coordinate
building the team billing dashboard.
Full task: a page at /app/billing/team where
team admins can see all seats, usage this month,
and manage subscription.
Workers: api-agent, frontend-agent, test-agent
Stripe is already configured in /lib/stripe.ts
Supabase is configured in /lib/supabase.ts
Present your assignment plan before executing.
Orchestrator Presents Plan
Worker 1: api-agent
- GET /app/api/billing/team/route.ts
(fetch team seats + usage from Stripe + Supabase)
- /types/billing.ts
(TeamBilling, Seat, UsageData interfaces)
Runs: first — no dependencies
Worker 2: frontend-agent
- /app/billing/team/page.tsx
- /components/billing/TeamBillingDashboard.tsx
- /components/billing/SeatList.tsx
- /components/billing/UsageMeter.tsx
Needs: /types/billing.ts from api-agent
Runs: after api-agent completes
Worker 3: test-agent
- Tests for all new files
Needs: all completed files from workers 1 + 2
Runs: last
Approve?
Review the plan.
Looks good.
Approved. Execute.
Worker 1: api-agent Runs
api-agent completes and reports:
Created: /types/billing.ts (3 interfaces)
Created: /app/api/billing/team/route.ts
Orchestrator Verifies
Types exported: TeamBilling ✓ Seat ✓ UsageData ✓
Route: validated, error-handled ✓
Proceeding to frontend-agent
Verification passed. Next worker.
Worker 2: frontend-agent Runs
frontend-agent completes and reports:
Read: /types/billing.ts ✓
Created: 4 files, all states covered
Orchestrator Verifies
Loading states ✓ Error states ✓ Empty states ✓
Proceeding to test-agent
Verification passed. Next worker.
Worker 3: test-agent Runs
test-agent completes and reports:
18 tests written, all passing ✓
All workers complete.
Now the quality gate.
Security Review Gate
Run security-reviewer on all new files before
marking complete.
security-reviewer checks and reports:
Clean — no findings
Quality gate passed.
Orchestrator Synthesizes
Files created: 7
Tests written: 18, all passing
Security review: clean
Feature complete
Close the Loop
/capture
Close GitHub issue via MCP
/ship
Done.
Seven files. Eighteen tests. Security reviewed.
All coordinated by one orchestrator.
Clean.
What I Learned (The Hard Way)
The "Never Do Specialist Work" Rule
My instinct was to let the orchestrator jump in and fix small things itself.
Rather than re-assigning to a worker.
"It's just a small fix. Why assign a worker?"
Every time I did that, the orchestration fell apart.
Because the orchestrator lost track of the overall picture.
Strict separation is what makes it reliable.
The "Present Your Plan Before Executing" Step
This is non-negotiable for complex tasks.
Reviewing the assignment plan before anything runs has caught wrong assumptions three times already.
30 seconds of review.
Saves 30 minutes of rework.
The Security Reviewer Gate
Worth adding to every orchestrated workflow by default.
Not as an afterthought.
As a standard final step.
Nothing ships without review.
Even if it's just "clean — no findings."
Why This Matters
The orchestrator and worker pattern is reliable because it's simple.
One agent coordinates.
Others execute.
Nobody crosses into someone else's scope.
The orchestrator never loses sight of the full task because it never gets pulled into implementation details.
The workers never lose focus because they each own exactly one piece.
This is the pattern worth learning deeply.
It scales from a three-worker feature build to a ten-worker project refactor.
Without changing the fundamental structure.
My Raw Notes (Unfiltered)
The "never do specialist work" rule for the orchestrator is the one that took me longest to trust.
My instinct was to let the orchestrator jump in and fix small things itself rather than re-assigning to a worker.
Every time I did that the orchestration fell apart because the orchestrator lost track of the overall picture.
Strict separation is what makes it reliable.
The "present your plan before executing" step is non-negotiable for complex tasks.
Reviewing the assignment plan before anything runs has caught wrong assumptions three times already.
The security reviewer gate at the end is worth adding to every orchestrated workflow by default.
Not optional. Standard.
Phase 5 Building Momentum
Day 40: Designing from scratch (principles + architecture)
Day 41: Orchestrator + Worker pattern (most reliable architecture) ← You are here
Day 42 preview: Multi-agent for real projects (full workflow, actual feature, start to shipped)
From theory to implementation.
From principles to patterns.
Next: real production use.
Following This Series
Core 30 Days: ✅ Complete
Bonus Days: In progress
Phase 1 (Days 1-7): Foundations ✅ Complete
Phase 2 (Days 8-21): Getting Productive ✅ Complete
Phase 3 (Days 22-35): Power User ✅ Complete
Phase 4 (Days 36-39): Build In Public ✅ Complete
Phase 5 (Days 40+): Multi-Agent Systems ⬅️ Building the patterns
G
P.S. - The orchestrator never writes code. The workers never coordinate. When an agent tries to do both, it does both worse. Strict separation is what makes it reliable.
P.P.S. - Present the plan before executing. 30 seconds of review saves 30 minutes of fixing wrong assumptions. This step has caught errors three times for me. Non-negotiable.
P.P.P.S. - Add security-reviewer gate to every orchestrated workflow by default. Not optional. Standard final step. Nothing ships without review, even if result is "clean — no findings."