The Ascent / Learn

Level 4 · Orchestrate — the lesson

Orchestrate (Code)

Directing a team of parallel agents against a whole system, under written rules they obey — you set the destination, tempo, and policy, not the keystrokes.

The line You can't watch each keystroke, and a rule isn't enforced just because it's written — you govern via the brief, the rules file, the order of play, and the merge gate.

Read the full referencethe deep, complete version of this level

Play the models below — each one you try climbs a floor of your tower.

Brief one GM — a fleet runs in parallel. Press Run.

Brief Build the Q1 board dashboard from the raw data — under the rules file.
GM · lead agent — splits the job, assigns rooms, assembles running in parallel
Dataclean + aggregate the CSVlive aggregates ✓idle
Webbuild the charts — holds for Data4 charts wired ✓idle
Reviewertrace every figure to its source1 invented stat caught ✗idle
Result dashboard branch → your merge gate

A rule with no check is a wish — you read the diff before anything merges.

A rule is only as strong as its check — toggle a gate off, then run the fleet

AGENTS.md

Charts read live data, never mock files

idle

No secrets committed

idle

Every figure traces to a source

idle

Toggle a gate off and run: the ungated rule slips straight through. Written policy shapes; only a check or the human gate forces.

Do it now — 4 small steps

One step = one paste into Claude (the mobile app is perfect). Your progress saves on this device.

  1. Step 1 of 4 · Hire your GM

    You brief one lead; it runs the specialists.

    You're my General Manager. I want a one-page plan for [a small project you care about]. Break it into 3 specialist tasks — researcher, writer, reviewer — with a one-line brief each. Don't start yet.
    Open Claude ↗

    You should see: A task plan awaiting your go.

  2. Step 2 of 4 · Dispatch a specialist

    Each specialist works its own brief.

    Run the researcher's task now, as that specialist. Return only their deliverable.
    Open Claude ↗

    You should see: Focused output in that specialist's voice.

  3. Step 3 of 4 · Assemble and check

    The GM integrates — and you watch for conflicts.

    Run the remaining specialists in order, then assemble everything into the finished piece. Flag anything where one specialist contradicts another.
    Open Claude ↗

    You should see: One coherent deliverable, conflicts surfaced.

  4. Step 4 of 4 · Graduate

    On a computer, Claude Code runs these specialists in parallel for real — in rooms, guided by an AGENTS.md.

    When you're at a desk: claude.com/claude-code — the same pattern with real folders, real parallel agents, and skills you invoke as /commands.

    You should see: You, directing a department.

The ideas behind the steps — tap a takeaway to unpack it.

What this level is

Takeaway You govern the system; you don't operate it keystroke by keystroke.

You stop typing the work and start writing the law it runs under. A lead (the GM above) splits your brief into specialist subagents, each in its own room, each reading your rules.

Work runs broad and in parallel; you're OUT of the loop on steps, ON the loop through written rules, checks, and gates.

This is the Code tool — it feels like running a department, not doing a task.

The three load-bearing ideas

Takeaway Write the rule, set the order, give the rule a wall — a rule with no check is a wish.
  • The rules are the work. A vague spec to four parallel agents gets four divergent systems, fast. The rules file (AGENTS.md) is where you're present after dispatch.
  • Tempo is a governing move. Set the order of play — what runs in parallel, what holds on a dependency (data in first, builder waits, reviewer last).
  • Instructions aren't enforcement. A rule only shapes behavior; a check or the human gate forces it. Give every load-bearing rule both.

Verify the action, not the report of it

Takeaway Plausible is not verified — check the effect against the real source, never the agent's word.

Two things feel like verification and aren't. "It ran" — a green build proves code executed; a chart off mockFeedback.json passes every test and lies. "It sounded right" — the lead's "ready to merge" is a claim. Read the diff, trace the figure to its data. Classic catch: an invented "+38% net sentiment" that passes every check and ships to an exec dashboard.

Is this the right level for your task?

Before standing up a team, run the Standing-Rules Test: is this a system-scale, parallelizable job worth standing up rules and gates for?

Stay here — Orchestrate (L4): standing rules and gates pay for themselves.
Step down to Delegate (L3): a fleet adds coordination cost with no parallel payoff. Open the Delegate lesson →
Do it yourself or use Delegate — orchestration here is pure ceremony. Open the Delegate lesson →

Pick the closest match — you'll get a verdict.

The capstone — the whole level in one prompt

Run one full orchestration (~30-45 min), then grade it. Real repo + agent CLI if you have them; no dev setup? Do every governing step on paper and role-play the fleet with one chat — you still do the Navigator/Verifier work that *is* the class. Pick a job spanning more than one area that you'll run more than once. The prompt below is your tutor and your lead.

You are my orchestration coach AND, separately, the lead agent (the GM) for a practice run. I want to learn to govern a fleet, not do the work myself.

The job: build a small dashboard/report from this input: [PASTE a CSV, dataset, or describe a real cross-area task you'll repeat].

Run it in this order and STOP at each numbered step for my input — don't race ahead:

1. Coach me to write a tight spec — the one outcome, the inputs, the concrete output, and "done means" — and push back if it's vague enough that four agents could drift.
2. Coach me to write a rules file (AGENTS.md/CLAUDE.md) with how-we-work, the commands, one HARD gate, and one machine-checkable acceptance criterion per room.
3. As the GM, decompose the job into specialist subagents and assign each a room. Tell me what runs in parallel vs. what HOLDS on a dependency. Pause so I can approve or redirect the decomposition and the order.
4. Role-play the fleet: report back as if each specialist worked in parallel and produced a branch. Deliberately include ONE plausible-but-invented or out-of-scope choice (a number with no source, a smoothing nobody asked for, a cross-room edit) so I can practice catching it. Do NOT tell me which.
5. Give me a check report mapped to my acceptance criteria, then wait while I review. I'll name the load-bearing claims, say how I'd verify each against the source myself, and identify the planted defect. After I answer, reveal it and tell me whether re-asking you would have caught it (it wouldn't).
6. Help me write the gate decision (merge / redirect / reject per branch) and the 1-3 new rules to fold back into the rules file so the next run starts smarter.

Throughout, hold me to governing before dispatching, setting policy and tempo not keystrokes, and verifying judgment rather than trusting green checks. Be blunt when I slip into the loop or rubber-stamp a green report.
Open Claude ↗

Self-check

0 / 4

You've leveled up when…

Top of the ladder — no next rung. Mastery is depth: sharper specs agents can't drift from, rules that accrete every run's lessons, gates that stand by default. The test: hand your spec and rules file to a stranger and leave the room — does the work come back right, and the bad branch get caught at the gate? If yes, your governance is doing the work, not your presence.

The new craft isn't writing every prompt — it's engineering the loop that runs itself, and standing only at the points that matter. Go run a room.

Back to the overview →