Multi-Step Delegation Basics

10 examples to get you started with Multi-Step Delegation - 7 basic and 3 intermediate.

Multi-step delegation means handing Claude a goal and a plan rather than a single narrow instruction. Instead of asking for one small thing at a time, you describe the outcome you want, let Claude break it into a numbered plan, and have it work through that plan one step at a time. The examples below start with the simplest version of this - a single delegated task with one checkpoint - and build up to juggling several deliverables and deciding how much autonomy to give Claude along the way.

Basic Examples

1. Delegate a Research-and-Draft Task

Hand Claude a goal instead of a single instruction, and let it propose the steps.

Research the current state of passkey adoption among major consumer apps and draft a one-page summary I can share with my team. Before you write the summary, tell me your plan.

• Claude responds with a short numbered plan (what to research, how to structure the summary) instead of jumping straight to a finished draft.
• You get a chance to redirect scope before any real work happens, which is cheaper than fixing a wrong draft.
• The phrase "tell me your plan" is doing the work here - it converts a single-shot request into a multi-step one.
• This is the smallest possible version of delegation: one goal, one plan, one pause.

Related: What Multi-Step Delegation Looks Like with Claude - the concept behind this pattern

2. Break a Large Ask into a Numbered Plan

Ask Claude explicitly for a plan before any execution begins.

I need to reorganize about 40 scattered meeting notes into a single reference doc by project. Don't start yet - first give me a numbered plan for how you'd approach this.

• Naming a step count or structure ("numbered plan") nudges Claude toward a concrete, checkable list rather than a vague description of its approach.
• A plan you can read in ten seconds is easier to correct than a wall of finished text.
• If a step in the plan looks wrong, you fix it once instead of catching the same mistake repeated across 40 notes.
• This is the foundation every other example in this page builds on.

Related: Breaking a Large Task into a Plan Claude Can Execute - a full walkthrough of this step

3. Add a Checkpoint Before the Final Step

Tell Claude to stop and wait for approval before it produces the finished output.

Draft an outline for the onboarding guide first. Stop there and wait for my go-ahead before writing the full guide.

• The checkpoint sits between planning and production, which is usually where mistakes are cheapest to catch.
• Claude will hold at the outline and wait for a reply instead of continuing on its own.
• If the outline is close but not quite right, you can adjust one line instead of rewriting a finished document.
• Skipping this step is the single most common way multi-step delegation goes wrong.

Related: Checkpoints and Human Review Gates in a Delegated Workflow - more on where to place gates

4. Clean Up and Reorganize a Set of Notes

Delegate a multi-step cleanup task with a review point partway through.

Here are my raw notes from six product interviews. First group them by recurring theme and show me the groupings. Once I confirm the groupings, write a one-paragraph summary for each theme.

• Splitting "group" from "summarize" turns one big fuzzy task into two checkable steps.
• You approve the grouping - the structural decision - before Claude spends effort writing polished prose on top of it.
• If a note lands in the wrong group, that is a one-line fix instead of a rewritten summary.
• This pattern works for almost any "sort, then write" task: notes, feedback, support tickets, survey responses.

5. Produce a Multi-Part Report with a Review Gate

Delegate a report with several sections, and hold the last section for your review.

Write a quarterly update with three sections: wins, risks, and next steps. Draft wins and risks now. Pause before next steps so I can confirm the risks section reads right first.

• Sequencing sections lets you catch tone or factual issues in the earlier parts before they carry into the rest of the report.
• The pause is scoped to one section, not the whole document, so the wait is short and the ask is specific.
• This keeps a long document from being either "all approved" or "all wrong" - you get graduated checkpoints.
• Naming the exact section to pause before removes ambiguity about when Claude should stop.

6. Ask Claude to State Its Plan Before Starting

Make plan disclosure a habit, not a one-off request.

Before doing anything, list the steps you'll take and roughly how long each will take to review. Wait for my okay before step one.

