The Promise
Run a fleet of AI workers on your real business without becoming the middle manager of a robot army — one Coach takes the mission, dispatches the workers, and hands you a single page at the end of the day.
The One-Sentence Setup
Most operators try to scale themselves with AI by opening more chat tabs — the right move is the opposite: open fewer chats, but put one of them in charge of the rest.
The Core Insight
The second mistake every operator makes (the first being no Memory) is talking to AI as a peer. Peer-mode means the operator is the manager of every thread — context-switching between twelve tabs, repeating themselves, re-deciding the same calls. The Orchestrator pattern inverts that. One AI agent — the Coach — owns the mission. The Coach decomposes the work, spawns specialized sub-agents, supervises them, coaches them through their own blockers, and bubbles up only the handful of items that genuinely need a human. The operator talks to the Coach. The Coach talks to the fleet. The fleet talks to memory. That is the entire system, and it is the difference between "I have twelve AI tabs open" and "I have one Coach and a debrief at 6pm."
The Mechanism
1. Name the five roles before spawning anything
What: Decide who plays what part before opening a single agent. How: Five roles, no more. (a) The Operator — you. Hands the Coach a mission and reads the debrief. (b) The Coach — the orchestrator. Scopes, decomposes, dispatches, supervises, debriefs. (c) The Sub-Agent Fleet — specialists with names like Market Mapper, Lead Hunter, Content Engine, Outreach Operator, Pipeline Analyst. (d) The Scribe — a continuous background sub-agent that mirrors every output to memory. (e) The Approval Inbox — a queue (Notion DB, Slack channel) where the Coach posts the few items that need a human decision. Miss this and: the operator becomes the orchestrator by default, which is the exact role this pattern was built to delete.
2. Write the Coach's charter as a system prompt
What: A single markdown document — CLAUDE.md at the project root or the system prompt of a long-running Claude Project — that fully defines the Coach.
How: Five sections: Role (who the Coach is, what philosophy they reason by), Operating Loop (Scope → Plan → Dispatch → Supervise → Debrief), The Fleet (named sub-agent roles available to spawn), Guardrails (the only escalations allowed), and Output Cadence (where status lands and how often). Two pages is the upper limit. The charter is the Coach's character sheet.
Miss this and: the Coach drifts back into peer-mode, asks the operator twenty questions a day, and the pattern collapses into the chat-tab problem it was supposed to solve.
3. Define the Guardrails — and keep the list short
What: The handful of categories that bubble up to the operator. Everything else, the Coach handles. How: Floor of four. (a) Spending money — Coach builds the cart, operator places the final click. (b) First send of any new outbound sequence in the operator's name — drafted and queued by the fleet, approved once, then the sequence runs. (c) Private-info firewall — equity, HR, family, sensitive named individuals never touch shared systems. (d) Destructive or irreversible actions — deleting accounts, prod deploys, wire transfers. Everything else runs at full speed. Miss this and: every ambiguous case becomes a new Guardrail, the list bloats, and the operator is back in the loop on every decision.
4. Stand up the Approval Inbox
What: A single durable queue where the Coach posts Guardrail items, daily debriefs, and one-tap approvals. How: A Notion database with five columns — From / Type / Status / Urgency / Subject — is the cleanest version. Slack channel works. Email does not — too noisy. The Coach writes here. The operator opens it once or twice a day, taps approve/reject, and closes the laptop. Phone-friendly is the bar; if the operator can't approve from a walk, the inbox is in the wrong place. Miss this and: the Coach pings across three channels and the control point becomes another notification stream.
5. Cap the active fleet at five
What: Never more than five active sub-agents at once. Queue the rest.
How: When the Coach wants to spawn a sixth, it must either retire one or refuse the dispatch. The Coach should be ruthless about this — agents spawned to look busy dilute the agents working the actual constraint. The current binding constraint determines which five are live. When the constraint moves, the fleet roster turns over. Keep the active list in FLEET_STATUS.md and update it every cycle.
Miss this and: the operator ends up with twelve sub-agents producing twelve mediocre artifacts that no human will ever read.
6. Run a single daily debrief
What: One file per day. DAILY_DEBRIEF_YYYY-MM-DD.md. The operator's one mandatory read.
How: Three sections. What shipped today (concrete artifacts, not activity). The current constraint (named, one line). The one thing (if any) that needs you (a question or an approval, never both). One page. Anything longer than a page is the Coach failing to do its job. The debrief lands at a fixed time — 6pm works for most operators — so the loop is predictable.
Miss this and: the operator either checks the system constantly or doesn't check it at all. Both kill the pattern.
The Pitfalls
The Middle-Manager Trap. The operator supervises the Coach instead of letting the Coach supervise the fleet. Fix: hide the sub-agent channels from the operator entirely — the only signals that reach them are the daily debrief and the Approval Inbox.
The Guardrail Creep. Every awkward case becomes a new Guardrail until the list is forty items long. Fix: Guardrails are for irreversible actions only. If the Coach can fix it by trying again, it is not a Guardrail.
The Fleet Bloat. Spinning up sub-agents to look busy. Fix: every new sub-agent has to name the constraint it serves. If it doesn't move the binding constraint, it doesn't spawn.
The Lost-Context Trap. Sub-agents work in isolation and their outputs never compound. Fix: the Scribe runs continuously and mirrors every artifact to the Memory Architecture. Un-logged work is work that didn't happen.
The No-Definition-of-Done Trap. Sub-agents loop forever, draft after draft. Fix: every charter contains an explicit definition of done — a named file at a named path with a named acceptance bar. When the file exists and clears the bar, the agent retires.
The Drill (this week)
Thirty minutes, one mission. Pick a real mission you actually have this week — not a hypothetical. Open MISSION_PLAN.md. Write the goal in one sentence. Name the binding constraint in one line. List three Guardrails (use the floor above). Pick the ONE sub-agent you'd dispatch first — give it a name, a one-paragraph charter, and a definition of done as a named output file. Now open Claude Projects, paste the Coach charter into the system prompt, drop in the mission plan, and say: "Spawn the first sub-agent and report back only when the definition of done is met or a Guardrail is tripped." If the next thing you see is a finished artifact, the pattern works. If it's a list of questions, the charter is too soft — tighten the autonomy clause and re-run.
The Tools
| Layer | Primary | Alternates |
|---|---|---|
| Coach runtime | Claude Code with --dangerously-skip-permissions for autonomy | Claude Project (web), Cursor agent mode |
| Sub-agent spawning | Claude Code Task agents / sub-agents | Anthropic Claude Agent SDK for programmatic fleets |
| Coach model | Claude Opus 4.7 (1M context) for long-running orchestration | Claude Sonnet 4.6 for shorter cycles |
| Approval Inbox | Notion DB with From/Type/Status/Urgency/Subject columns | Slack channel, Linear inbox, dedicated Gmail label |
| Scribe target | Obsidian vault (see The Operator Vault) | Plain markdown folder, Notion wiki |
| File conventions | MISSION_PLAN.md, FLEET_STATUS.md, DAILY_DEBRIEF_<date>.md | Any consistent naming the Coach is told to honor |
The opinion: Claude Code with full autonomy is the only runtime currently mature enough to run a real fleet without constant babysitting. Browser-only chat tools still force too many context switches back to the operator.
Cross-references
This framework lives in the Reason and Act surfaces of The 4-Surface AI Stack — the Coach is the reasoning layer, the fleet is the acting layer. The Persona Cascade powers the Coach's character sheet (and each sub-agent carries its own scoped persona). The Memory Architecture is what the Scribe writes to — without Framework 05 in place first, the fleet's work doesn't compound and this pattern decays inside two weeks. The Autonomy Ladder is what your Guardrail list is — defining Guardrails is choosing which rung each action category sits on. Forward, this framework is the prerequisite for The Hand-off Brief Pattern: the discipline of writing sub-agent charters tight enough that the Coach can dispatch them and walk away.
One framework. One drill. One week at a time.
The Operator Stack is the architecture. Verala is the practice that runs it on your own communication delivery — voice, pitch, pause, presence. One foundation per week, until it's automatic.
Take the free 5-Foundation Voice Audit → · Book a 30-min intro call →