What It Does

Uses one AI tool as the orchestrator and a different AI tool as the engineering team. The orchestrator plans, spawns parallel workers, waits for results, judges quality, and integrates outputs. Workers just code.

The Pattern

The architecture is deliberately asymmetric. The orchestrator has full context about the project, the plan, and the relationships between tasks. Workers get narrow, self-contained prompts with explicit file scopes.

Orchestrator (planning + integration)
  ├── Worker 1 (file scope A)  ─┐
  ├── Worker 2 (file scope B)  ─┤ parallel
  ├── Worker 3 (file scope C)  ─┘
  ├── [integration step]
  └── Judge (read-only verify)

Spawning workers uses background processes. Each worker gets a command like codex exec -C /repo -o /tmp/worker1-output.md "prompt" and runs independently. The orchestrator launches all independent workers in a single step.

Waiting is parallel too. You wait for all workers simultaneously, not sequentially. Each worker writes its final status to an output file. The orchestrator checks those files for completion markers.

The worker prompt template enforces discipline:

1. State the file scope explicitly ("Your ONLY files are: X, Y, Z")
2. Require the worker to prove it's in the right repo (run pwd and git rev-parse)
3. Include all schemas, types, and constraints inline (workers have zero conversation context)
4. Define verification commands the worker must run
5. Require a completion marker: FINAL: DONE or FINAL: BLOCKED

Integration is the one step where the orchestrator writes code. When workers produce outputs that need to be combined (like one worker creates an API and another creates the frontend that calls it), the orchestrator merges the interfaces.

The judge is a separate read-only agent that reviews all changes. It runs verification commands, checks for regressions, and returns PASS / FIX REQUIRED / BLOCKED. Max 2 fix iterations before escalating.

Key Decisions

Workers must be self-contained. They share zero context with the orchestrator. This means prompts are verbose, but it prevents subtle bugs from context leakage. Every schema, every path, every constraint goes in the prompt.

File scopes prevent conflicts. Workers never touch the same files. If two tasks need the same file, they go to the same worker or get sequenced. This eliminates merge conflicts between workers.

Topology scales with task size. One worker for tiny tasks (3 files or fewer). 2-3 parallel workers for small tasks. A planner step before 4-5 workers for medium tasks. 3-4 parallel workers is the practical sweet spot.

The placeholder pattern handles cross-worker data dependencies. Worker A embeds a placeholder value where Worker B's output will go. The orchestrator replaces placeholders after both workers finish. This allows parallel execution even when outputs are interdependent.

When to Use It

• Tasks that naturally decompose into independent file scopes
• Work that benefits from parallel execution (speed matters)
• Situations where different AI tools have different strengths (one plans better, one codes better)
• Projects large enough to justify the orchestration overhead (more than ~3 files)