• Asking for a plan and a rough sense of what each step produces helps you judge how much review time to budget.
• This makes the checkpoint explicit and expected from the very first message, rather than something you have to remember to ask for later.
• A visible plan also surfaces missing context early - if Claude's plan assumes something wrong, you catch it before any output exists.
• Reusing this phrasing across different tasks builds a consistent habit that costs almost nothing.

7. Run One Iteration of Draft, Feedback, Revision

Treat the first draft as a starting point, not the finished product.

Draft a short announcement for the new feature. I'll give feedback, then you revise.

(After the draft comes back:) Good structure, but the tone is too formal - make it more conversational and cut the second paragraph in half.

• The first message sets up a two-turn exchange rather than expecting a perfect result in one pass.
• Specific, concrete feedback ("too formal," "cut the second paragraph in half") produces a much better revision than vague notes like "make it better."
• This is the smallest unit of an iterative refinement cycle: one draft, one round of feedback, one revision.
• Treating the first output as a draft rather than a deliverable lowers the pressure on the initial prompt.

Related: Walking Through an Iterative Refinement Cycle with Claude - the full cycle across more turns

Intermediate Examples

8. Chain Outline, Draft, and Edit with a Checkpoint at Each Stage

Delegate a full writing task as three linked steps, each gated by your approval.

I need a how-to guide for setting up two-factor authentication. Step 1: outline. Step 2, after I approve the outline: full draft. Step 3, after I approve the draft: a tightened edit pass for length and clarity. Wait for my confirmation between each step.

• Naming the steps up front means Claude and you share the same mental model of what "step 2" and "step 3" mean, so there is no ambiguity mid-task about what should happen next.
• Each checkpoint only has to evaluate one kind of change - structure, then content, then polish - which is easier than reviewing all three at once.
• If you catch a structural problem at step 1, you avoid paying for a full draft and an edit pass built on the wrong outline.
• This chained pattern scales to longer documents (specs, reports, guides) without needing a single giant review at the end.

Related: Common Orchestration Patterns for Chaining Skills and Routines Together - more chaining patterns

9. Mix Full Delegation with a Tight Loop Within One Task

Decide, step by step, how much autonomy to give Claude for each part of the same task.

Research competitor pricing pages on your own and summarize the findings - I don't need to see intermediate steps for that part. But once you get to writing our positioning statement, show me a draft before finalizing anything, since that part needs my input.

• Research-and-summarize is low-stakes and reversible, so it is a reasonable candidate for full delegation without a checkpoint.
• The positioning statement carries more judgment and risk, so it gets a tight loop with a review gate.
• Telling Claude which parts get which treatment, in the same message, avoids either over-checkpointing trivial work or under-checkpointing risky work.
• This is a judgment call you make per task, not a fixed rule - the right mix depends on how reversible and how consequential each step is.

Related: When to Delegate Fully vs Keep Claude in a Tight Loop - a fuller framework for this decision

10. Catch and Correct Drift Mid-Task

Use a checkpoint to notice when Claude has wandered from the original plan, and reset it.

Before you continue, recap what you understand the goal to be and what you've done so far. I want to confirm we're still aligned before you move to the next step.

• Asking for a recap at a checkpoint is a cheap way to surface drift - cases where Claude has quietly reinterpreted the goal or skipped part of the original plan.
• If the recap reveals a mismatch, you correct it in one message instead of discovering the problem only after the final output is delivered.
• This check is most valuable in longer delegated tasks, where small misunderstandings early on can compound over several steps.
• Building this recap habit into your checkpoints is one of the simplest ways to avoid the failure modes that show up in longer delegated workflows.

Related: Failure Modes When Delegation Goes Wrong - more on drift and other breakdowns | Multi-Step Delegation & Orchestration Best Practices - a checklist to apply across all of the above

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5. Model names, pricing, and product features move quickly - verify current specifics at platform.claude.com/docs before relying on them.