This is the full, in-depth reference for Level 4. For the short version, go back to the lesson.

Level 4 — Orchestrate (Code)

The leadership class. Verb: Orchestrate. Org-rung: Leadership. You direct a team of parallel agents against a whole system or codebase, under written rules they obey — you set policy and destination, not individual keystrokes. You don't write the work; you write the brief, the rules, and the gates, and you decide what merges. This is the top of the ladder: the same two muscles you built at Level 1 — framing an intent, verifying a result — but now applied at the scale of a team, where a wrong call doesn't cost one screen, it costs the whole system, in parallel, fast.

Before you start — three things to read once

These get used on every page below. Read them now and the rest reads cleanly.

A prerequisite note — read this first, especially if you've never opened a terminal

This is the one level on the ladder that assumes a developer's workbench: a code editor, a project of files, and version control. The hands-on parts below run inside an agent that lives in a terminal and edits a real codebase. If you've used those tools, equip away. If you haven't, you can still learn the whole class — the governance is the lesson, and the governance is tool-agnostic: a written brief, isolated workspaces, automated checks, and a human checkpoint before anything ships. Where a section shows a command or a file path, read it as "this is what it looks like in practice," not "you must type this to understand it." The mini-glossary below defines every developer term the module leans on, in plain language, before it's used.

The four-level ladder (where you are)

This module is Level 4 of 4 — the top rung. The whole ascent:

One boundary worth stating up front: the orchestration mechanics in this module — parallel subagents, a rules file the agents obey, gated merges — are how the Code tool works. Chat, MCP-Connect, and Cowork do not run a team of agents this way; they reason, fetch, and run single delegated jobs respectively. You don't orchestrate a fleet from a chat window.

The thing that changes at this rung: at every level below, you were close enough to watch the work — in the loop on each action (L2), or on the loop step by step (L3). Here the work runs broad and in parallel, and you can no longer watch each step. You govern through what you write down and what you let through.

The three jobs (your hats)

Across the whole ladder you wear three hats. They never go away; what changes is which one is doing the heavy lifting.

