The Conductor Read Every Score
💥 The problem: Orchestra’s orchestrator was reading ~90KB of phase scripts into its own working memory — instructions meant for workers
🔧 The fix: Pass scripts by file path in worker briefs instead of reading them into the orchestrator
✅ The result: 62% less script context consumed, 96% less growth per loop iteration
17 scripts totalling 141KB — 11 worker scripts handed off by reference, 6 orchestrator scripts retained.
Result: orchestrator context drops from 145KB to 55KB (−62%).
The Bug Nobody Noticed
Yesterday we shipped spawn enforcement — rules that stop the orchestrator from faking fresh-spawn workers with in-session agents. The orchestrator was finally spawning real terminal processes.
But it was still filling up its own working memory (called the “context window”) too fast. Why?
Core insight: Think of it like an orchestra conductor who memorises every musician’s sheet music before the concert. The conductor doesn’t need to know how to play the oboe part — they just need to hand the oboe player their score and listen to the result.
That’s exactly what was happening. The execution sequence said “Read scripts/phase-2-build.md and execute” for every phase. The orchestrator dutifully read each script into its own memory — even when it immediately delegated the work to a fresh worker.
The Numbers
Orchestra has 17 script files totalling 141KB. The orchestrator was reading almost all of them.
Here are the biggest offenders — phase scripts that only workers need:
| Script | Size | Purpose |
|---|---|---|
| phase-2-build.md | 14.9 KB | Full build instructions |
| phase-7-visual-audit.md | 13.5 KB | Screenshot capture & analysis |
| scoring.md | 12.1 KB | Rubric and scoring rules |
| delivery.md | 12.1 KB | Pre-delivery gate & report |
| phase-1c-deep-research.md | 10.0 KB | Web research protocol |
| phase-6-verify.md | 7.5 KB | End-to-end verification |
| phase-3-test.md | 7.0 KB | Testing protocol |
| loop-mechanics.md | 6.7 KB | Fix loop rules |
| phase-4-harden.md | 6.2 KB | Security & performance |
| phase-1b-recon-plan.md | 5.1 KB | Recon & planning |
The orchestrator was consuming ~145KB of script content across a single run. In a 3-loop run, that ballooned to over 300KB — because it re-read scripts on every loop iteration too.
The Fix
Split the scripts into two categories: orchestrator scripts (the ones it actually needs to make decisions) and worker scripts (the ones it should pass by reference).
Before: the orchestrator loaded 15KB of build instructions it never used. After: it writes a 200-byte brief and reads a 1KB result.
What the Orchestrator Actually Needs
Only the scripts that help it make orchestration decisions:
Routing Scripts
context-gate.md, orchestra-protocol.md, spawn-enforcement.md — what to spawn and when.
Bookkeeping Scripts
task-tracking.md, token-tracking.md, run-reporting.md — progress and cost tracking.
Judgment Scripts
scoring.md, loop-mechanics.md — read only when scoring and looping.
Delivery Script
delivery.md — read once at the end to produce the final report.
The orchestrator now keeps only four script categories in memory:
Routing (3) · Bookkeeping (3) · Judgment (2) · Delivery (1)
Every other script — the eight worker phase scripts — is passed by file path, not loaded.
Everything else — the phase scripts that tell a worker how to build, test, harden, verify, and polish — stays out of the orchestrator’s memory entirely.
Before vs After
| Metric | v0.2.1 (Before) | v0.3.0 (After) | Change |
|---|---|---|---|
| Scripts read by orchestrator | ~145 KB | ~55 KB | −62% |
| Context added per loop iteration | ~60–90 KB | ~2–4 KB | −96% |
| Total script context (3-loop run) | ~300+ KB | ~65 KB | −78% |
v0.2.1 grew 60–90KB per loop: by loop 3 the stack was ~325KB — over the compaction ceiling.
v0.3.0 grows 2–4KB per loop: by loop 3 the stack is ~64KB. Same ceiling, miles of headroom.
The single-pass saving matters, but the loop savings are where it really counts. Each loop iteration used to re-read 60–90KB of phase scripts. Now each loop adds only the result.json files from workers — a few KB total.
Why This Wasn’t Obvious
The execution sequence was inherited from one-shot-scripts, where there’s only one session doing everything. “Read the script and execute” made perfect sense there — the single session needs the instructions to do the work.
When Orchestra forked from one-shot-scripts, the execution sequence came along unchanged. Nobody questioned it because the words “read and execute” still sounded right. But in Orchestra, “execute” means “write a brief and spawn a worker” — not “do the work yourself.”
Do
Write a brief that references the script by path. The worker reads it in its own fresh memory.
Don’t
Read the script yourself, understand it, then summarise it in the brief. That’s double the memory cost for zero benefit.
The Pattern
This is the third Orchestra fix in three days. Each one caught the same class of bug: the orchestrator doing work that belongs to workers.
- v0.1.0 — Orchestra launched, but the orchestrator sometimes skipped fresh spawns entirely
- v0.2.0 — Spawn enforcement added, but the orchestrator still read every phase script
- v0.3.0 — Scripts passed by reference. The orchestrator finally conducts without playing.
The lesson: When you build a delegation system, audit what the delegator still touches. Delegation isn’t just “someone else does the work” — it’s “someone else holds the instructions too.”
Three Orchestra fixes, three days, one bug class:
v0.1.0 (skipped fresh spawns) · v0.2.0 (read every script) · v0.3.0 (this fix — pass by reference)
Every prism opens to the same label: orchestrator doing work that belongs to workers.
What This Unlocks
With 90KB freed from the orchestrator’s working memory, it can run longer before hitting compaction (the point where old messages get compressed to make room). That means more loop iterations, more workers, and bigger builds before quality degrades.
The orchestrator’s context now grows almost entirely from result.json files — structured data averaging 1–2KB each. A 10-worker run adds roughly 15KB. That’s the budget a single phase script used to consume.
Run Orchestra on Your Next Build
Fresh workers, lean orchestrator, parallel execution. One prompt in, finished product out.
Get Godmode How Orchestra Works