PTN—36
Action plans
Before executing a multi-step task, show the plan — steps, order, consequences — and let the person approve or edit it.
An approval gate reviews one action; an action plan reviews the whole campaign. When a person delegates a goal — “migrate these customers to the new membership tier,” “refactor the billing module” — the cheapest moment to catch a wrong assumption is before step one, when the correction costs a sentence instead of a rollback. The plan is where the agent’s interpretation of the request becomes visible, and interpretation is where most delegated work goes wrong. The model rarely fails at executing its plan; it fails at planning the thing you actually meant.
A plan worth approving is specific. “Update the affected records” is a vibe; “update 47 membership records, send 47 renewal emails, archive 3 expired agreements” is a plan — each step names its object and its consequence in figures, so the person can spot the step that should not be there. Vague plans are worse than no plan, because they extract an approval that authorizes nothing in particular, and the person discovers what they agreed to only after it happens.
The plan must also be an editable artifact, not a take-it-or-leave-it screen. Remove the step that is wrong, reorder the two that should swap, then run — steering at the plan level is dramatically cheaper than interrupting mid-execution or gating every micro-action. That is the pattern’s real economy: one deliberate review up front buys an uninterrupted run afterward. Approve the plan, and the agent executes the whole sequence without stopping to ask about each file write it already told you about.
Plans and gates are complements, not substitutes. The plan covers the shape of the work; per-action gates still fire on the genuinely destructive steps inside it. And a plan is a promise: if execution needs to deviate — a step fails, a new dependency appears — the agent surfaces the deviation rather than quietly improvising, because an approved plan the agent no longer follows is worse than no plan at all.
Anatomy
Assistant · proposed plan
Reassign 3 of Rivera’s Thursday jobs to Okafor
Text updated technician info to affected customers
Hold Rivera’s freed block for the Marsh Creek estimate
A proposed plan the person can audit and edit — steps, consequences in figures, and a single run control gated on the whole.
- 1Legible steps. Every step is visible and readable before anything executes — the plan is the disclosure.
- 2Stated consequences. Each step names what it touches in figures where possible — $1,140 of booked work, 3 SMS — not categories.
- 3Editable sequence. Steps can be removed or reordered before running, so review is steering, not just consent.
- 4Plan-level gate. One run control authorizes the approved sequence; execution then proceeds without per-step nagging.
When to use
- The task decomposes into multiple steps with real consequences — writes, sends, spend.
- The person delegated an outcome, not a procedure, and the interpretation needs checking.
- Steps are interdependent enough that catching a wrong assumption late means redoing everything.
- Per-action approval would fire so often that people would stop reading the gates.
Design considerations
- 01State each step’s consequence in figures — counts, names, amounts — so wrong steps are spottable at a glance.
- 02Make the plan editable in place: remove, reorder, and annotate steps before running, not just approve or cancel.
- 03Gate on the plan and then run without interruption — re-asking about steps already approved burns the value of the review.
- 04Keep destructive steps visually distinct inside the plan, and let per-action gates still fire on them during execution.
- 05Surface deviations during execution: if a step fails or the plan must change, stop and show the revised plan, never improvise silently.
- 06Scale plan ceremony to stakes — a three-step read-only task needs a one-line summary, not a review screen.
Pitfalls
- ✕Vague plans that authorize nothing: “Step 2: update the relevant records” extracts consent without disclosure, and the person learns what they approved only from the damage.
- ✕Approve-only plans — when the response to a wrong step is cancelling the whole task and re-prompting, people approve flawed plans because fixing them costs too much.
- ✕The plan as theater: the agent shows a plan, gets approval, then does something structurally different, converting the pattern into a trust liability.
- ✕Planning everything: forcing a review screen on trivial tasks trains people to click through plans, which spends the attention the consequential plan needed.
In the wild
- Claude Code
- Plan mode has the agent research and present a step-by-step plan for approval before it may edit any file — the person reviews the approach, not just the diffs.
- ChatGPT
- Deep research asks clarifying questions, then states the research plan it intends to run before spending minutes of autonomous browsing on it.
- Replit Agent
- Turns an app request into an explicit build plan the person confirms or adjusts before the agent starts generating the project.