Reference

The Figures

The diagrams behind the write-up, gathered in one place.

FIGURE 1

System architecture: human, orchestrator, two worker accounts with subagents, and shared services HUMAN (phone: approve / deny) single control point ORCHESTRATOR (one session, small container) ACCOUNT A WORKER 1 WORKER 2 H S O F S O F H subagents, tier per rubric: H Haiku 4.5, S Sonnet 5, O Opus 4.8, F Fable 5 ACCOUNT B WORKER 1 WORKER 2 O F S H H S O F SHARED SERVICES (available to orchestrator + all workers) RAG INDEX STATUS LOG APPROVAL GATE WATCHERS
Figure 1. One orchestrator directs two worker accounts, each fanning out to tier-routed subagents, with shared services on the side and a single human approval point at the top.

One orchestrator sits at the top of the tree and never touches the work itself. It hands tasks down to two separate worker accounts, and each worker fans out to subagents on four model tiers, marked H, S, O, and F from cheapest to priciest. A shared rail on the right holds the services every layer draws on: the lookup index, the shared log, the approval gate, and the watchers that keep sessions alive. The only human touchpoint sits at the very top, a phone with two buttons.

FIGURE 2

The delegate loop: brief, dispatch, work, milestone, independent verify, then pass or fail BRIEF DISPATCH right-sized model WORK MILESTONE appended to log verifier is never the builder VERIFY pass DONE fail: findings back to worker
Figure 2. Each unit of work moves through dispatch, execution, and a logged milestone, then an independent verifier passes it to done or sends it back with findings.

This is the path one piece of work takes from start to finish. It gets briefed, dispatched to whichever model tier fits, worked, and logged as a milestone. Then a separate verifier checks it, and only a pass moves it to done. A failure sends findings straight back to the work stage, drawn as a dashed loop, so the fix happens where the work happens rather than depending on the builder to remember what it meant to do.

FIGURE 3

Routing decision tree from a new subtask to a model tier NEW SUBTASK MECHANICAL? yes HAIKU 4.5 no top-tier on a two-command chore no BOUNDED CHORE? yes SONNET 5 no NEEDS JUDGMENT? yes OPUS 4.8 no MULTI-HOUR BUILD? yes FABLE 5 no bottom-tier on an architecture call
Figure 3. A new subtask falls through mechanical, bounded, judgment, and build questions until it lands on the cheapest model that clears the bar.

A new task walks down four yes-or-no questions before it lands on a model. Mechanical work stops at the cheapest tier right away. Anything that needs real judgment or a multi-hour build climbs all the way to the top two tiers. The two callouts on the right state the guard rails plainly: never spend a top-tier model on a two-command chore, and never send the cheapest model at an architecture decision.

FIGURE 4

The three-layer retrieval stack: recall, navigate, record QUERY RECALL RAG over docs, infrastructure notes, project history query before reading any file miss to logged READ ONE FILE (fallback, on miss only) NAVIGATE code graph and symbol tools for live code work only RECORD memory graph and per-topic state files decisions survive the session
Figure 4. A query hits recall first and only falls through to a single file read on a miss, while navigate and record serve code work and durable state on their own tracks.

Every query hits recall first, a lookup over indexed docs and notes, and only falls through to reading one actual file when the index comes up empty. That miss gets logged so the index improves over time. Navigate and record run on separate tracks below it: one for working the live codebase, the other for writing down decisions that need to survive past the current session.

FIGURE 5

The approval gate and the session watcher, two control-flow panels APPROVAL GATE AGENT PROPOSE (CLI) PHONE PUSH APPROVE DENY BLOCKED WAIT EXIT 0, APPROVED EXIT 1, DENIED EXIT 2, TIMEOUT timeout treated as NOT approved SESSION WATCHER WORKER SESSION observed by WATCHER (DETACHED) on cap: URGENT PUSH RESUME FILE WRITTEN SAME SESSION CONTINUES AFTER RESET never restart
Figure 5. The gate blocks on a phone tap and treats a timeout as a denial, while a detached watcher resumes the same session after a usage cap instead of restarting it.

The left panel is the approval gate. An agent proposes something irreversible through a small command-line tool, that pushes a notification to a phone, and the whole session blocks until a tap comes back. A timeout counts as a denial, not a maybe. The right panel is the separate watcher sitting outside a worker session. If a usage cap hits mid-task, it pushes an urgent alert and writes a resume file so the same session can pick back up after the reset instead of starting over.

FIGURE 6

Overnight swimlane of real session timestamps across two accounts, July 10 to 11, 2026 22:00 23:00 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 ACCT A ACCT B COURSE SITE 22:02-22:34 USAGE DASHBOARD 00:22-01:04 COMPLIANCE PAGES 04:13-04:18 RESEARCH PLAN 04:42-05:05 BUDGET UPGRADE 22:03-22:33 FRAMEWORK EVAL 00:27-00:49 UI FEATURE 01:57-07:28, verified 07:28 proposal timed out, human asleep approved 07:19 active work blocked, waiting on approval human approved
Figure 6. Real timestamps from the shared status log show two accounts running work in parallel through the night, with the one overnight approval gate visible as a stalled bar that resolves at the morning tap.

This is a real slice of the shared status log, laid out on a clock running from ten at night to half past seven the next morning. Solid bars are active work, dashed red bars are stretches where a job sat blocked waiting on approval, and the green dot marks the moment a phone tap released it. The UI feature bar runs the back half of the night, stalls twice waiting on approval, and only finishes after the morning tap. The gate held while its owner slept.

FIGURE 7

Results panel: projects shipped by category, peak concurrency, and the campaign window PROJECTS BY CATEGORY CLIENT / REVENUE 4 INFRA / OPS 5 FAMILY ASSISTANT 2 PERSONAL ADMIN 2 plus 3 more shipped overnight into July 11, two more in flight PEAK CONCURRENCY 18 LIVE SESSIONS AT ONCE ACCT A 8 ACCT B 10 CAMPAIGN WINDOW 4 DAYS JUL 8-11, 2026 8 9 10 11
Figure 7. Thirteen projects at the mid-run record, with three more finished overnight, spanned client, infrastructure, family, and personal work; concurrency peaked at eighteen live sessions across the four-day window.

Three panels summarize the run. The left one counts shipped projects by category, weighted toward infrastructure and operations work. The middle one shows peak concurrency split across the two accounts, eighteen live sessions running at once between them. The right one marks the calendar window the whole campaign ran in, four days start to finish.