How I Built an Orchestrator-Worker System for Claude Code

Mohamed Aly Amin — Sat, 10 Jan 2026 16:58:05 +0000

Back in early January, I was wrestling with a problem: coordinating multiple Claude Code sessions across different repos without losing context or stepping on my own toes.

I'd been using Claude Copilot - a framework that adds persistent memory, specialized agents, and task management to Claude Code. It's a solid foundation, but I needed something it didn't have: multi-session coordination.

My solution was an orchestrator-worker pattern built on top of Claude Copilot. I pushed the first version on January 6th.

The Problem

When you're working across multiple repos (backend, frontend, admin, infra), you need:

A coordinator that tracks progress but doesn't touch code
Workers that focus on one task in isolation
Clean handoffs between sessions

Claude Copilot gave me the memory and task infrastructure. I needed to add the coordination layer.

What I Built

Orchestrator (coordinates, never executes):

Tracks status across all repos
Tells you which worker command to run
Updates sprint boards and invoices
Syncs with Notion

Workers (isolated execution):

Run in git worktrees (no branch switching conflicts)
Use git flow (feature/ branches)
Report progress via memory
Have strict start/done commands

Makefile-based - no Python dependencies, just:

make worker-new REPO=backend TASK=fix-migration

Key Design Decisions

1. Human-in-the-loop

Workers don't spawn automatically. You decide when to start one. This keeps you in control while still parallelizing work.

2. Git flow native

Every task is a feature branch, finished properly with git flow feature finish. No orphan branches, no merge chaos.

3. Strict role boundaries

The orchestrator literally cannot write code - it's prompt-enforced:

## CRITICAL: Your Role Boundaries

**You COORDINATE. You do NOT EXECUTE.**

### You do NOT:
- Write code or fix bugs (workers do this)
- Work directly in sub-repos (workers do this)
- Create feature branches for tasks (workers do this)

4. Worktree isolation

Each worker runs in a separate git worktree. No branch switching, no stash juggling, no conflicts. Workers can run truly in parallel.

The Flow

┌─────────────────┐     ┌─────────────────┐
│   ORCHESTRATOR  │     │     WORKER      │
│   (main repo)   │     │   (worktree)    │
├─────────────────┤     ├─────────────────┤
│ • Track status  │────▶│ • feature/task  │
│ • Assign tasks  │     │ • Write code    │
│ • Update Notion │◀────│ • Report done   │
│ • Never code    │     │ • Cleanup       │
└─────────────────┘     └─────────────────┘

Try It

Everything is in my fork of Claude Copilot:

🔗 github.com/skylight74/claude-copilot

Key files:

templates/Makefile.orchestrator - The orchestration commands
.claude/commands/orchestrator.md - Orchestrator behavior
.claude/commands/worker.md - Worker behavior
docs/ORCHESTRATOR-WORKER-FLOWCHART.md - Full system diagram

What's Next

Still iterating on:

Better progress reporting between workers
Automatic conflict detection across worktrees
Tighter Notion integration

Would love feedback from anyone solving similar multi-session coordination problems. What's your approach?

Built on top of Claude Copilot by Everyone Needs a Copilot

DEV Community: Mohamed Aly Amin