An agent loop decides its next move one step at a time — great for exploring, uncomfortable when the steps are expensive or destructive. Plan-then-execute splits the work in two: first the model produces a complete plan, that plan gets validated (by a human, by rules, or by another model), and only then does execution start.

The analogy

The renovation quote. No contractor knocks down a wall and then discusses what the job will look like. They write up a quote — what will be done, in what order, at what cost — you approve it, and then the work starts. The plan is cheap to change; the wall is not.

The principle

flowchart LR
    T([task]) --> P["LLM: write the full plan"]
    P --> V{"plan validated?"}
    V -->|approved| E["execute step 1…N"]
    V -->|rejected| P
    E --> C{"reality still matches?"}
    C -->|yes| OUT([done])
    C -->|drift| P
  • The plan is a deliverable: numbered steps, files touched, commands run, expected outcome. Concrete enough to be judged.
  • Validation is a human-in-the-loop checkpoint at the cheapest possible moment — before anything happened.
  • During execution, if reality diverges from the plan (a file isn’t where expected), the right move is back to planning, not improvising.

A concrete example

A coding agent asked to migrate a database schema:

1. plan  → "① add nullable column  ② backfill in batches
            ③ add NOT NULL constraint  ④ drop old column
            — rollback plan for each step"
2. human → reads 10 lines, spots that step ④ breaks a legacy
           report, asks to keep the old column 30 days
3. agent → executes the amended plan, step by step

Thirty seconds of plan review prevented an incident — much cheaper than reviewing a 400-line diff after the fact.

When to use it

  • Steps are expensive or irreversible: migrations, deletions, bulk emails, infrastructure changes.
  • You want reviewability: a 10-line plan is easier to judge than a wall of actions in a log.
  • Several actors must agree before work starts.

When to avoid it

  • Exploratory tasks where the plan is the unknown — debugging can’t be planned in advance; use the agent loop.
  • Trivial tasks: writing a plan to rename one variable is ceremony.

The classic trap

The plan nobody re-reads at execution time. If the executor treats the plan as a vague suggestion, you’ve paid for theater. Make the plan the contract: each executed step references its plan step, and any deviation stops execution and goes back to planning.