At Level 4, the Navigator and Conductor hats dominate together. You own the destination and the policy (Navigator: the spec, the rules file, the definition of "good"), and you set the tempo and the gates for a team of agents (Conductor: who runs when, what holds, what ships). This is the one level where two hats share the lead — because orchestration is both where are we going and in what order, through which gates. But the Verifier hat does not retire; it gets sharper and more concentrated. You verify less often (you can't read every keystroke of a parallel team) but the stakes of each verification are highest on the ladder — so it moves to the human gate, where one read of a diff stands between wrong work and a system-wide merge. The reflex you built on cheap mistakes at Level 1 is the load-bearing prerequisite here, where the mistakes are the most expensive you can make.

Mini-glossary (plain definitions, used throughout)

The developer terms, in one place, in plain English — so you're never decoding a word mid-workflow:

• Terminal (the command line): a text window where you type commands instead of clicking buttons. The agent at this level lives here.
• IDE (code editor): the program a developer writes code in; many can host the agent in a side panel.
• Project root: the top folder of your project — the one everything else sits inside.
• File (a diff): a diff is a side-by-side list of exactly which lines an agent changed — removed lines (usually marked -) and added lines (marked +). Reading the diff is how you see what actually changed, not what the agent said it changed. It is the single object the human gate operates on.
• Commit: a saved, named bundle of changes — a checkpoint in the project's history, with a message saying what changed and why.
• Branch: a private copy of the project where work can happen without touching the live version. The live version is usually called main. Work on a branch, review it, then merge it.
• Merge: to fold a branch's changes into the live main version — the moment work actually "ships" into the system. This is the act you govern at this level: you approve merges, not keystrokes.
• CI (continuous integration): an automated service on your code host that runs your checks (tests, etc.) on every branch and can block a merge if they fail. CI is a host feature, not a Claude feature — but it's a core enforcement lever here.
• Tests / lint / typecheck: automated checks that pass or fail on their own. Tests confirm the code does what it should; a linter flags style/quality problems; a typecheck catches whole categories of mistakes before the code runs.
• The rules file (AGENTS.md / CLAUDE.md): a plain-text file you place in a folder that every agent entering that folder reads first. It's the folder's standing brief — who the project is, how to work in it, its voice, the steps, the commands, and the hard "always / never" rules. It's how you stay on the loop without being in it: agents you never watch still obey what it says. (You write it in any text editor and save it in the folder; the agent reads it automatically when it starts work there. AGENTS.md is the emerging cross-tool name; Claude Code reads CLAUDE.md natively — check which your tool honors, and pick one name per project to avoid confusion.)
• Subagent: a separate agent the lead spawns to handle one slice of the job, running in its own separate context (its own clean working memory) with the tools you've allowed it. You brief one lead — the GM (general manager): the single coordinating agent you talk to — and it spawns a subagent per room and reports back. You don't talk to every specialist. (Why separate context matters: it keeps each agent sharp and stops one room's noise polluting another's reasoning — but it also means nothing automatically travels between agents; anything shared has to be made a committed artifact, see the "context fragmentation" pitfall.)
• Room (folder-as-department): a folder scoped to one kind of work, with its own rules file. design/, data/, and web/ are three rooms; an agent that enters data/ reads data/'s brief and works only there. Rooms are how parallel agents stay out of each other's way.
• Skill: a reusable, packaged capability or standard (e.g. a brand-styles skill) an agent can pick up and apply — and that can travel between rooms, so the look defined in design/ lands consistently in web/.
• The human gate: the review checkpoint where work stops and waits for you before it merges. Automated checks run first; the human gate is the last, human "yes." It's the single point where the Verifier hat does its work at this level.
• Blast radius: how much a single mistake can touch. It grew at every level; at Orchestrate it's the whole system, multiplied by however many agents ran the bad instruction in parallel. This is the term that justifies the rules and the gates.
• Parallel / in parallel: several agents working at the same time, each in its own room, rather than one after another. It's the level's speed and its danger — the same bad instruction reaches everywhere at once.

Availability note: the capabilities named here (an agent CLI in a terminal, an IDE integration, an AGENTS.md/CLAUDE.md rules file, subagents, custom commands and skills, gated commits and reviews) vary by plan, tool, version, and account, and by how your repository and environment are set up. Names, install methods, and exact file paths for agent tooling move quickly — where this module shows one, treat it as current convention at time of writing, not a guarantee. Where a specific feature isn't present or is named differently in your setup, the principle still holds — written rules, isolated rooms, automated checks, a human gate — even if the button, command, or filename differs.

0. Class Card — at a glance

In ten seconds: Orchestrate is the broadest, fastest, highest-leverage way to point Claude at real work — and the highest-stakes. You trade away the ability to watch each step (you're out of the loop on keystrokes) and in exchange you gain reach over an entire system worked in parallel — but only if you stay on the loop through the three things that replace watching: the brief, the rules file, and the gate you choose to merge through. That trade is exactly why this level leads with rules and gates: at every rung below, a wrong answer was words, then one action, then one unattended job. Here it's wrong work at scale, in parallel, fast — so the governing you do before and at the gate is the whole class.

The running scenario, set once (threaded through Sections 5 and 10): You direct a team to "Build a customer-feedback dashboard from our survey data." A lead — the GM — breaks it into specialist subagents: a Researcher to read the 1,204 survey responses, an Architect to design the layout, a Builder to write the code, a Reviewer to test quality. Each works in parallel in its own room — design/, data/, web/ — reading that room's rules file; a brand skill and the live data travel between departments. Automated checks run, then the work waits at your gate. Nothing merges until you say so. That single job is what every later section makes concrete.

1. What This Level Is — and the Thinking Behind It

The class in one line: Orchestrate is directing a team of parallel agents against a whole system, under written rules they obey — you set the destination and the policy, not the keystrokes.

The plain definition

You stop typing the work and start writing the law the work runs under. You hand a coding agent a project and a brief; a lead agent — the GM — breaks the brief into specialists, each working in parallel in its own room, each reading the rules you wrote, each reporting back. Picture the survey dashboard: you don't open a chart library and start coding. You write one sentence — "a dashboard that answers why customers leave, from our 1,204 responses, on-brand, tested, reviewed by me before it merges" — write the rules each room obeys, hand it to one lead, and watch finished, checked work arrive at a gate where you decide what ships. That is the whole mechanic. The class is built on one move: Orchestrate.

It feels like running a department instead of doing a task. The class is powerful. Playing it safely is the entire discipline.

The thinking that makes it work

Three practices separate someone governing a fleet from someone who just spawned four agents and hoped.

• The rules are the work. At Chat the answer was only as good as the frame; here the system is only as good as the brief and the rules file, because those are the only places you're present. A vague spec handed to four parallel agents doesn't get you one mediocre answer — it gets you four divergent systems built fast. You author the destination and the non-negotiables first, in writing, because written policy is the only thing that governs work you can't watch. (How to do it deliberately: Section 4 — Preparation and Section 5, Steps 1–2.)

• Instructions are not enforcement. This is the confusion that sinks the level. A rules file, a room brief, a skill — these shape behavior; they do not force it. A capable agent usually obeys them and under a long, ambiguous task can drift. Only automated checks and the human gate pass/fail and block. So every load-bearing policy gets both: the rule, written down — and a check or a gate that enforces it. You stay on the loop through the instructions; you stay safe through the enforcement. (The full reconciliation: Section 3.)

• Reach is the currency you spend — and here you spend the most. The thesis of the whole Ascent: the more you let Claude reach, the more you can hand over. Here you let a team reach an entire system, in parallel, so you hand over the execution itself — and accept the largest blast radius on the ladder in exchange. That trade only pays off if the Verifier hat is strongest exactly where the reach is widest: at the gate. (The procedure: Section 8.)

The boundary of the class — stated precisely (and used identically everywhere below)

Be exact here, because a loose version of this boundary is what gets wrong work merged at scale. The precise statement is:

At Orchestrate level work runs broad and in parallel; you are OUT of the loop on individual steps and ON the loop through written rules, automated checks, and review gates. You govern via the brief, the rules file, and what you choose to merge.

That is the line. Note what it does not say: it does not say "you're hands-off" (you write every rule and read every merge) or "the agents decide" (they execute inside policy you set, and ship nothing without your gate). What it says is narrower and true: you govern the system; you don't operate it keystroke by keystroke, and nothing reaches main without passing your checks and your gate. Concretely:

These are not limitations to route around. They are the boundary of the class — and that boundary is exactly why the rules and the gates carry the weight.

Why the highest class needs the cheapest reflex most

MCP, Cowork, and Code don't replace the verify-reflex — they raise its stakes. A wrong fact you'd shrug off in a chat becomes, here, a fabricated number rendered onto an executive dashboard by a builder agent, passing every test, shipping at scale unless one human reads the diff. A weak frame that wasted one answer at L1 wastes a whole parallel fleet at L4. So the promise of this level is precise:

The Ask and the Verify-reflex you built at Level 1 are not optional warm-ups here — they are the load-bearing prerequisite. Orchestration is those two muscles applied to a team, where the blast radius is largest and the gate is the only place a human still rules.

The rest of this module is how you build the rules and stand the gates that make that safe.

2. Skill-Point Allocation — the Judgment of When to Play This Class

If RPGs aren't your thing: a "class" is just a role with its own strengths; "skill points" are your limited time and attention. The lesson is to spend them where they pay off — not to reach for the most powerful-looking class every time. Orchestrate is the most powerful, which makes mis-spending it the most expensive.

Every level can technically attack almost any job. That is exactly the trap, and it's sharpest here: a coding agent fleet can build a one-page toggle, the same way a wizard can swing a sword. The skill is not "can Orchestrate do it" — it's "is standing up a team under rules the right spend for this job, or is it ceremony bolted onto something a single delegated agent would have finished faster."

Orchestrate is the broadest, fastest reach on the ladder. You pay for that reach in three currencies: setup (a spec and rules files written before anything runs), coordination (a lead, rooms, dependencies, isolation), and blast radius (a bad instruction now lands across a system, in parallel, fast). Allocate well and you've turned a system-scale job into a governed, repeatable capability. Allocate badly and you've either under-spent (hand-driving a job that wanted a fleet) or over-spent (arbitrating four agents' merge conflicts on a task one agent would have closed in an afternoon).

The master gate: the Standing-Rules Test

There is one spine to carry; everything else hangs off it. Before standing up a team — or deciding Orchestrate is even the right class — ask: is this a system-scale, parallelizable job worth standing up rules and gates for, rather than one delegated job or one connected ask? That answer sets everything downstream. Three sub-moves fall out of it:

• Is the parallelism real? Does the job genuinely split into independent parts that can run at once — or is it one sequential thread wearing a team costume? If the steps each need the last one's output, a fleet just adds coordination cost to a job that wanted one agent. No real parallelism → drop to Delegate (L3).
• Are written rules cheaper than re-briefing? Will this run more than once, or span enough rooms, that encoding the policy in a file beats re-explaining it every time? If you'd re-type the same brief on every run, the rules file pays for itself; if it's a genuine one-off in one room, the file is overhead. A rules file only earns its keep when it's reused — across rooms, across runs, or across agents.
• Can you afford the gates — and is the blast radius worth governing? Parallel reach across a live system is the largest blast radius on the ladder. If you can't stand a real gate (automated checks + your review before merge), you cannot safely play this class — the speed will outrun your ability to catch wrong work. No gate you can stand → don't dispatch; the cheapest orchestration is sometimes none.

The "rules cheaper than re-briefing" sub-move is the one people skip, so make it concrete. The rules file isn't a formality — it's a real artifact that earns its place by being reused. This is the root rules file for the running scenario, the thing four agents inherit instead of you re-explaining the project four times:

# AGENTS.md — Customer-Feedback Dashboard

## Overview
A web dashboard over our survey data. It answers ONE question: why customers leave.
Source of truth for responses: data/survey-2026.csv (1,204 rows).

## How we work
- Branch per task off `main`; never commit to `main` directly.
- One lead (the GM) dispatches specialists; specialists stay in their room.
- Report back to the lead; the lead assembles. I review the diff before any merge.

## Always / Never
- ALWAYS run `npm test` and `npm run lint` before reporting a task done.
- ALWAYS cite the row count / source for any number shown in the UI.
- NEVER edit data/survey-2026.csv (read-only source of truth).
- NEVER merge without my review. NEVER commit secrets or .env.

If you'd write that once and reuse it across the build, the next survey wave, and four agents, the file passes the test. If you'd never look at it again, you're over-spending — play Delegate.

The decision: stay at Orchestrate, drop a rung, or just do it

Run the job through the gate, then read it off this table.

Where Delegate ends and Orchestrate begins (the one boundary that matters here)

• Delegate (L3): one agent in one standing space runs a multi-step job; you're on the loop, reviewing the result. One brief, one thread, one reviewer — you. The reach is a job.
• Orchestrate (L4): a team runs in parallel across rooms under written rules, and you're out of the loop on steps, on it via the rules, the checks, and the merge gate. The reach is a system. You trade the ability to watch the work for throughput you govern by policy.

The tell that you've crossed the boundary: you find yourself wishing one agent could become many, running against your whole system at once, under standing rules — and you have a gate you can stand to catch what comes back. Until both are true, stay in the cheapest class that does the job.

A note on "level-up" — there is none

This is the top of the ladder. Every other section closes with a wish that points up a rung; this one doesn't. The skill-point lesson at the summit is not when to climb — it's when to stay put. The most common allocation error here is over-orchestrating: playing Leadership for a Delegate job because the tools are impressive. Mastery is depth — sharper specs, cleaner gates, better rules — not a next class (Section 13).

3. Equipment — the Tools You Equip at This Level

At Orchestrate level your character no longer holds a single conversation — it commands a workspace. The pieces you equip here are not things that ground an ask (that was Level 1) or grant reach to one tool (Level 2). They are the instruments of policy and tempo: the file the agents obey, the rooms they work in, the way you fan work out in parallel, the checks that run without you, and the gate where you — the only human — decide what ships. Equip these well and you can be out of the loop on every keystroke and still on the loop through the rules, the checks, and the gate. Equip them badly and you've built a machine that does the wrong thing across your whole codebase, fast.

The reframe from every level below: down there you equipped tools that change what the model can see or touch. Here you equip tools that change what a team of agents is allowed to do without you in the room. Every piece on this table is a lever on the precise boundary of the class — work runs broad and in parallel; you are out of the loop on individual steps and on the loop through written rules, automated checks, and review gates.

The loadout

Two artifacts, shown not asserted

A /review slash command — a named, reusable procedure the team runs the same way every time, so your house review standard is executed, not re-explained. In Claude Code this is a small file (e.g. .claude/commands/review.md); its body is just instructions:

# /review — house review checklist
Run before any branch goes to the human gate. Report PASS/FAIL per item.
1. Tests + lint + typecheck all green (paste the command output, don't summarize).
2. Diff touches ONLY files inside the agent's assigned room. Flag any cross-room edit.
3. Every number shown in the UI traces to a value in data/'s output — no literals.
4. No raw hex colors; brand tokens only.
5. No secrets, keys, or .env in the diff.
Do NOT fix what you find — only report it back to the lead.

And a skill — the brand-styles skill the design/ room owns and that travels into web/, so the "the skill travels between rooms" claim is backed by a file, not restated. A skill is a small folder the agent loads on demand; at its simplest:

brand-styles/                  ← the skill folder (loadable from any room)
├── SKILL.md                   ← when to use it + the rules ("tokens only, never raw hex")
└── tokens.css                 ← the actual brand colors, type, spacing as named tokens

# SKILL.md — brand-styles
Use whenever building or styling any UI. Apply tokens.css; never invent colors or type.
Every surface uses brand tokens (e.g. var(--color-text), var(--space-4)) — no raw #hex.

The design/ room defines it; the web/ room's builder loads the same skill, so the dashboard's look matches the design without anyone re-describing the palette. That is expertise travelling department to department as a committed artifact — the only way anything crosses between separately-contexted agents.

The reconciling paragraph — instructions vs. enforcement (read this; it's the confusion that sinks this level)

The pieces above split into two kinds, and conflating them is the central mistake of the class. The rules file, room briefs, commands, and skills are instructions — they shape what agents do, but they do not force it. A capable agent usually follows them; under a long or ambiguous task it can drift. Automated checks, the agent's own permission prompts, and the human gate are enforcement — they pass/fail and they block. So the rule is: never let a load-bearing policy live only as an instruction. "All money math must round to cents" in the rules file is a wish until a test asserts it. "Don't touch the auth module" is a wish until a check (or a reviewer at the gate) catches the diff that did. You stay on the loop through the instructions; you stay safe through the enforcement. Write the rule, and give it a wall.

What each piece changes about the engagement

• Terminal + IDE alone — you have an agent that acts on the real tree, asking before each real action. Powerful, and ungoverned by policy: one session, no written law. Fine for a scratch branch, thin as a default for a team.
• + Rules file (and room briefs) — the agent now starts every task knowing the project. The single biggest upgrade at this level: the difference between briefing a contractor who's read the onboarding doc and one who hasn't.
• + Parallel subagents — throughput. The job that took one agent all afternoon fans out across four working at once — and the blast radius of a bad brief fans out with it, which is why this piece is the last one you equip, after the rules and the gate exist.
• + Checks and the gate — the engagement becomes governable at scale. You stop watching steps and start owning policy and merges. This is the posture the whole class is built to reach: on the loop, in it where it counts, never out of it.

The rule of thumb: equip the rules and the gate first, the parallelism last. Standing up four agents before you've written what they obey is how you ship wrong work fast. The order is the lesson.

4. Preparation — Before You Engage

Nothing gets dispatched until this exists. At Level 1 preparation was framing one ask; here it is writing the policy a team will run under and assembling the access they'll need — the Navigator and the Conductor working before a single agent moves. The output of this section is the thing you hand to the workflow in Section 5: a written objective, a drafted rules file, the rooms scoped, and the access/checks confirmed. Skip it and parallelism just amplifies whatever you left vague. Four moves.

1. Align on the destination — what is this team actually for? Name the outcome and its definition of done, not the task title. The brief specifics live in the rules; the destination lives in one sentence you can hold the whole engagement against.

• Topic (too loose to dispatch): "Build a customer-feedback dashboard."
• Objective (dispatchable): "Ship a dashboard that answers one question — why customers leave — from our 1,204 survey responses, on-brand, tested, and reviewed by me before it merges. Done = it's behind the gate with green checks and I've read the diff."

The first would have four agents charting every metric they can find — the Navigator's classic failure. The second tells the lead what to cut. If you can't write the one-sentence destination, the job isn't ready to orchestrate — that's a finding, not a delay.

2. Run the orchestration self-discovery. A short self-interview that surfaces what the rules and the dispatch can't infer — and, critically, whether this is even an L4 job:

• Does this genuinely split into parallel, independent parts? (If it's one sequential thread, it's a Delegate/L3 job, not Orchestrate — don't stand up a team to do one agent's work.)
• What is the blast radius if an agent does the wrong thing across the whole tree — and is it reversible? (This sets how tight the gate and checks must be.)
• What are the hard "never" rules — the things no agent may do regardless of task (touch prod data, edit the auth module, commit secrets, merge without review)?
• What does "good" mean per room? (design/ good ≠ data/ good ≠ web/ good.)
• What's the smallest set of checks that would catch the failure I most fear? (This becomes the enforcement half of your policy.)

3. Write the rules — draft the brief the team will obey. This is the load-bearing artifact of L4 preparation: the rules file (CLAUDE.md/AGENTS.md) every agent reads first. In practice: this is a plain text file you write in any text editor and save in the folder's top level — the agent reads it automatically when it starts work there. Cover who the project is, how to work in it, its voice, the commands, and the non-negotiables. The running scenario's root brief is the one shown in Section 2; a nested room brief is shorter — it layers only what's local. The data/ room's rules file:

# data/ — analysis room
- Output a single tidy file the web/ room consumes: data/dist/feedback.json.
- Every aggregate carries its n — the total it was counted out of
  (e.g. {"reason":"price","count":312,"n":1204} reads as 312 out of 1,204).
- "Why customers leave" = the churn-reason field only. Ignore NPS free-text for v1.
- Read survey-2026.csv; never modify it. All transforms live in data/transform.*.

4. Assemble access and the gate — confirm enforcement exists before dispatch. Instructions without enforcement is the trap from Section 3; close it now. Confirm each line is real, not assumed:

Output of this section: a one-sentence destination, a drafted root rules file plus per-room briefs, the rooms and isolation scoped, and the checks-and-gate confirmed to actually exist. That bundle — the policy and the access a team runs under — is what Section 5 dispatches against. Until it exists, you have a wish, not an orchestration.

5. The Workflow — Step by Step, Each Step Names Its OUTPUT

At Orchestrate level the work doesn't happen in front of you — it happens in parallel, in rooms you don't sit in, by a team reading rules you wrote. So the workflow is not "how I get an answer." It is how I govern work I can't watch. Each step produces an artifact that becomes the next step's input and a piece of the audit trail you'll need when something goes wrong at scale.

The rule that makes it a workflow, not a vibe: no step without a named output. And one rule the level adds on top: the early outputs are the controls. The spec and the rules file aren't paperwork you do before the "real" work — at this level they are the steering wheel and the brakes. You are out of the loop on individual steps and on the loop through the brief, the rules file, the automated checks, and what you choose to merge. If the spec is vague or the rules are thin, you have handed a vague instruction to a team running in parallel, and you've removed yourself from the only place you could have caught it.

The running example below is one engagement carried end to end: "Build a customer-feedback dashboard from our survey data." It spans three rooms — design/, data/, web/ — with a brand skill and the live survey data travelling between departments: you → a GM/lead → a subagent per room.

Step 1 — Spec the destination → a written spec with explicit acceptance criteria

You don't type keystrokes here; you write the destination so precisely that four agents working independently can't each interpret it differently. A spec at this level is not a paragraph of intent — it is the outcome, the rooms it touches, and the acceptance criteria the automated gate in Step 5 will mechanically check. This is the single highest-weight output of the whole pipeline, so here it is as an actual artifact, not a description of one:

# SPEC — Customer-Feedback Dashboard

## Outcome
A single shippable web dashboard that turns our latest survey export
(data/survey-2026.csv, 1,204 responses) into something a non-analyst exec
can read in 60 seconds: overall sentiment, top themes, and trend over time.

## Rooms this touches
- data/   → load, clean, aggregate the 1,204 responses; expose a tidy JSON
- design/ → apply the brand skill (palette, type, spacing); no off-brand UI
- web/    → build the dashboard that renders the data/ JSON, on-brand

## Acceptance criteria (the gate checks these — Step 5)
1. Every one of the 1,204 responses is accounted for (counted, not dropped).
2. Sentiment + theme aggregation is reproducible from the raw CSV — no
   hand-entered numbers anywhere in web/.
3. UI passes the brand-skill conformance check (tokens only; no raw hex).
4. Page builds clean and loads with zero console errors.
5. Every displayed figure traces to a value in the data/ JSON (no orphans).

## Out of scope (do NOT do)
- No new survey collection. No auth. No backend/database — static build only.
- No editing the raw CSV; treat data/survey-2026.csv as read-only.

Note what the acceptance criteria buy you: criterion 1 ("all 1,204 accounted for") and criterion 5 ("every figure traces to the data") are the machine-checkable version of "don't invent the numbers" — the failure mode that, unchecked, ships wrong work at scale. You're not trusting the agents to be careful; you're defining the test that proves they were.

Step 2 — Write the rules → a committed rules file (per room)

The spec says what to build. The rules file says how to behave in this room — and unlike the spec, it persists: every agent that ever enters that room reads it first. At Orchestrate level this is your second control surface. A thin rules file is the signature failure of the level: it lets one bad assumption propagate, in parallel, through four agents at once.

You write one per room because each room has different law. Here is the highest-leverage of the three — the data/ room's brief — as a real artifact:

# AGENTS.md — data/

## What this room is
The single source of truth for survey numbers. Nothing downstream invents a
figure; web/ and design/ consume what this room produces, nothing more.

## Conventions
- survey-2026.csv is READ-ONLY. Never edit, re-save, or "clean in place."
- All aggregation lives in `aggregate.py` and is deterministic: same CSV in,
  same dashboard.json out. No notebooks, no manual steps.
- Output is `dashboard.json` with an explicit `total_responses` field.

## How we work
- Branch per task: `data/<task>`. Never commit straight to main.
- Run `python aggregate.py && python check_counts.py` before reporting back.
  check_counts.py FAILS the task if the response count != 1204.

## Forbidden
- Hardcoding any number that should come from the CSV.
- Dropping rows silently — blanks/partials get counted as a category, not deleted.

Notice the rule check_counts.py FAILS the task if the count != 1204. You have moved acceptance criterion 1 out of your head and into the room, so it fires automatically inside the agent's own loop — before the work ever reaches you. That is what "on the loop, not in it" means concretely: the rule does the watching. The design/ room's brief does the same for the brand skill ("tokens only, no raw hex"); web/'s does it for the build ("zero console errors, every figure reads from dashboard.json").

Step 3 — Dispatch the lead → a task decomposition + agent-to-room assignment

You hand the spec to one lead — the GM — not to four specialists. You brief one; it runs the specialists. The GM reads the spec and produces the decomposition; you check that decomposition before any agent starts, because it's the last cheap moment to catch a misframing. The output is concrete:

GM decomposition (you review before dispatch):

  Researcher → data/    : read survey-2026.csv, classify sentiment + themes,
                          emit dashboard.json. Obeys data/AGENTS.md.
  Architect  → design/  : define layout + apply brand skill → design tokens
                          + component spec. Obeys design/AGENTS.md.
  Builder    → web/     : build dashboard consuming dashboard.json + tokens.
                          Obeys web/AGENTS.md. Blocked on Researcher+Architect.
  Reviewer   → (cross)  : run all acceptance criteria + check reports; does
                          NOT fix — only reports pass/fail back to GM.

Dependency: Researcher & Architect run in PARALLEL; Builder waits on both;
Reviewer runs last.

Reviewing this is a Navigator move, and it's a real skill — not every decomposition is good. A rejectable one looks like: the GM put data-cleaning logic in the web/ room (violates "no data logic in web/"), or it marked Builder as parallel with Researcher when the builder genuinely needs the data schema first. The corrective is a one-line redirect to the GM — "move the aggregation into data/; web/ only renders" or "hold Builder until Researcher's dashboard.json lands" — before any agent runs. Catching a bad decomposition here costs a sentence; catching it after four agents have built on it costs the run. Approve a clean one, and the lead dispatches.

Step 4 — Agents work in parallel → per-room work products on isolated branches

Now you are out of the loop on keystrokes. Four subagents work at once, each in its room, each in its own separate context with only the tools you allowed it, each having read its room's rules file. The brand skill travels from design/ into web/ as a loaded artifact; the live survey data travels from data/ into web/ — expertise moving department to department, the only way anything crosses between separately-contexted agents. The output isn't one answer; it's a set of work products on isolated branches (so nothing touches main yet):

data/feedback-agg     → dashboard.json (total_responses: 1204), aggregate.py
design/feedback-ui    → tokens.css, component-spec.md (brand skill applied)
web/feedback-dash     → index.html + dashboard.js (renders dashboard.json)

Isolation is the safety mechanism: if the builder went off-spec, the damage is quarantined on a branch, not merged into the live system. You don't read these yet — that's the gate's job, two steps down.

Step 5 — Automated checks run → a pass/fail check report against the spec

Before a human looks at anything, the gates you defined fire. This is the verify-reflex from Level 1, now automated and run by machine at scale, because at this level you can't eyeball four parallel work-streams by hand. The report maps one-to-one onto the Step-1 acceptance criteria — that traceability is the whole point:

CHECK REPORT — feedback-dashboard
  [PASS] 1. All responses accounted for ........ 1204/1204 (check_counts.py)
  [PASS] 2. Numbers reproducible from CSV ....... aggregate.py deterministic
  [FAIL] 3. Brand-skill conformance ............. web/ uses 2 raw hex values
                                                  (#1e90ff, #ff4444) — tokens only
  [PASS] 4. Build clean, zero console errors .... build OK
  [WARN] 5. Every figure traces to data ......... "Net sentiment +38%" displayed,
                                                  but no `net_sentiment` key in
                                                  dashboard.json — orphan figure

The report did its job: it surfaced one hard FAIL (off-brand colors slipped past the design rule in web/) and one WARN that is far more dangerous — a headline figure on screen with no source in the data. That is a number that may have been invented by the builder. The machine flagged it; now a human must judge it.

Step 6 — Review at the human gate → a gate decision (a reviewed, annotated diff)

This is where you re-enter the loop — deliberately, at the gate, with the diff and the check report in front of you. You judge each change against the spec and decide its fate. You do not rubber-stamp a green report, and you absolutely do not merge on a WARN you haven't run down. Here's the gate decision as an artifact:

GATE DECISION — feedback-dashboard

  data/feedback-agg    → MERGE.    All checks pass; numbers reproduce.
  design/feedback-ui   → MERGE.    Tokens clean, brand skill applied.
  web/feedback-dash    → REDIRECT. Two fixes before this merges:
     (a) FAIL #3: replace #1e90ff/#ff4444 with brand tokens (design/AGENTS rule).
     (b) WARN #5: "+38% net sentiment" has no source. I checked dashboard.json
         by hand — the figure is NOT derivable from it. The builder invented a
         plausible headline. REJECT the figure; if we want it, data/ must
         compute and emit net_sentiment first, then web/ reads it.

  Action: send web/ back to the GM with (a)+(b). Re-run checks on return.
  Nothing merges to main until web/ is green AND the orphan figure is gone.

The "+38%" catch is the level's most important moment in miniature: a fluent, confident, invented number that would have shipped to an exec dashboard at scale if no gate had stood between the agents and main. The gate is the one place a human still rules — and the rule is the same one from Level 1, just with higher stakes: plausible is not verified.

Step 7 — Merge / ship → merged work + an updated rules file

You merge the work that passed. data/ and design/ go in; web/ goes in only after its redirect returns green. Then you do the move that compounds: you fold what you learned back into the rules, so the next engagement starts smarter than this one ended. The off-brand-hex slip and the orphan figure each become a permanent rule:

# web/AGENTS.md
+ ## Forbidden
+ - No raw hex anywhere. Brand tokens (tokens.css) ONLY — CI rejects raw #hex.
+ - Every displayed figure MUST read from dashboard.json. No computed-in-the-UI
+   headline numbers. If a figure is needed, data/ emits it; web/ only renders.

That diff is the walk-away artifact that makes you better at orchestration over time — the rules file is a living control surface, and tightening it is how you get depth at this top rung (Section 13). Ship the merged, on-brand, fully-sourced dashboard.

The pipeline in one breath: spec with acceptance criteria → committed rules file → reviewed task decomposition → parallel branch work → automated check report → gate decision → merged work + tightened rules. The first two outputs are your controls; the last one is how you sharpen them. Run it once and you'll feel why the spec and the rules carry the weight: they're the only places you're in the loop, so they're where the whole engagement is won or lost.

6. Goals → Considerations Map

Three goals recur at Orchestrate level. They're separated by what's being parallelized and how reversible the result is — which changes where you spend your governance. Match your real intent to the variant before you dispatch a team against the wrong shape of work. Each row carries one concrete heuristic for the call that bends the workflow — not just that it bends.

The tell that you've matched goal to variant: a build run ends with the seams verified, not just the parts; a refactor run ends with the full suite green and behavior provably unchanged; a standing run ends with a rules file sharper than it started — the engagement made the team permanently better at the job, not just the artifact done once.

7. Connect the Components — Patterns & Outliers

At Chat you read a conversation; here you read an engagement — many agents working in parallel rooms, each emitting commits, check runs, file diffs, and notes against the brief. The unit you track is no longer "the answer." It's the fleet: what the lead reports, what each specialist produced in design/, data/, and web/, and what the automated checks said about all of it. The shift is structural — you are out of the loop on individual steps and on the loop through written rules, automated checks, and review gates, so the only way to read the engagement as a whole is to read the signals it emits, not to watch the keystrokes.

The discipline that makes this tractable: everything an agent does leaves an artifact — a commit, a check result, a diff, a line in its room's worklog. If a unit of work produced no artifact you can inspect, you cannot review it, which means you cannot gate it, which means it doesn't merge. "It's done, trust me" is not a component you can connect.

How to track the fleet without watching every keystroke

You track three streams and reconcile them against the spec. This is the L4 equivalent of the running verified-claims list — a fleet ledger, kept per room and rolled up by the lead:

Here is the ledger for the dashboard engagement at the moment the lead reports "first pass complete" — this is the artifact; the prose is packaging:

The ledger does the connecting. The moment you lay the three streams side by side, the two failures jump out — and neither is visible from "all checks green."

Patterns — promote them into the rules

A pattern at this level is a behavior that holds across rooms and across runs. When the same convention keeps producing clean work, you don't just keep it — you lift it into the rules file so the next fleet starts already obeying it. That is the L4 capture move: a pattern that lives only in your head re-litigates itself on every run; a pattern written into the rules file is enforced for free on every agent, every room, forever.

Examples from the dashboard run worth promoting:

1. Every room stayed inside its folder except where noted. That's the boundary working. Promote it from "the convention" to an explicit, testable rule: "An agent edits only files within its assigned room; cross-room changes require a flagged hand-off."
2. The data/ room sourced every number from the real export and the queries passed validation. That's the verify-against-source habit (Section 8) producing trustworthy output. Promote the mechanism: "All numbers shown in the UI must trace to a query against the real survey export; no literal values in components."

Promotion is how the engagement compounds. Run one dashboard and you learn the rules; write them down and the second engagement inherits them — better rules, cleaner gates, sharper briefs is the only form of leveling-up at the top of the ladder.

Outliers — the concrete drift and anomaly signals for this level

An outlier is any signal that doesn't reconcile against the spec or the rules. At L4 the danger is specific: a single bad instruction or a single unflagged deviation is amplified in parallel, fast — so an outlier here is not "one wrong answer," it's the leading edge of wrong work at scale. Watch for these, by stream:

The connecting move in one line: roll the three streams into the fleet ledger, reconcile each row against the spec, promote what held into the rules and interrogate what didn't before anything reaches the merge gate — because at this level an un-interrogated outlier doesn't stay one wrong answer; it merges at scale.

8. Qualitative vs Quantitative — Results Vary by Case

The fleet emits two kinds of output, verified in opposite ways — and at this level there's a third axis that dwarfs both. A qualitative output is a judgment: the architect's decision to aggregate by week, the choice of chart type, "this layout reads cleanly." A quantitative output is a checkable fact: a number on the dashboard, a row count, a percentage, a query result. But the output that defines L4 is neither — it's an action against a real system: a migration that ran, a file that was written, a query that touched the database, a commit that landed. Verifying that is the heart of the class.

Results vary by case, and parallelism magnifies it. The same brief dispatched twice produces different code, different file layouts, different edge-case handling — model sampling and agent autonomy guarantee it. So a fleet that produced clean work yesterday is not a fleet you can trust blind today. You verify by type and by source, never by reputation of the last run.

Why "it ran" and "it sounded right" are not verification

This is the line that gets skipped, and skipping it is the signature failure of the level.

• "It ran" is not verification. A green build, a passing test suite, a successful exit — these confirm the code executed without erroring. They say nothing about whether it did the right thing. A chart that renders beautifully off mockFeedback.json (placeholder data) passes every test and is a lie. A migration that completes successfully can still have written the wrong column. Execution is a precondition for correctness, not evidence of it.
• "It sounded right" is not verification. The lead agent's summary — "all four charts read live aggregates, schema validates, ready to merge" — is fluent, confident, and is itself a claim, not a check. Asking the lead "are you sure?" produces a more confident summary, not a more correct one. Asking the fleet to attest to its own work is not verification — the attestation is generated by the same process that may have erred. The check must come from outside the agents: the diff, the real database, a query you run, the rendered page with the data path traced.

The compressed rule: verify the action against the real source, not against the agent's report of the action. The diff is the source for "what changed." The database is the source for "what's true now." The rendered page wired to a traced query is the source for "what the user will see." None of those is the agent's word.

One worked catch

Lead agent (roll-up):
  "Dashboard complete. All 4 charts read live aggregates from data/.
   Schema validation, build, and unit tests all green. Recommend merge."

Plausible, specific, and green. The wrong move is to merge — or to ask the lead "you're sure the charts are live?" (you'll get a confident yes). The right move is to verify the action against the real source, three ways:

1. Read the diff stream, not the summary. The diff lists exactly which lines changed — the - line is what was removed, the + line is what replaced it. In web/RatingChart the diff shows:

   - import { weeklyRatings } from "../data/aggregates";   // real, live data
   + import mockFeedback from "./mockFeedback.json";        // fake placeholder data
   

   In plain terms: the chart was switched from the real survey aggregates to a fake test file. The build is green because the import resolves — execution succeeded; correctness did not.

2. Query the real source yourself. The dashboard shows "Avg rating: 4.6." Run the aggregate against the actual survey export:

   Real export → AVG(rating) over 1,212 responses = 3.9
   Dashboard   → 4.6  (computed from 20 rows of mock data)
   

   The number is fabricated relative to reality — not because the agent lied, but because it computed honestly off the wrong source.

3. Trace the cross-room anomaly the reviewer missed: design/ had edited web/theme.css, so even the styling the summary called "done" had an unreviewed author.

Verdict: the engagement is not mergeable despite all-green checks and a clean summary. The catch was impossible from "it ran" or "it sounded right" — it required reading the diff and recomputing against the real export. The fix isn't only "re-point the chart": it's a new gate — a check that fails the build if any component imports fixture data — so this class of outlier can never reach the human gate silently again. That is the level correcting itself: the missed verification becomes a written rule.

9. Recommendations → Plans

The engagement has to produce something you can stand behind — not a pile of green checks, but a decision about what merges, why you trust it, and what runs next. Two moves turn the fleet's output into that walk-away artifact.

1. Assemble recommendations — tagged by trust

From the fleet ledger (Section 7) and the type-and-source verification (Section 8), write down what to do with each piece of work in plain terms, each tagged by how much you trust it. At L4 the trust tags map directly to the merge gate — they are the input to "what crosses, what waits, what's rejected":

For the dashboard engagement, the recommendations come out as:

• data/ ingest + schema + queries → Merge. Numbers traced to the real export; validation green; diff confined to data/.
• web/ chart components → Reject/redirect. One chart read mock data (Section 8 catch); send back with the exact defect and a new "no-fixture-imports" gate to satisfy.
• design/ layout + brand tokens → Merge after I confirm X. Brand skill applied correctly, but it edited web/theme.css cross-room — confirm that edit is intended and re-attributed before it crosses.
• Reviewer's review rule → Reject/redirect (the rule itself). It missed the cross-room edit; the recommendation is to widen the review rule, not to re-run the same review.

2. Line them into a plan

Sequence the recommendations into a concrete plan, and for each name what's handed to the agents vs. what you keep, plus the reusable context that makes the next engagement start ahead of this one. At Orchestrate level the hand-over is the widest on the ladder — agents do the work in parallel — but the gates and the merge decision stay yours; you govern via the brief, the rules file, and what you choose to merge.

The reusable context — capture it into the rules, not your notes. This is the L4 capture move and the whole engine of mastery at the top of the ladder. Three things from this run get written into the rules file so the next dashboard, or the next system, starts already obeying them:

# AGENTS.md — promoted from the feedback-dashboard engagement
- Agents edit only files within their assigned room. Cross-room changes
  must be flagged as an explicit hand-off and re-attributed before merge.
- Every value displayed in the UI must trace to a query against the real
  data source. No literal or fixture data in components. (CI: no-fixture-imports.)
- The reviewer agent flags ANY file changed outside an agent's room, not
  only logic deviations.

The walk-away artifact is concrete: a merge decision you can defend — what shipped, why you trusted it (verified against source, not because it ran), what was sent back with a specific defect — and a rules file three lines stronger than it was this morning. That last part is the payoff of the level: a one-off engagement turned into policy that makes every future fleet start sharper. At the top of the ladder you don't level up to a new class; you deepen this one — better rules, cleaner gates, sharper briefs.

10. Worked Examples

Three runs through the whole template. Each one is a real engagement, not a single prompt — because at Orchestrate level the unit of work is a team against a system, not one ask against one window. Example A carries the running scenario — the customer-feedback dashboard — end to end, from a blank repo to a shipped artifact, showing every gate firing. Example B is a different goal (a system-wide refactor) so you see the template flex. Example C is the smallest illegitimate orchestration, to mark the floor: below it, you should have stayed at Delegate.

The thing to watch across all three: you never touch a keystroke of the work. You write the spec, you write the rules, you read the diffs, you decide what merges. That is the whole class. You are out of the loop on the individual steps and on the loop through the brief, the rules file, the automated checks, and the merge gate.

Example A — Build a system from survey data (the running scenario, end to end)

The job, as it lands on you: "Build a customer-feedback dashboard from our survey data." One sentence. At Delegate level you'd hand that to one agent and review what came back. You don't, because it passes the Standing-Rules Test three ways: it spans three rooms (design/, data/, web/), the pieces are independent enough to run in parallel, and you'll re-run it next survey wave — it is worth standing up rules for. So you play Orchestrate.

Step 1 — Spec + rules → the brief and the governing rules. First you Navigate the destination, because the lone sentence under-specifies it. Left alone, a builder agent charts every column it finds. You decide the dashboard answers one question — why customers leave — and ships Friday. That's the spec. Then you write the rules each room obeys.

The spec (the destination, written so an agent can't drift):

# Spec — Customer-Feedback Dashboard

## The one question
Why are customers leaving? Every chart must serve that. If a chart
doesn't help answer it, it does not ship.

## Inputs
- data/responses.csv — 1,204 survey responses, Q1-2026 wave.
- design/brand-styles/ — the brand skill. All UI uses it. No new palette.

## Output
- A single static page in web/, no build step, opens in a browser.
- Sentiment over time + top 5 churn-driver themes, each drillable to verbatims.

## Done means
- Every number on screen traces to a row in responses.csv.
- Reviewer signs off on accessibility + that no chart is decorative.
- I (the human) approve the merge. Nothing ships on an agent's say-so.

The root rules file the whole team inherits (AGENTS.md) — the standing brief: who the project is, how to work in it, its voice, the commands, the gates:

# AGENTS.md — Feedback Dashboard

## Overview
A static, single-page dashboard answering one question: why customers leave.

## How we work
- Branch per agent: feat/<room>-<task>. Never commit to main.
- Small commits. Every commit message says what changed and why.
- A task is not "done" until its check passes AND a human approved the merge.

## Voice / brand
- All UI pulls from design/brand-styles (the brand skill). Do not invent styles.

## Commands
- Serve: python3 -m http.server
- Check: npm run lint && npm run test && npm run a11y

## Gates (non-negotiable)
- No agent merges its own work.
- Numbers on screen must trace to data/responses.csv — Reviewer verifies.

Each room then gets a nested rules file that narrows the root for its specialty — data/AGENTS.md says "clean before you count; flag and quarantine nulls, never silently drop"; web/AGENTS.md says "no framework, vanilla JS, one file." OUTPUT of Step 1: a spec, a root rules file, and per-room rules — the policy a team will obey while you're not watching.

Step 2 — Dispatch parallel agents → the assigned team. You don't talk to four specialists. You brief one lead — the GM — and it spawns a subagent per room, each in its own context with only the tools it needs:

You → GM: Build the dashboard per /spec.md and the AGENTS.md rules.
          Break it into specialists, run what's parallel in parallel,
          hold what depends on data until the numbers are clean.
          Report back; do not merge anything.

GM → spawns:
  Researcher  — read all 1,204 responses, extract the top churn themes.
  Architect   — design the layout that serves the one question.
  Builder     — write the page in web/, using design/brand-styles.
  Reviewer    — test quality, a11y, and that every number traces to source.

You set the tempo here as Conductor: Researcher and Architect can run at once (themes and layout are independent), but Builder holds until Researcher's themes land, and Reviewer runs last. You also sanity-check the decomposition before dispatch — if the GM had put theme-extraction in web/, you'd redirect it to data/ in one line first. OUTPUT of Step 2: four agents working in their rooms, in a dependency order you set.

Step 3 — Agents work in their rooms → branches + reported results. Each works in isolation against its room's rules and reports to the GM, not to you. The GM relays one consolidated status — "all four reported back, assembled." OUTPUT: a branch per room and a single status from the lead — not merged code.

Step 4 — Automated checks run → a pass/fail signal you didn't have to produce. Before anything reaches your eyes, the gates from the rules file fire: lint, tests, the accessibility check. This is the cheap filter — it catches the mechanical failures so your human attention is spent only on judgment. OUTPUT: a green/red check result per branch. Builder's branch comes back red — the a11y check flags unlabeled chart axes. It never reaches your review queue; the GM sends it back to Builder to fix. That is the system working: a defect caught by a gate, not by you.

Step 5 — You review at the human gate → an approve/redirect decision. Now you read. Not the keystrokes — the diff and the claims. You build the verified-claims list, the Verifier artifact from across the ladder, now pointed at agent output at scale:

That fourth row is the catch that matters — a confident, plausible, invented analytical choice that would have shipped a wrong story to the board. No automated gate caught it because it passed lint and tests; only a human reading for judgment caught it. You redirect that one branch and approve the rest.

Step 6 — Merge / ship → the shipped artifact + reusable rules. With the smoothing fixed and re-reviewed, you merge. The walk-away is concrete:

Feedback Dashboard — Shipped
- 1,193 of 1,204 responses charted (11 quarantined nulls, logged)
- Top 5 churn themes, each drillable to verbatims
- On-brand via design/brand-styles; reviewed, a11y-passed, human-approved
- Answers the one question: pricing + onboarding friction drive churn

And the second artifact — the one that pays off next quarter — is the rules. The spec and the rules files stay in the repo. Next survey wave, you change one input line (Q2-2026 wave) and re-dispatch the same team against the same rules. The orchestration is now a standing capability, not a one-off run. That is the deepest hand-over on the ladder: you handed over the doing, kept the governing.

Example B — Refactor across a whole system (template flexed to a different goal)

The job: "We're renaming the Account model to Workspace everywhere — code, tests, docs, API." The textbook Orchestrate job: broad, mechanical-but-pervasive, parallelizable by area, and catastrophic if one agent does it wrong in fifty files at once.

Spec + rules (Step 1): the spec is tight because the danger is scope, not ambiguity:

# Spec — Rename Account → Workspace

## Scope
Rename the symbol Account to Workspace across: src/, tests/, docs/, the
OpenAPI spec. Preserve all behavior. This is a rename, not a redesign.

## Hard rules
- Do NOT rename the database table or the on-the-wire API field yet
  (that's a migration, out of scope — breaking it breaks production).
- Every changed file keeps its tests green.
- One area per branch so each can be reviewed and reverted independently.

That second hard rule is the spec earning its keep — without it, the most "helpful" agent renames the DB column and takes down prod. The signature failure of this level is a single bad instruction amplified across parallel agents; the rules file is the thing standing between you and it.

Dispatch (Step 2): the GM spawns one subagent per area — src/, tests/, docs/, the API spec — in parallel, since the areas are independent. Checks (Step 4): the test suite is the gate; a branch with a red suite never reaches you. Human gate (Step 5): you spot-read the src/ diff and immediately catch the outlier — one agent, reasoning past the rule, also renamed account_id in the schema. The check didn't catch it (tests passed locally against a stale fixture). You catch it, reject that branch, ship the rest. Merge (Step 6): four clean branches merge in sequence — each small enough to revert in one step (the Section 6 refactor heuristic); the out-of-scope migration becomes a separate, deliberate job. The lesson the run teaches: parallel speed is exactly why the gate has to be a human reading for the thing the automated check structurally cannot see.

Example C — The floor (when you should NOT have orchestrated)

The job: "Add a dark-mode toggle to our single-page app." You stood up a spec, a rules file, and dispatched three agents. The CSS agent and the JS agent kept colliding on the same two files; you spent more time arbitrating their merge conflicts than the work took. The tell: there was nothing to parallelize — it's one change in one room, run once. This was a Delegate (L3) job: one agent, one standing space, you review the result. Orchestration added rules, gates, and coordination overhead to a task that had no breadth to govern. The skill-point lesson, shown by its violation: the gate isn't "can a team do this" — it's the Standing-Rules Test: is this a system-scale, parallelizable job worth standing up rules and gates for, rather than one delegated job. Here it failed all three sub-moves — no real parallelism, no reuse, no blast radius worth governing. Drop a rung.

11. Pitfalls

At every level below, a pitfall costs you one wrong answer or one wrong action. Here it costs you wrong work at scale, in parallel, fast — the most expensive failure on the ladder, because the same machinery that lets one good instruction become a finished system lets one bad instruction become a finished mess just as quickly. The fixes restore the two dominant hats: Navigator (the destination and the policy were unclear) and Conductor (the tempo, the gates, or the sequence failed). The last three rows are the ones that don't bite on a single run — they only surface across a longer engagement, which is exactly why they're the dangerous ones.

The one reflex under all of them: at this level you govern, you don't do — so a failure is almost always a missing rule or a missing gate, not a missing keystroke. When work goes wrong at scale, don't reach for the keyboard to fix the output; reach for the rules file to fix the policy that let it happen.

12. Practice + Self-Check

Reps, but the reps here are governing reps, not doing reps. Run one full orchestration — about 30–45 minutes — then grade it against the rubric. The rubric is the instructor.

Two ways to run it — pick by your setup

• Hands-on (you have an agent CLI + a code editor): run the full task below against a real repo.
• Dry-run (no developer setup — and a legitimate way to learn the governance): do every governing step on paper, and stand in for the fleet with a single chat. Write the spec and the rules file in a document. Then hand the job to one agent in a chat, telling it to role-play the lead and report back as if four specialists worked in parallel. Practice the part that's actually the skill: reading its reported claims against the source by hand, finding the one plausible-but-invented item, and writing the rule that would have caught it. You won't merge anything — but you'll have done the Navigator and Verifier work that is the class.

The starter task (do it now)

Pick a real job that genuinely spans more than one area and that you'll run more than once — a small reporting pipeline, a documented site or tool, a cross-cutting cleanup. If it fits in one room or you'll only do it once, it's a Delegate job; pick something else, or you'll be practicing Example 10C's mistake. If nothing fits, use the house scenario: build a small feedback dashboard from a CSV you have.

1. Spec + rules (10 min). Write two artifacts before you dispatch anything:
   • A spec naming the one question/outcome, the inputs, the output, and "done means."
   • A rules file (AGENTS.md/CLAUDE.md) naming how-we-work, the commands, and at least one hard gate ("no agent merges its own work").

   # Spec
   ## The one outcome: <the single thing this must achieve>
   ## Inputs: <files / data / skills the team may use>
   ## Output: <the concrete artifact and where it lives>
   ## Done means: <traceable? reviewed? human-approved?>
   

2. Dispatch (5 min). Brief one lead, not each specialist. Name what runs in parallel and what holds until a dependency lands. (Dry-run: tell a single chat to role-play the lead.)

   Build <X> per the spec and AGENTS.md. Break it into specialists.
   Run the independent parts in parallel; hold anything that needs the
   data until the data is clean. Report back. Do not merge anything.
   

3. Let the checks run (5 min). Confirm a red check stops a branch before it reaches you. If you don't have automated checks, write the one check that matters and make it the gate. (Dry-run: name the one check, and check it by hand.)
4. Review at the gate (10 min). Read the diffs and the claims, not the keystrokes. Build a verified-claims list; verify every load-bearing number against its source yourself, and find the one plausible-but-invented choice (there is usually one).
5. Merge + keep the rules (5 min). Merge only what you approved (dry-run: mark what you'd approve and why). Then save the spec and rules file so the next run inherits them. The capture at this level is the governance, not just the output.

Self-check rubric (gradable from this document alone)

Scoring. 7/7 — you orchestrated; read Section 13. 5–6 — solid; the usual miss is #6 (you trusted green) or #7 (you treated it as a one-off and threw the rules away) — re-run and force those. 4 or below — check #1 and #2 first: you almost certainly dispatched without written rules, or you slipped into the loop and reviewed keystrokes. Both collapse the level into a slow, dangerous version of Delegate. Re-run with the spec and the gate written first.

13. Level-Up / Exit Criteria — Mastery Is Depth Here, Not a Next Rung

This is the top of the ladder. There is no Level 5 to graduate into — so "leveling up" stops meaning climb and starts meaning deepen. You don't exit Orchestrate; you get better at it, and the gains are entirely in the quality of your governance: sharper specs, cleaner gates, rules that have absorbed the lessons of every run before. The mark of mastery is behavioural, not a feeling — over-trust at scale feels exactly like leadership from the inside, right up until an unreviewed merge ships wrong work to everyone.

The mastery gate — you've gone deep on Orchestrate when you consistently, unprompted:

A blunt self-test: if you handed your spec and rules file to a stranger and let them dispatch the team, would the work come back right — and would the bad branch get caught at the gate without you in the room? If yes, your governance is doing the work, not your presence. That is the depth this level rewards.

What the gate does NOT require: you haven't failed because a check missed a defect (that's why the human gate exists), or because a branch came back wrong (catching it is the job), or because you don't write the agents' code yourself (you're not supposed to — that's the hand-over). It also does not require you to be in the loop on every step; being on the loop is the design, not a shortcut.

The signal that you've gone as far as climbing takes you

One unmistakable tell — and because this is the summit, it points inward, at depth, not upward at a next class:

"My orchestration only works because I'm watching it. The moment I'm not in the room, work drifts — because the quality lives in my attention, not in my rules and gates."

That wish is the whole remaining game. Everything below Orchestrate can be automated; the only question left is your place in the loop. When you feel the pull to stand closer because the rules won't hold without you, the answer is never to climb and never to walk away — it's to make the rules and gates hold on their own. Better briefs, cleaner gates, sharper specs. The new craft isn't writing every prompt — it's engineering the loop that runs itself, and standing at the points that matter.

Where the depth goes — Orchestrate, shallow vs. deep

There is no next column. The comparison that matters now is you against your earlier self, and the new "reach" you're buying is reach you can trust to run without you:

Hand-off

There is no next rung. The summit isn't a place you arrive — it's a craft you sharpen: better rules, cleaner gates, sharper briefs. Now go run a room.

Carry the same three things you carried up every level, now pointed at a system: the framing habit (a team with a vague brief just fails faster, in parallel, against your whole codebase), the verify-reflex (it matters most here — wrong output lands at scale, fast, and only your read at the gate catches the wrong-but-passing work), and one real capture — leave every engagement with a spec and a rules file that make the next run a standing capability instead of a fresh scramble. The skill that lasts isn't doing the work. It's knowing what good looks like, and where to stand.