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

Level 3 — Delegate (Cowork)

The senior class. Verb: Delegate. Org-rung: Senior Management. You stop handing Claude a single question and start handing it a whole job — a standing space, a set of skills, and a brief that says what "done" looks like — then you let it run the multi-step work and judge the finished deliverable instead of driving every keystroke. Master this class and you trade turn-by-turn control for a hand-over of the doing: Claude reads, merges, decides, formats, and comes back with a result; you set the tempo and own the verdict.

Before you start — five things to read once

These get used on every page below. Read them now and the rest reads cleanly. If you came up through Level 1 and Level 2, the shape is identical — the same ladder, the same three hats, the same self-contained rules. What changed is reach: Claude now runs the work, not just a fetch.

The four-level ladder (where you are)

This module is Level 3 of 4. The whole ascent:

"MCP" (Level 2's class name) is short for Model Context Protocol — the plumbing that lets Claude reach a real tool like Drive or Gmail. You don't need to understand it to play Level 3; you only need to know that granting that reach happened at Level 2, and here you put it to work inside a standing space.

If you skipped straight here: the two muscles built below — a clear brief and a real review of the deliverable — are this level's entire game. They are the L1 framing-and-verify reflex, scaled up from one answer to a whole finished output. Everything else is loadout and procedure.

A note on the word "Cowork." Product names move. This module uses "Cowork" for the class where Claude is given a standing workspace and runs a multi-step job for you to review. Whatever your build calls the surface, the class is defined by the behavior — delegate a job, review the result — not the label on the button. If the names below don't match your screen, see the availability note.

Which surface this module assumes. The pieces below — a standing space, Skills, subagents, a standing brief, inherited connectors — are real, but they do not all live on one product surface. Skills work across Claude.ai, Claude Code, and the Agent SDK; subagents and standing-brief files (AGENTS.md / CLAUDE.md) are primarily a Claude Code capability; Claude.ai Projects carry saved instructions and files instead of a brief file. So read the loadout as a conceptual loadout whose concrete form varies by surface — not as four switches you'll find in one window. Where it matters, the text says which surface a piece belongs to.

The three hats (your jobs)

Across the whole ladder you wear three hats. They never go away; what changes is which one does the heavy lifting. At Delegate level the work runs while you watch — so the hat that decides what runs, what gets reviewed, and when it ships is the one in charge.

At Level 3, the Conductor hat dominates. The class is no longer "ask one good question" (Navigator-led) or "grant one safe scope and check the action" (Verifier-led). It's "engineer a job, set it running, and decide when it's done" — which is tempo, sequencing, and the accept/redirect call. That is Conductor work.

But you still wear all three, and at this level the cost of dropping one rises:

• You Navigate when you write the brief — a vague destination is the single fastest way to get back a confident, finished, wrong deliverable, because the agent will fill every gap you left with its own assumption.
• You Verify when the deliverable lands — and this matters more here than anywhere below, because a finished multi-step output looks authoritative. A wrong fact in a chat is one wrong sentence; a wrong fact in a delegated deliverable is buried inside five steps of confident work built on top of it.

The vocabulary is the connective tissue of the whole ascent. The Verifier reflex you built at Level 1 on cheap mistakes is the prerequisite that makes delegation safe; the Conductor hat is what this level adds.

Mini-glossary (plain definitions, used throughout)

These terms are new at this level — you meet them before they're fully unpacked in Section 3. Plain definitions first:

• Delegate (the level's core move): hand over a whole multi-step job — not a single question — and let Claude run the steps, then review the finished result. Contrast with Ask (one question, one answer) and Connect (one fetch or action you supervise). Delegating means you judge the deliverable, not each step.
• The loop: picture the work running in a loop of steps; the question is where you stand relative to it. In the loop = you approve every step (total control, but you're the bottleneck — keep it for irreversible calls). On the loop = the work runs and you supervise, stepping in on exceptions and judging the result — this is the Delegate posture. Out of the loop = you walked away and it runs blind. At Level 3 you are deliberately on the loop: reviewing and redirecting, not driving every step, and never absent.
• Standing workspace ("room"): a persistent space — a folder, a Project, a workspace — that holds the files, context, and skills for a job and stays put between sessions. Unlike a single chat window, it doesn't reset to empty; the job lives there. Throughout, "room" is our plain-English word for this standing space; on your screen it may be a Project (Claude.ai) or a project folder (Claude Code) — there is no button literally labelled "Room."
• Standing brief: the written definition of the whole job that travels with the room — what the job is, the constraints, what "done" looks like, the house format. It's the difference between briefing a competent hire once and re-explaining the job every morning. On Claude.ai this is the Project's saved instructions; in Claude Code it's literally a plain-text file named AGENTS.md or CLAUDE.md (the .md just means "markdown," a simple text format) that the tool reads first.
• Skill: a reusable, named capability you set up once and the workspace applies on demand — a saved procedure, a house format, a standard way of doing a recurring task — so you don't re-specify it each run. (Skills are a real, current capability across Claude.ai, Claude Code, and the Agent SDK.)
• Subagent: a worker Claude spins up to handle one part of a larger job (read the notes, pull the decisions, format the output), reporting back into the main job. Each runs in its own context with the tools it's granted — which can be narrower than the main job's. Subagents are primarily a Claude Code capability; some surfaces split work this way, others don't.
• Connector: a switch (granted at Level 2) that lets Claude reach a real tool — Google Drive, Gmail, Calendar. A "scope" is how far that switch reaches (read this folder, not the whole Drive).
• Load-bearing: the parts other things depend on — the facts someone will actually act on. If a load-bearing claim is wrong, real decisions go wrong. (The figure in a budget line is load-bearing; a stylistic word choice is not.)
• Deliverable: the single finished artifact the job hands back for you to judge — the summary, the model, the page — as opposed to a transcript of how it got there. The deliverable is what you review; the steps are what you delegated.

Availability note: the features named in this module (a standing workspace / Projects / folders, Skills, subagents, a standing brief, connectors, and the multi-step delegated runs themselves) vary by plan, by product surface (Claude.ai, the desktop workspace, Claude Code), by device, and by account settings — and the names move as products evolve. If a control described here isn't on your screen, or is called something else, that's why — not a mistake on your part. The class is defined by the behavior (delegate a whole job, review the deliverable), so the lesson holds even where the labels differ.

0. Class Card — at a glance

In ten seconds: Cowork is where you stop asking and start delegating — you give Claude a standing space, a set of skills, and a brief that says what the finished job should look like, then let it run the steps and come back with a deliverable you review. You trade turn-by-turn control (you're now on the loop, not in every step) for a far bigger hand-over: an entire job done while you do something else. The catch you accept in that trade — and the reason the brief and the review are the whole craft — is that the work can now be finished, confident, and wrong before you ever look at it. So you live by two rules: brief it like you'd brief a capable hire, and review the deliverable like it might be wrong, because looking done is not the same as being right.

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

The class in one line: Cowork is a standing space you hand a whole multi-step job — and an agent that runs the steps inside it while you review the finished result.

The plain definition

You stop typing a question and start writing a brief. Instead of "what's the difference between a budget and a forecast?" you hand over "turn these three meetings of notes into a finished weekly summary with the decisions and owners" — and Claude works the steps: it reads all three sets of notes, merges the overlaps, pulls out the decisions, assigns the owners, formats the summary, and hands back a finished document for you to review and accept. You didn't drive any of those steps. You defined the job, set the room up, let it run, and judged the result. That is the whole mechanic. The class is built on one move: Delegate.

It feels like managing a competent new hire: you don't watch their hands, you brief the job and check the work. The class is powerful. Playing it well is entirely about the brief and the review.

The thinking that makes it work

Three practices separate a senior operator from someone who just types a bigger prompt.

• The brief is the product. At Chat a vague ask got you a vague answer you could see was vague. Here a vague brief gets you a confident, finished, wrong deliverable — the agent fills every gap you left with its own assumption and then runs four more steps on top of it. The single biggest predictor of a good delegated result is not the agent's skill; it's whether you wrote what "done" looks like before the work ran. (How to do it deliberately: Section 4 — Preparation.)

• You move from IN the loop to ON the loop. That shift is delegation. At Connect you approved each action as it happened — in the loop. Here you let the multi-step work run and judge the finished thing — on the loop. The leverage comes from stepping out of every keystroke; the discipline that earns it is reviewing the deliverable hard enough that "on the loop" never becomes "out of the loop." (The verification procedure: Section 8.)

• Reach is the currency you spend. The thesis of the whole Ascent: the more you let Claude reach, the more you can hand over. Here you grant a standing space — a room that persists, with skills and scoped tools — so what you hand over grows from "the thinking" (L1) and "the looking-up" (L2) to the doing of the whole job. Bigger reach, bigger hand-over, bigger thing that can go wrong unattended.

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

Be exact here, because a loose version of this boundary is what makes people either over-trust an agent or refuse to delegate at all. The precise statement is:

At Delegate level Claude runs multi-step work on its own, but only within the space, skills and brief you set up. You are ON the loop — reviewing, redirecting — not IN every step. You judge the finished deliverable, not each keystroke.

That is the line. Note what it does not say: it does not say "it does anything you can imagine" (it runs the job you briefed, inside the room you built — it doesn't invent new jobs or reach past its scopes) and it does not say "you walked away" (you're on the loop, supervising and able to redirect, not out of it). What it says is narrower and true: Claude runs the steps; you set the job and judge the result. Concretely:

These are not bugs. They are the boundary of the class — and the new risk that boundary admits is the price of the leverage: wrong multi-step work, done unattended — a whole finished output built on a wrong assumption, handed back looking done. That risk is exactly what the brief (to prevent it) and the review (to catch it) exist to manage. Level 4 moves this boundary again, to many such jobs in parallel under rules you set once.

Why mastering this class matters most before the top

At Orchestrate, the brief becomes a policy that governs many parallel agents, and the per-deliverable review becomes the gate before anything merges. A vague brief here is one wrong summary; a vague rule there is wrong work across your whole system, fast. So the promise of this level is precise:

Master the brief and the deliverable-review here, on the class where you delegate one job and review one result, and Level 4 inherits both as the load-bearing prerequisites of safe orchestration.

The rest of this module is reps on those two muscles.

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.

Every level can technically produce a weekly summary. That is exactly the trap. Building a standing room, writing a brief, and equipping a Skill for a thing you'll do once is a senior manager scheduling a project kickoff to answer a single email. The skill is not "can Delegate do it" — it's "is delegating-and-reviewing the right spend for this job."

Delegate is the most expensive class to set up and the cheapest to re-run. You pay up front — a room, a brief, scoped tools — and you get it back every time the job repeats and every time the work is too multi-step to babysit. Allocate well and one good brief runs a job for months. Allocate badly and you over-spend (a room and a brief for a one-off a single chat would have cracked) or under-spend (driving a ten-step job turn by turn in Chat when you should have delegated it once).

The master gate: the Delegation Test

There is one spine to carry. Everything else hangs off it. Before building a room or writing a brief, run the job through three clauses — it must pass all three:

Delegate when the job is multi-step AND repeatable AND result-reviewable.

The point is not "delegate everything multi-step." It's that all three must hold — miss one and you've mis-allocated. Three corollaries fall out of the gate, each a sub-move of it:

• The Brief-Cost corollary (from result-reviewable). If you can't write the "done" definition in two sentences, the job isn't ready to delegate — the cost of briefing it well now is less than the cost of unpicking confident-wrong work later. A job you can't brief, you drive yourself.
• The Review-Cost corollary (from result-reviewable). Delegation only pays if reviewing the deliverable is cheaper than doing it. If verifying the output costs as much as producing it (every figure must be re-derived from scratch), the leverage is gone — do it yourself or break the job smaller.
• The Repeatability corollary (from repeatable). The room/brief/Skill setup is an investment that amortizes. One run rarely justifies it; from the second run the Skill is most of the brief and the per-run cost collapses. The wrong-spend tell is building a room you use once.

The decision: do it yourself, step down, stay, or step up

Run the job through the gate, then read it off this table. (This is the actionable form — keep it; it encodes the judgment without a second checklist.)

Threaded through the running scenario — stay, step down, step up, or skip

The weekly-summary job makes the gate concrete. Watch the same job change classes as its shape changes:

• One meeting, once, and you'll read it yourself anyway → just do it, or ask Chat to summarize the pasted notes. Single-step, non-repeating, trivially reviewable — the Delegation Test fails multi-step and repeatable. Building a room here is the level's classic over-spend.
• "What decisions are in this meeting doc in my Drive?" → Connect (L2). One fetch, one supervised action, you in the loop. Nothing multi-step to hand over.
• Three meetings → one merged summary with decisions and owners, every week → Delegate (L3). Now it's multi-step (read · merge · extract · assign · format), repeatable (weekly), and reviewable (you can write "every owner named or UNASSIGNED; every decision traces to a note"). All three clauses pass. This is the running scenario, and it's why this class exists.
• The weekly summary, plus a support-ticket digest, plus a competitor-watch — all five running in parallel every Monday under one set of rules → Orchestrate (L4). The bottleneck is no longer doing each job; it's you, serially on the loop for each. That's the level-up signal (Section 13).

The boundary that separates Delegate from the rest, restated exactly: At Delegate level Claude runs multi-step work on its own, but only within the space, skills and brief you set up. You are ON the loop — reviewing, redirecting — not IN every step. You judge the finished deliverable, not each keystroke. Below that line (one ask, one supervised fetch) you're cheaper in Chat or Connect; above it (many jobs, parallel, under standing rules) you've outgrown the room and want Orchestrate.

3. Equipment — the Tools You Equip at This Level

At Chat you equipped pieces that changed what one ask could stand on. At Delegate the loadout changes kind: you're no longer dressing a conversation — you're building the room the job will run in. Every piece here exists to make unattended, multi-step work safe and repeatable: a standing space so the work has somewhere to live, Skills so it does the steps your way, subagents so a big job splits into focused passes, and a standing brief so the room remembers the rules without you re-typing them.

Remember the which-surface caveat from the front matter: these are a conceptual loadout. On Claude.ai the "room" is a Project with saved instructions; in Claude Code it's a project folder with an AGENTS.md/CLAUDE.md. Subagents are mainly a Claude Code capability. Read the table for what each piece does, then take the concrete form your surface offers.

Three things to hold before the table:

• This equipment is set up once, then reused. That's the whole economics of the level. A room you build for the weekly-summary job pays for itself the second time you run it — which is exactly why the gate asks whether the job is repeatable (Section 2). Building a room for a one-off is the level's most common over-spend.
• The boundary holds, restated precisely: At Delegate level Claude runs multi-step work on its own, but only within the space, skills and brief you set up. You are ON the loop — reviewing, redirecting — not IN every step. You judge the finished deliverable, not each keystroke. Equipment is how you draw the edges of that space. A Skill bounds how; a room bounds over what; the brief bounds what "done" means; the connectors it inherits bound what it can touch.
• The cost you're now paying is scope-over-time, not scope-per-action. At Connect you granted reach for one fetch you watched happen. Here a standing room holds a standing set of permissions and can act inside them unattended, across many runs. Read every "scope & safety note" as "what could this touch while I'm not looking?"

The loadout

Availability note: the exact names, surfaces, and packaging of these pieces vary by plan and surface (Claude.ai Projects, the desktop workspace, Claude Code in the terminal) and by account. Skills, subagents, and standing-brief files are all real capabilities, but they live on different surfaces — subagents and AGENTS.md/CLAUDE.md are primarily Claude Code; Projects use saved instructions; Skills span Claude.ai, Claude Code, and the SDK. Which you'll see depends on your surface — if a control isn't where described, that's surface variance, not your mistake.

How the pieces compose — reconciled once (read this; it's the level's most-confused point)

People meet four nouns here and assume they're four switches to toggle in one window. They aren't one window — and they nest. Seeing the nesting is what makes the level click:

1. The standing room is the container. It's the outermost shell — the where. Everything else lives inside it (a Project, or a project folder).
2. The standing brief is the room's rulebook. It's the what and how-strictly — read first by anything that enters, it defines "done" and the do-nots for every run (Project instructions, or an AGENTS.md/CLAUDE.md).
3. Skills are the room's procedures. They're the how for specific recurring tasks — loaded when relevant, so the method isn't re-typed.
4. Subagents are the room's temporary staff (on surfaces that have them) — the who for one big job, spawned, scoped, collected, gone. Connectors are the room's reach — the doors the staff are allowed to open, each granted narrowly.

So "what do I equip to delegate the weekly-summary job?" has one composed answer, sized to your surface: a room to hold it, a brief in that room defining the summary format and what "done" means, optionally a Skill carrying your house summary method, subagents if your surface has them and a run is big enough to split, and the Drive connector if the notes and the output live in real folders. You set this up once. Then every Friday you hand over the job and review what comes back — which is exactly what Section 4 prepares.

The rule of thumb: equip the room so a competent stranger could run the job from it with no further instruction from you — because that's effectively what an unattended agent is. The moment you wish you could stand up many such rooms and run them in parallel under rules set once, the class has run out of room — that's the Level-Up signal (Section 13).

4. Preparation — Before You Engage

At Chat, preparation produced a one-line objective and a sorted pile of context for a single ask. At Delegate the stakes of preparation invert the effort: because you will review the finished deliverable, not each step, almost everything that can go wrong gets decided here, before the job runs. A vague brief doesn't produce a vague answer you can see is vague — it produces confident, finished, wrong work (the signature pitfall, Section 11). Preparation is where you earn the right to look away.

This is the Conductor's work — you're setting what runs, against what, and what "done" looks like before you set the tempo. Nothing gets delegated until the output of this section exists. Five moves.

1. Name the whole job and its "done" — not a question. At Chat you named an outcome you'd act on. Here you name a deliverable the agent will hand back finished, plus the explicit bar it's judged against. "Turn these three meetings of notes into a finished weekly summary with the decisions and owners" is a job. "Help me with my meeting notes" is a topic — and a topic delegated is a coin flip. The "done" definition is the load-bearing half: if you can't write what a good finished summary contains, you can't review one, and you certainly can't delegate one. If you can't state job + done in two sentences, the work isn't ready to hand over — that's a finding, not a failure (the Brief-Cost corollary, Section 2).

2. Run a one-minute scoping discovery on the job. A quick self-interview surfaces what the room and brief must carry so a fresh, unattended agent doesn't have to guess:

• What is the finished deliverable, concretely — its format, its sections, where it lands?
• What does "done well" look like, and what would make the result useless even if it's complete? (Often the fastest way to find the rule that matters: "useless if it invents an owner who wasn't named in the notes.")
• What are the steps I'd take by hand? — you don't script them for the agent, but knowing them tells you where it could go wrong and whether the job is big enough to split (subagents, Section 3).
• What do I know that the agent can't infer? — your owner-assignment rule, that "held" decisions aren't "made," the house format, names that map to people.
• What must it NOT do? — the do-nots are as load-bearing as the dos at this level, because no one's watching mid-run. "Don't assign an owner you're not sure of — flag it instead. Don't invent decisions to fill a section."

3. Scope the reach to the job — the new, level-specific move. This is the step Chat didn't have. Decide, deliberately, what standing access the run needs and grant no more:

• What must it READ? (The three notes — pasted in, or fetched from a named Drive folder?)
• What may it WRITE or ACT ON? (Hand back a draft for you to place? Or write the finished file into a specific folder — if you've granted write scope and the surface supports it?)
• What's explicitly out of scope? (It reads meetings/; it does not touch the rest of the Drive. It drafts; it does not send.)

Concretely, "narrow scope" looks like granting (in your connector settings) read access to one folder rather than your whole Drive, and no send/write scope at all unless the job needs it. The rule: grant the narrowest standing scope the job actually uses, because this scope is live across every unattended run, not just the one you'd watch. Over-granting here is the level's quiet version of the Connect pitfall.

4. Decide the review checkpoint up front. You're on the loop, not in it — so decide now where the loop closes. Is this an accept-or-redirect at the end job (review the finished summary, ship or send back)? Or does it warrant a mid-point check (eyeball the merged decisions before it formats and writes)? Naming the checkpoint before the run is what stops the second half of the signature pitfall: not actually reviewing the deliverable because it looks complete. A finished-looking artifact is the most dangerous output at this level — decide its review before its polish can disarm you.

5. Assemble it into the brief. Everything above is loaded into the room (Section 3): the job and "done" become the standing brief's core; the do-nots become its rules; the house method becomes a Skill if it recurs; the reach decision becomes the connectors and scopes the room uses. Preparation doesn't sit beside the engagement — it becomes the room the engagement runs in.

Output of this section — shown, not asserted. A written objective (job + definition of done) plus the assembled context and scoped access, ready to drop into the brief. For the running scenario:

OBJECTIVE (the job)
  Turn the three meeting-notes files (mon.txt, wed.txt, fri.txt) into one
  finished Weekly Summary I can review and ship — multi-step, handed back done.

DEFINITION OF DONE (the bar I'll review against)
  - One document, house format: a one-line header (meetings · decisions · actions),
    a Decisions list, and an Actions list.
  - Decisions: only ones actually made in the notes. "Held"/"deferred" items are
    labelled as such, NOT listed as decisions. A decision that was later reversed
    is reconciled to its FINAL state, with the change noted.
  - Actions: each has a named owner (or UNASSIGNED — never guessed) and, where
    stated, a date.
  - Overlapping points across the three meetings are merged, not duplicated.

CONTEXT TO ASSEMBLE (what the room/brief must carry)
  - The three notes — read from the `meetings/` folder (Drive connector).
  - Owner rule: owners are people named in the notes. If no owner is named,
    write "UNASSIGNED" — do NOT guess one.
  - Figure rule: never invent a number to fill a slot. If a figure wasn't stated,
    write "pending" and flag it.
  - "Done" != "discussed": a decision needs an explicit resolution in the notes.

REACH / SCOPE (granted standing, kept narrow)
  - READ:  the `meetings/` folder only.
  - WRITE: hand back the finished summary as a draft for my review.
           Do NOT write into other folders; do NOT send or share anything.

REVIEW CHECKPOINT (where the loop closes)
  - Accept-or-redirect at the end. I review the finished summary against the
    "done" bar above before it goes anywhere. (No mid-point check needed — the
    job is short and the output is fully reviewable in one read.)

That block is the artifact this section produces. It is also, almost verbatim, the standing brief from Section 3 — which is the point: at Delegate, good preparation is the room, written down before a single step runs.

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

At Delegate level the workflow is not a conversation — it's a hand-off. You stop producing the steps and start producing the conditions under which an agent produces them: a brief, a room, and a definition of done. Then you go on the loop (reviewing, redirecting) instead of in it (typing each turn). The pipeline below is what stands between "I delegated a whole job" and "I got back confident, finished, wrong work."

The rule that makes it delegation, not abdication: no step without a named output — and the two heaviest outputs are written down, not held in your head. The brief and the review verdict are artifacts. If they live only in your intent, you didn't delegate a job; you gambled on one.

The running example carried end to end: you hand over a whole job — "Turn these three meetings of notes into a finished weekly summary with the decisions and owners" — and Claude works the steps (reads all three, merges overlaps, pulls decisions, assigns owners, formats) and hands back a finished summary for you to review and accept.

Step 1 — Brief → a standing brief (job + done-criteria)

This is the highest-weight artifact in the whole level. Delegation quality lives or dies here: a vague brief doesn't get you a vague answer (the Level 1 failure) — it gets you a confident, finished, wrong deliverable that cost the agent ten minutes to build and costs you twenty to unpick. The brief names four things: the whole job (not the first step), the inputs (which files, where), the shape of the deliverable, and what "done" looks like as checkable criteria — because at this level you judge the finished result, and you can't judge against a bar you never wrote.

Here is the brief for the running example — this is the output of the step, not a description of it:

JOB
Turn three meeting-notes files into one finished Weekly Summary.

INPUTS
- mon.txt, wed.txt, fri.txt (in this room). These are the only sources.
  Do not pull in anything outside these three files.

DELIVERABLE
A single "Weekly Summary" document:
  - A header line: "<n> meetings · <n> decisions · <n> actions"
  - DECISIONS (one line each, with the source meeting cited)
  - ACTION ITEMS — each with a named OWNER (or UNASSIGNED) and, where stated, a date
  - OPEN QUESTIONS / unresolved threads
Keep it under one screen. Plain, skimmable, no preamble.

DONE LOOKS LIKE
- Every decision traces to a line in one of the three files (cite [Mon]/[Wed]/[Fri]).
- Every action item has an owner field. If a note didn't name one, write
  "UNASSIGNED" — never guess a name.
- No figure is invented to fill a slot. If a number wasn't stated, write
  "pending" and surface it in Open Questions.
- Overlaps across the three meetings are merged, not duplicated.
- A decision and its later reversal are reconciled to the FINAL state, change noted.

FLAG, DON'T GUESS
If an owner, a date, a figure, or a decision is ambiguous across the notes,
surface it in "Open Questions" rather than inventing a resolution.

WORK LOG
As you work, list each step you take, and tag every claim with the file it
came from, so I can see the run, not just the result.

Notice what the done-criteria buy you: the lines "every action item has an owner field; if a note didn't name one, write UNASSIGNED — never guess" and "no figure is invented to fill a slot" are the difference between a reviewable deliverable and a plausible fabrication. The brief pre-loads the review. The WORK LOG line is what makes the run legible later (Section 7).

Step 2 — Set up the room → a loaded room + equipped Skills

The agent runs inside the room you give it — that is the level's boundary made physical. Assemble three things: the room/folder (a Project or project folder the job lives in, so the next run starts where this one ended), the input files dropped in (the three notes), and any Skill the job needs encoded once so you don't re-explain it every run.

For the running example the room is light: a "Weekly Summaries" Project, the three note files, and — because this is a repeating job — a small weekly-summary Skill that carries the format and the owner-handling rule so future weeks inherit them without a fresh brief. (You make a Skill by writing these instructions as a named SKILL.md in the Skills area of your surface — or, in Claude Code, a skills/ folder — and Claude pulls it in when the job calls for it.)

SKILL: weekly-summary
- Output format: header count line / Decisions (cited) / Action items (owners) /
  Open questions.
- Owner rule: never infer an owner; write UNASSIGNED if not stated.
- Figure rule: never invent a number; write "pending" if not stated.
- Reconcile reversals to final state; note the change.
- Source discipline: only the files in this room; tag every claim with its file.

A Skill is the brief's repeatable spine, lifted out of the one-off prompt and parked in the room. The first run you write the brief; from the second run the Skill is most of the brief, and you only state what's different this week.

Step 3 — Delegate → a running job with a stated autonomy boundary

Hand over the brief plus the room, and — this is the Conductor's move — state what the agent may do unattended versus what it must stop and surface. Concretely, you type (or paste) this instruction into the room's chat, with the brief and files already loaded — the same chat box you know from Level 1, now pointed at a room instead of an empty window. At Delegate level the default autonomy is "do the whole multi-step job within this room, on these files," and the boundary is "surface anything that would require inventing a fact."

Run the weekly-summary job on mon.txt, wed.txt, fri.txt in this room,
following the brief. Work all the steps end to end and hand me the
finished summary. Stop and ask only if an owner, a figure, or a decision
is genuinely ambiguous across the notes — don't guess to keep moving.

The output is a job that is now running its own steps — reading, merging, extracting, assigning, formatting — with a line you can point to that says where its autonomy ends.

Step 4 — Monitor → a go / redirect signal mid-run

Being on the loop means watching the run unfold against the brief's steps and catching a wrong assumption before it hardens into a wrong deliverable. You are not re-doing the work; you're scanning the visible progress for the one drift that would poison everything downstream. The run surfaces its steps as it goes — Reading all three sets of notes → Merging overlapping points → Pulling out the decisions → Assigning owners → Formatting — and that trace (which your brief's WORK LOG line forced) is your monitoring surface.

The signal you're producing is a single mid-run call:

Mid-run, you see: "Assigning owners — defaulting unnamed action items
to the meeting organizer."

REDIRECT (now, not after): "Stop — don't default unnamed owners to the
organizer. Mark them UNASSIGNED per the brief. Re-do the owner pass."

Caught here, it costs one line. Caught at review, it means re-reading every action item to find which owners were invented. That is the whole reason monitoring is its own step.

Step 5 — Review → a reviewed deliverable + a verdict

Now you judge the finished deliverable against the done-criteria — the Verifier hat, still worn under the Conductor's. The discipline here is the level's quiet killer: because the output looks complete, the temptation is to skim it and accept. A finished-looking summary is a claim that the work was done right, not proof of it. You don't re-read every keystroke; you spot-check the load-bearing claims — the ones a decision will hang on — against the source files, not by re-asking the agent.

Here is the deliverable that comes back, and the review run against it:

WEEKLY SUMMARY                                              [Done]
3 meetings · 5 decisions · 6 actions

DECISIONS
1. Phase 1 scope locked. [Mon][Wed]
2. Launch held at Mar 14 (revised from Mar 7 set on Mon). [Wed]
3. Marketing budget approved at $48,000 with a 10% contingency. [Wed]
4. Vendor shortlist cut to two. [Wed]
5. Hiring freeze lifted for the data role. [Fri]

ACTION ITEMS
- Send revised launch plan — Owner: Priya — due Mar 3 [Wed]
- Circulate locked Phase 1 scope — Owner: UNASSIGNED [Mon]
- Get two vendor quotes — Owner: Marco — due Wed [Wed]
- Post the data-role req — Owner: Dana [Fri]
- Confirm the contingency line with finance — Owner: Priya [Wed]
- Book launch-readiness review — Owner: UNASSIGNED [Wed]

OPEN QUESTIONS
- "Launch" date: Mar 14 (Wed) supersedes Mar 7 (Mon) — confirm with the team.

REVIEW (against DONE-criteria):
✓ Decision #1, #4, #5 each cite a source meeting. PASS.
✓ Decision #2 reconciles the Mar 7 → Mar 14 reversal to final state + notes it. PASS.
✓ Two actions correctly left UNASSIGNED, not guessed. PASS — this is the catch
  Step 4 protected; it held.
⚠ Decision #3: "$48,000" is a load-bearing number (money). The brief says never
  invent a figure. SPOT-CHECK against wed.txt before accepting — open the file,
  confirm the figure exists; do NOT ask the agent to "confirm its own source."
? Action "Get two vendor quotes — due Wed": "Wed" is ambiguous (which Wed?).
  Should have surfaced as an open question, not assigned a vague date.

→ Open wed.txt. It says: "Marketing budget approved — add a 10% contingency,
  finance to confirm the base figure." The base number was NEVER stated.
  The "$48,000" appears in NO meeting. The agent had a "budget approved"
  decision and a format that wanted a number, so it manufactured a plausible one.

VERDICT: Accept with two redirects —
  (1) strike the invented $48,000; write "base figure pending finance";
  (2) move the ambiguous vendor-quote date to Open Questions.

The verdict is the artifact: not a feeling that it "looks good," but a line-by-line pass/flag against criteria you wrote in Step 1, with the load-bearing number checked outside the agent, in the source file. That fabricated specific — a round, confident figure inside a finished doc — is the level's signature failure (Section 8); the canonical workflow catches it here, in the spine.

Step 6 — Accept or redirect → an accepted artifact, or a redirect brief

Two exits, and you name which. Accept: the deliverable clears the criteria; you ship it and the room (with its Skill and files) becomes the reusable context for next week's run. Redirect: hand back a scoped correction that names the specific gaps — never a vague "try again," which restarts the whole multi-step job and re-rolls the parts that were already right.

REDIRECT (scoped, from the review verdict):
"The summary is good — keep all of it except two fixes.
(1) Decision #3: the $48,000 base figure is in no meeting. Replace with
'Marketing budget approved with a 10% contingency; base figure pending finance.'
(2) The vendor-quotes action: 'due Wed' is ambiguous; move it to Open Questions
as 'vendor-quote deadline unclear — confirm.'
Don't touch anything else."

That redirect changes two lines; everything that passed stays. The accepted artifact — the corrected finished summary plus the room that produced it — is the walk-away.

The pipeline in one breath: standing brief → loaded room + Skills → running job with an autonomy boundary → mid-run go/redirect → reviewed deliverable + verdict → accepted artifact or scoped redirect. The two heaviest stones are the brief (Step 1) and the review verdict (Step 5) — write those down and the level holds. Skip either and you're back to gambling on finished-looking work.

6. Goals → Considerations Map

Three jobs recur at Delegate level. They share the spine — brief, room, delegate, monitor, review, accept — but each bends it at a different joint. Match your real intent to the variant instead of running the pipeline blind, because where a job is fragile decides which step earns the weight.

The tell that you've matched goal to variant: a synthesize run ends with every load-bearing line traceable to a source; a repeatable-process run ends with a Skill-backed room where next cycle is one prompt; a build run ends with the early assumption confirmed before the artifact was finished on top of it. The running summary is a synthesize job — which is exactly why its brief, not its monitoring, does the heavy lifting.

7. Connect the Components — Patterns & Outliers

A delegated job is not one answer you read — it's a finished deliverable built on a chain of steps you didn't watch. At Chat you read every turn as it landed; here Claude reads all three meetings, merges the overlaps, pulls the decisions, assigns the owners, and formats the summary before you look at anything. That's the bargain of the level — and the precise statement of its boundary, used identically everywhere in this module:

At Delegate level Claude runs multi-step work on its own, but only within the space, skills and brief you set up. You are ON the loop — reviewing, redirecting — not IN every step. You judge the finished deliverable, not each keystroke.

So "connecting the components" stops meaning read each reply in sequence and starts meaning reconstruct the chain from the artifact. The deliverable is the only thing you're handed; the steps that produced it are inferred. Your Conductor job is to read the whole engagement backwards from the output — to see, in a finished summary, the shape of the work that made it, and to catch where that work bent.

Track the run, not the turns

You can't pressure-test a step you never saw, but a competently-run agent leaves a trail — if your brief required one. The WORK LOG line from Step 1 is exactly that requirement; here's why it earns its place:

The discipline: before you judge whether the summary is good, judge whether the run is legible. A deliverable with no trail isn't finished work — it's a confident guess wearing finished work's clothes, and you cannot review it. That alone is grounds to redirect. (The one line that buys you the trail: "As you work, list each step you take and tag every claim with the file it came from.")

Patterns — promote them

A pattern is a regularity that survives the run and is worth keeping past this job. At Delegate the unit of capture is bigger than a single good answer — it's a repeatable piece of the process:

• A brief framing that produced clean work. If "list every decision as Decision → cite the meeting, one line each" gave you a usable summary, that's not a one-off prompt — it's the spec for next week. Promote it into the standing brief so the job starts there every time (Section 9).
• A Skill the agent leaned on correctly. If a "house summary style" Skill made three runs come back in your format without re-explaining, promote it — that's exactly what Skills are for: a method that travels with the job instead of being re-typed.
• A recurring true signal. "Launch dates always live in the Friday or Wednesday notes," "budget lines always need a contingency call-out" — bake the regularity into the brief so the agent looks for it unprompted.

The tell of a real pattern: it held up under review and it will recur. Promote those into the room/Skills/brief and the level compounds — each run makes the next one cheaper. A pattern that's true once but won't recur is just a good outcome; capture it (Section 9), don't institutionalize it.

Outliers — interrogate them

An outlier is a finished-looking output that doesn't add up. At Chat the drift signals were hedging, self-contradiction, and an unsupported number — read live, turn by turn. At Delegate the dangerous drift is silent: it's already baked into a polished deliverable, so it reads as done. These are the concrete drift/anomaly signals for this level — what to scan a finished deliverable for:

1. The confident, complete, un-briefed output. The summary covers a fourth topic you never handed over, or names an owner who wasn't in any meeting. The hallmark of delegated failure is a whole finished section built on something invented — fluent, formatted, and wrong. Confidence and completeness are not coverage; check the deliverable against what you actually gave it.
2. Counts that don't reconcile. Header says "3 meetings"; the body only ever cites two files. Or "5 decisions" but you can find six in the notes. A coverage count that doesn't match the inputs means a step silently dropped data — an input never got read, or a decision got merged away.
3. A figure, owner, or date that no source supports. "$48,000" in a decision line when the notes only said "budget approved, base figure to be confirmed." A specific, load-bearing field with no traceable origin is the delegated cousin of Chat's invented number: the agent filling a slot the format demanded rather than reporting a fact. (This is the running scenario's exact outlier — see Section 8.)
4. A swallowed contradiction. Monday's notes set the launch at Mar 7; Wednesday's pushed it to Mar 14. A good summary surfaces the conflict and reconciles to the final state with the change noted; a drifting one silently picks one (usually the last it read) and presents it as settled with no note. Reconciliation that should have been flagged, wasn't.
5. A missing assumptions section. Two unnamed owners, one undated action — and the deliverable flags none of it. Total absence of hedging across a genuinely ambiguous input is itself the anomaly: the agent resolved every gap by guessing and told you about none of the guesses.

How to interrogate without re-driving the whole job: don't re-run it, redirect it at the outlier. You stay on the loop, not in it.

Before I accept this — three checks:
1. The header says 5 decisions across 3 meetings. List each decision with the
   exact meeting file it came from. If any meeting contributed none, say so.
2. "Marketing budget approved at $48,000" — quote the line from the notes that
   states the $48,000 figure.
3. Monday and Wednesday give different launch dates. Which did you use, why, and
   is the change noted as the brief requires?

That turn is the Conductor move that defines the level: you didn't do the work and you didn't re-do the work — you read the deliverable as a whole, found where the chain bent, and sent the agent back to that one seam. The verified version of that is Section 8.

8. Qualitative vs Quantitative — Results Vary by Case

A delegated deliverable mixes two kinds of content, and they fail — and verify — in opposite directions. The summary contains facts lifted from your inputs (the launch is held to Mar 14; the budget carries a 10% contingency; Dana owns the data-role req) and judgments the agent made while running (which overlapping points to merge, which discussion rose to a "decision," who the implied owner is). Misfiling one as the other is how a confident, finished, wrong deliverable gets accepted.

And results vary by case: hand the same three files to the same brief twice and the merge can split differently, a borderline discussion can get promoted to a decision in one run and dropped in the next, an ambiguous owner can resolve to a different person. A run that came back clean last week is not a warrant for this week's run. That variance is exactly why you verify by type against the source — not by trusting that it worked before.

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

This is the heart of the level. At Chat the seductive failure was fluent. At Delegate it's finished — and "finished" impersonates "verified" far more convincingly. Name the two false signals plainly:

• "It ran" is not verification. A delegated job that completes without error has proven only that the process didn't crash — not that the output is true. The agent can flawlessly execute every briefed step and still have read "Sara" where the note said "Sarah," promoted a hallway aside to a board decision, or quietly dropped the third meeting because the file was malformed. Completion is a statement about the machinery, not the content. A job that ran cleanly on a wrong assumption is precisely the level's new risk: wrong multi-step work, done unattended, handed back looking done.
• "It sounds right" is not verification. The deliverable is formatted, the owners are plausible, the dates are sensibly spaced, the tone matches your house style — of course it does, that's what the agent is good at. Plausibility is the agent's native output, so it carries zero information about correctness. The summary will read like a perfect weekly recap whether or not it matches the meetings. Surface polish is evidence of competence at formatting, never of fidelity to the source.

The verification that actually counts at this level is therefore against the real source, not against the deliverable's own confidence. Concretely:

1. For each load-bearing factual claim, open the input and find the line. Decision, owner, date, figure — the things people will act on. The check is deliverable → source file, one direction: does wed.txt actually state a $48,000 figure? You are not asking the agent whether it's sure. Asking the agent to confirm its own output is not verification — if it misread or invented the line, "are you certain?" usually returns the same fabricated line stated more confidently, because it's re-reading its own output, not your notes. The check must come from something that isn't the agent: the original file, opened by you.
2. For each load-bearing judgment, make the reasoning visible and attack it. "Why did you record this as a decision and not a discussion? What in the notes made Marco the owner rather than Priya? Show me the two points you merged and why they're the same issue." A merge or promotion that survives the question is one you can ship; one that collapses under it was the agent filling structure, not reporting substance.
3. Reconcile the counts to the inputs. Three files handed over, three files cited. Five decisions claimed, five decisions you can point to. The count is a cheap, high-signal cross-check that no whole step silently dropped your data.

One worked catch

The agent returns the finished Weekly Summary. It's clean — formatted, owned, dated. Under Decisions sits:

Decision: Marketing budget approved at $48,000 with a 10% contingency. [Wed]

Everything about it reads done. The number is specific, the contingency matches a real discussion, the source is cited. "It sounds right" — and it ran without error, so "it ran" too. Both false signals are firing green.

• The wrong move: accept it (it's plausible and complete), or ask the agent "are you sure about the $48,000?" — which re-reads its own output and cheerfully re-confirms the figure.
• The right move (verify against the source): open wed.txt and find the line. The notes say: "Marketing budget approved — add a 10% contingency, finance to confirm the base figure." The base number was never stated. The contingency is real; the budget was approved; but $48,000 appears nowhere in any meeting. The agent had a "budget approved" decision and a format that wanted a figure, so it manufactured a plausible one to fill the slot — exactly the failure the brief's "no invented figures" rule was written to catch, and the same outlier the workflow flagged in Section 5.

Verdict: keep "Marketing budget approved with a 10% contingency, base figure pending finance" (the source supports it); strike the $48,000 (invented); redirect the agent to mark unstated figures as pending rather than guessing them. The fluent specificity — a round, confident number in a finished doc — was the tell, exactly as at Chat. The difference is that here it arrived pre-baked into a deliverable that completed successfully, which is why neither "it ran" nor "it sounds right" could have caught it. Only the source could.

The rule for the level: a finished deliverable is a stack of claims to be traced, not a result to be accepted. Done ≠ correct; ran ≠ verified; sounds right ≠ is right. You verify the action and the data against the real source — because that's the only place the truth lives.

9. Recommendations → Plans

A delegated engagement has to produce something you can stand behind and reuse — not a transcript, not even just the deliverable, but a deliverable you've judged, with its trust on the record, and a brief that makes next week cheaper. Three moves turn the run into that walk-away artifact.

1. Assemble recommendations — tagged by trust

After the review (Sections 7–8), don't ship the summary whole. Decompose it into the actions it actually recommends, and tag each by how far it survived verification. The tag is the product — it's the difference between "I read it" and "I judged it." Carrying the running example through:

Tags, defined once and reused:

• ACT ON IT — traced to source or low-stakes; ship it.
• ACT AFTER I CONFIRM X — load-bearing and pending one external check or one human confirmation; named explicitly so it can't be forgotten.
• DISCARD — didn't survive verification; struck, with what replaced it noted so the gap is visible, not silent.
• PROMOTE — a process recommendation; sends it into the standing brief/Skill (move 3).

2. Line them into a plan — what's handed to Claude vs. kept by you

Sequence the surviving recommendations into an ordered plan, and on each line name the hand-over precisely. The level's boundary sets the split: Claude runs the multi-step work within the room and brief you set up; you stay on the loop, owning the calls that act on the real world.

The split is the level in one table: the assembling, formatting, drafting, and re-running — the multi-step labor — is Claude's; the confirming-against-reality and the irreversible acts (setting the live launch date, hitting send) stay yours, because those are calls, not keystrokes.

3. Capture the reusable context — the standing brief

The walk-away artifact at Delegate isn't only the finished summary — it's the standing brief that makes the next run start where this one ended. This is where the promoted patterns (Section 7) and the survived judgments land. A brief worth its name records the job, the "done," the promoted rules, and what stays yours — shown concretely:

STANDING BRIEF — Weekly Meeting Summary
(Claude.ai: paste into Project Instructions · Claude Code: save as CLAUDE.md)

JOB: Read this week's meeting notes (the .txt files in /meetings) and produce
one Weekly Summary deliverable.

DONE LOOKS LIKE:
- A header line: "<n> meetings · <n> decisions · <n> actions" — counts must
  reconcile to the files actually read.
- DECISIONS: each as a one-liner with the source meeting cited [Mon]/[Wed]/[Fri].
- ACTIONS: each with an owner (a real name OR UNASSIGNED) + due date where stated.
- OPEN QUESTIONS / ASSUMPTIONS: list EVERY inferred owner, unstated figure, or
  conflicting date. Never guess a missing number — mark it "pending". Never
  silently resolve a date conflict — reconcile to final state AND note the change.

RULES (promoted from prior runs):
- Launch dates usually live in the Wed/Fri notes; check there.
- Budget items need an explicit contingency call-out.
- Never invent a figure to fill a slot (the $48,000 catch — mark "pending").
- Use the "house-summary-style" Skill for formatting — don't re-derive it.
- Keep a WORK LOG: list each step and tag every claim with its source file.

WHAT'S MINE, NOT YOURS: do not finalize live dates, make owner assignments, or
send anything. Surface them for me to confirm.

That brief is the level's compounding asset: the verified judgments became rules, the invented-figure catch became a "mark it pending" rule, the date conflict became a "reconcile and note" rule, and the house style became a Skill the job carries. Next week you hand over three files and a brief that already knows where you got burned — and the only new work is the review.

The walk-away, in one breath: a judged deliverable → recommendations tagged ACT / CONFIRM / DISCARD / PROMOTE → a plan that names what Claude runs and what you confirm → a standing brief that makes the next run cheaper. That's a one-off delegation turned into a standing job — which is the doorway to the wish that bridges to Level 4 (Section 13).

10. Worked Examples

Three runs through the full template — brief → set up the room/Skills → delegate → monitor → review → accept or redirect. Each is a real Delegate-level job: one carries the running scenario end to end, one is the same shape on a higher-stakes deliverable, one is the recurring job that forces the level-up signal. Every prompt block below is a standing brief — written to a worker that will run the whole job unattended — not a single question. That is the difference from every example one rung down.

The Delegate-level reading test for all three: the brief defines the whole job and what "done" looks like before any step runs, and the run ends at a reviewed deliverable, not a transcript. If either is missing, you played Connect with extra steps.

Example A — The running scenario, end to end (three meetings of notes → a finished weekly summary)

The job from the demo: hand over the whole thing — read all three, merge overlaps, pull decisions, assign owners, format it — and get back a finished summary to review and accept.

Brief (define the whole job + what "done" looks like). This is not "summarise these" — it names the steps' shape, the deliverable's structure, and the acceptance bar, because at Delegate level you judge the finished thing, not each keystroke. (It is the same brief from Section 5, Step 1 — the canonical fact-set: 3 meetings, the launch reconciled Mar 7 → Mar 14, budget approved with a contingency but no stated base figure.)

JOB: Turn the three meeting-note files in this room (mon.txt, wed.txt, fri.txt)
into one finished Weekly Summary I can send to the leadership channel as-is.

DO, in order:
1. Read all three sets of notes in full.
2. Merge points that recur across meetings into a single line.
3. Pull out every DECISION and every ACTION ITEM as distinct lists.
4. Assign an OWNER to each action — the name the notes attribute it to.
   If the notes never name one, write "UNASSIGNED" — do NOT guess.
5. Format: header count line · Decisions (cited) · Actions (owner — task — date)
   · Open Questions.

DONE LOOKS LIKE:
- Header: "<n> meetings · <n> decisions · <n> actions", counts reconcile to files read.
- Every decision cites its source meeting [Mon]/[Wed]/[Fri].
- No action without an owner field (a real name OR UNASSIGNED).
- No invented figure — if a number wasn't stated, write "pending" and flag it.
- A reversed decision is reconciled to final state, with the change noted.
- Length: under one screen. Tone: plain, internal, no hype.
- WORK LOG: list each step; tag every claim with its file.

Set up the room/Skills. Drop the three note files into one Project so the worker has a standing room, and write the brief into the Project's Instructions so it travels with the job (not just this one message). No new Skill is strictly needed — Claude can already format and pull out items on its own — but if your org has a "weekly summary" house format, saving it as a Skill is what makes next week's run identical without re-briefing.

Delegate. Hand the room + brief to one worker and let it run the multi-step work — typed into the room's chat, files already loaded. This is the line the demo dramatises, the steps resolving into a deliverable:

[worker, working the brief]
▸ Reading all three sets of notes
▸ Merging overlapping points
▸ Pulling out the decisions
▸ Assigning owners
▸ Formatting the summary
→ returns: Weekly Summary [Done] — "3 meetings · 5 decisions · 6 actions"

Monitor (you're ON the loop, not IN every step). You don't approve each step. You watch for the two things that mean stop and redirect now rather than at the end: a step that silently changed the job ("I also reordered the decisions by impact" — you didn't ask for a judgment call) and a step that ran on a missing input ("mon.txt was empty, so I summarised the other two" — a quiet scope change you must catch live). Everything else, you let run.

Review the deliverable (the step the level lives or dies on). The returned artifact is the one shown in Section 5: header 3 meetings · 5 decisions · 6 actions, the launch reconciled to Mar 14, two honest UNASSIGNED owners — and one planted defect: Decision #3 states "$48,000," a figure in no meeting. Grade against done: every decision is cited (good); two actions are honestly UNASSIGNED not guessed (the brief working, not a failure); the reversal is reconciled and noted (good). The catch you must make as Verifier is the one the workflow made in Section 5 — open wed.txt, confirm the budget figure was never stated, and strike it.

Accept or redirect. Not a reject — a surgical redirect, the Conductor's move:

Good — accept the structure, owners, citations, and the launch reconciliation.
One fix: the $48,000 base figure is in no meeting (wed.txt only says "base figure
to be confirmed by finance"). In Decision #3, replace "$48,000" with
"base figure pending finance". Leave everything else.

The worker re-runs that slice and returns a deliverable you ship. Accepted output: a sendable weekly summary, every action owned-or-flagged, every figure traceable or marked pending. Captured for reuse: the brief itself, now proven, becomes the room's standing brief for next week — the job runs again on fresh notes without you re-writing any of it.

Example B — Same shape, higher stakes (a quarterly board pack from raw inputs)

The running scenario's mechanics, scaled to a deliverable where confident-but-wrong is expensive — which raises the bar on the brief and the review, not the number of steps.

Brief. The escalation over Example A is entirely in the done clauses, because the Wrong-Answer Cost is high:

JOB: Assemble a Q2 board pack from the files in /board-q2 (the P&L export,
the OKR tracker, last quarter's pack). Produce: a 1-page exec summary +
a metrics table + a "risks & asks" section.

DONE LOOKS LIKE:
- Every number in the pack is copied from a source file, with a cell/sheet
  reference. NO number is computed or estimated by you unless I asked for it,
  and any computed number shows its formula.
- Quarter-over-quarter deltas are shown as (this Q / last Q / % change).
- The risks section lists ONLY risks named in the source notes — do not invent
  plausible-sounding risks to fill the section.
- Anything you could not source from a file goes in a "GAPS — I need these"
  list at the top, not silently omitted or filled.

Set up + delegate. One room, all source files, the brief saved as a Skill if board packs recur. Hand it over; let it run read → extract → compute deltas → draft → format.

Monitor + review. The high-stakes review is quantitative-first (Section 8): every number gets traced to its cell, because a single fabricated figure in a board pack is the level's signature failure made expensive — the exact $48,000-shaped error from Example A, now in front of a board. The worker returns the pack plus a GAPS block:

GAPS — I need these:
- Net retention for Q2 is not in any source file. Left blank, did not estimate.
- The OKR tracker has no owner for KR-3; risks section flags it as unowned.

That GAPS block is the deliverable doing its job: it surfaced the holes instead of papering over them with plausible numbers. Redirect: you supply net retention, confirm KR-3's owner, send one corrective turn. Accept: a board pack where every figure traces to a source and every gap was declared, not disguised.

Example C — The recurring job that forces the level-up (weekly, across many rooms)

The job that ends the class. You've run Example A four weeks running and it works. Now the wish arrives.

Brief (now standing, not one-shot). You write the brief once and want it to govern every future run without re-issuing it:

STANDING BRIEF (lives in /weekly-ops):
Every Monday, turn that week's three meeting-note files into the Weekly Summary
using the house-summary-style Skill. Same DONE rules as always: owners or
UNASSIGNED, cite the source meeting, never invent a figure (mark "pending"),
reconcile reversals to final state, keep a WORK LOG, under one screen.

The friction that is the whole point. You can delegate this one job beautifully. But you have five of these — the weekly summary, a support-ticket digest in another room, a competitor-watch in a third — and at Delegate level you still kick each one off and review each one yourself, room by room, on the loop for every job. The run works; the system doesn't scale. You catch yourself writing the wish that is the exit signal (stated canonically in Section 13). Example C isn't a failure to fix — it's the class telling you it has run out of room. The brief that travels with one job wants to become rules that govern a whole system — which is the next class.

11. Pitfalls

Delegate-level failures divide into two kinds, and the dangerous ones are in the second. The first kind bites in a single run and you see it immediately. The second kind only bites across a longer engagement — a brief reused for weeks, a deliverable accepted on a glance — and by the time you notice, you've shipped a month of confident, finished, wrong work. The signature pitfall sits in that second kind: a vague brief returns confident, finished, wrong work, and because it looks complete you don't actually review it. That is the whole class's failure mode in one line; the table breaks it into its parts.

The one reflex under all of them: a finished deliverable is a claim that the whole job was done right — review it as one. At Delegate level the danger isn't a wrong sentence on screen; it's a wrong job, completed, formatted, and waiting to be shipped because it looks done.

12. Practice + Self-Check

Reps on the two muscles that make or break this level: the brief and the review. Run one full delegation now — about 20–30 minutes — then grade it against the rubric. The rubric is the instructor; everything it asks for is defined in this module.

Setup — where to do this (so the practice is executable)

On claude.ai: click Projects in the left sidebar → New project; name it; open Instructions and paste your brief; upload your input files into the project. "Hand it to one worker" = type your delegate prompt into a new chat inside that project (the same chat box from Level 1, now with the room loaded). On Claude Code: make a project folder, write the brief into a CLAUDE.md, drop the files in, and run the job from the terminal. Either way the shape is identical: a room holds the job, a brief defines "done," you type the go.

The starter task (do it now)

Pick a real multi-step job from your work that passes the Delegation Test (Section 2) — multi-step AND repeatable AND result-reviewable. (A single question is a Chat task; one fetch is a Connect task — pick something with at least three steps and a deliverable you'd actually use.) If nothing fits, use the house job: drop three real meeting-note files (or three long email threads) into a Project and run the running scenario.

1. Brief (8 min). Write the standing brief before you hand anything over. It must contain: the whole job as ordered steps, the deliverable's exact shape, a DONE-LOOKS-LIKE block with at least one acceptance clause and one negative-space clause ("do NOT…"), the forcing rule "if any input is missing or ambiguous, stop and list it — do not guess," and the WORK LOG line.
2. Set up + delegate (2 min). Put the inputs in one room with the brief, hand it to one worker, let it run the whole job. Do not approve individual steps.
3. Monitor (passive, during the run). Watch only for the two stop-signals: a silent scope change, or a step run on a missing input. Redirect live only if one fires.
4. Review against the brief (8 min). Take the returned deliverable and grade it clause by clause against your DONE block. Trace every number/owner/date to a source file. Find the one error that would hurt most if shipped.
5. Accept or redirect (3 min). Send one surgical corrective turn at the largest gap ("accept everything except X; fix just X because Y"), then accept the re-run. Capture the proven brief into the room as its standing brief.

Self-check rubric (gradable from this module alone)

Scoring. 8/8 — you delegated and reviewed like a Conductor; read Section 13. 6–7 — solid; the usual misses are a thin DONE block (#2) or a rubber-stamp review (#5) — re-run and force those. 5 or below — you're driving, not delegating: most often #1 (you briefed a task, not a job) or #3 (you approved every step). The signature failure hides in #2 and #5 together — a vague brief that returns finished-looking wrong work you don't really review. If you missed both, that is the level's signature pitfall; re-run with a DONE block and a clause-by-clause review.

13. Level-Up / Exit Criteria — Bridge to the Next Class

You don't graduate Delegate by feeling like a manager. The feeling of a clean, finished deliverable landing in your lap is exactly what the signature pitfall counterfeits. The gate is behavioural.

The exit gate — you've mastered Delegate when you consistently, unprompted:

A blunt self-test: could you hand a colleague one of your standing briefs and a folder, and trust the deliverable that comes back — because the brief makes "done" checkable and the gaps self-declaring? If yes, you're out of Senior Management. One marker worth naming: at the entry to this level you either drive every step (no real delegation) or rubber-stamp the result (no real review); at the exit you've calibrated — you let the work run and you judge the finished thing hard, and you know the brief is what buys you both.

What the gate does NOT require: you haven't failed because you still kick off and review each job yourself, one room at a time (that is the level's design — you're on the loop per job). You haven't failed because you can't set rules that run many jobs in parallel unattended (that's the next class). Hitting those walls is graduation, not failure.

The signal you've outgrown it

One unmistakable tell — a specific, repeated wish (this is the canonical statement; Sections 3 and 10 point here rather than re-quote it):

"I keep wishing I could set the rules once and have it run many of these jobs in parallel across my whole system — and only pull me in when one trips a rule I set — instead of kicking off and reviewing each one myself, room by room."

When briefing-and-reviewing one job at a time becomes the slow part — when you have five good standing briefs and the bottleneck is you, serially on the loop for each — the class has run out of room. That wish is the thesis asserting itself again: the more you let Claude reach, the more you can hand over. You've handed over each job; now you want to hand over the orchestration of all of them.

The hand-over you're trading up for

The catch worth naming before you go: once many agents run in parallel under standing rules, a single bad instruction stops being one wrong deliverable and becomes wrong work at scale, fast. That's why Level 4 leads with rules and gates — the written brief that governed one job becomes the policy (AGENTS.md / CLAUDE.md) that governs a system, and the review you did per deliverable becomes the human-gate before merge. The brief-and-review discipline you built here is the exact prerequisite that keeps parallel orchestration from amplifying your mistakes.

A note on the top rung

Level 4 has no "next class" — it is the summit. So mastery there is not a further rung; it's depth in orchestration. The Delegate skills you're carrying up — a precise brief, a testable DONE, a hard review — don't change shape at the top; they multiply. At Leadership you write them once, as rules, and a grid of agents obeys them in parallel. Going up was about reach; the top is about how well you wield it.

Hand-off

Next: open Claude Code and direct several agents at once — that's Orchestrate.

Carry three things forward: the brief discipline (a parallel agent with a vague rule fails faster, across your whole system, not just one deliverable), the review-the-deliverable reflex (at scale it becomes the gate before anything merges — wrong work now lands in parallel), and one proven standing brief from this level — bring a job you delegated well here, and let Level 4 be the thing that turns it from a brief you run into a rule that runs itself, many times over, under your watch. Same Conductor, same hard review — now pointed at a whole system instead of one job at a time.