Planning

Read these first

• The agent loop implemented from scratch

What you will know

• Have an agent produce a plan before acting

  The artifact gives logs and reviewers a target for spotting impossible or unsafe steps before side effects occur.

• Compare upfront planning against interleaved reasoning on a real task

  Use the same task variants and record success, tool calls, latency, and token use so the tradeoff is observable rather than intuitive.

• Trigger a replan on failure rather than retrying blindly

  A failed tool call or violated precondition should update the proposed path, not merely repeat the same action with new wording.

• Break a multi-step task into dependencies, success criteria, and recovery points

  Explicit ordering and exit conditions expose missing prerequisites and make partial progress recoverable after an interruption.

• Measure planning overhead and task quality across short and long tasks, then set a routing rule

  The useful boundary depends on plan-generation latency and tokens versus the reduction in failed actions, not on task length alone.

Chapters

1. 1

   Planning upfront and reasoning between steps differ mechanically

   One produces the whole path before the first tool call and then carries it in context for every later turn; the other decides each step from what the last one returned. Name the difference in those terms rather than in terms of which sounds more competent. Then take one task where committing early is clearly right — an irreversible or expensive first action — and one where it is clearly wrong.

   Read chapter
2. 2

   A plan is an object a reviewer can read before anything happens

   Making the agent emit its intended steps before it acts produces something logs, humans and automated checks can inspect while the side effects are still avoidable. That is the operational payoff, and it is separate from any claim that planning makes the model smarter. Covered here: where the artifact goes, what it must contain to be checkable, and what an impossible or unsafe step looks like on paper.

   Read chapter
3. 3

   Dependencies, success criteria and recovery points make a plan

   A list of steps is not a plan. Breaking a multi-step task into ordered dependencies, an explicit success criterion per step and named recovery points is what exposes a missing prerequisite before the run and makes partial progress resumable after an interruption. Work an example where the ordering constraint is implicit in the prose and stays invisible until the third step fails on it.

   Read chapter
4. 4

   A plan followed without re-validation is a chain written at runtime

   At step three the agent discovers that the file the plan assumed exists was deleted, and the executor proceeds to step four anyway. The architectural fault is not the model's plan but the absence of any check of the plan against observations. You end up with the rigidity of a fixed control flow and none of its testability, because the graph was authored fresh for this run and nobody can test it.

   Read chapter
5. 5

   A stale step is only caught by a check that runs before it

   Nothing failed when the deleted file went unnoticed: step three completed and step four ran. Catching that needs a runtime that re-reads each step's declared preconditions and success criteria against current observations immediately before executing it, which is what finally gives the recovery points of the earlier chapter something that consults them. Decide what a failed check does — skip the step, trigger a replan, or halt and hand back — and where the check draws its observations from, because a check that reads the plan's own assumptions rather than the world is not a check.

   Read chapter
6. 6

   Replanning changes the path; retrying repeats the same action

   A tool call fails on an unmet precondition. Rewording the same call is a retry; choosing a different tool, a different order, or satisfying the prerequisite first is a replan, and only the second responds to what was learned. Then handle the failure that appears two weeks later, where runs replan six times and never finish. Capping replans at two hides the question, so the rule is convergence instead: every replan must be conditioned on information the previous attempt did not have, two consecutive plans that are the same means the run is terminal, a repeated failure signature is the trigger rather than a count, and replans draw on the same wall-clock and token budget as everything else.

   Read chapter
7. 7

   The routing rule comes from plan cost against failures avoided

   Run the same task variants both ways and record success, tool calls, latency and tokens, because that is the only comparison that settles it. Then compute the real number: 1,200 tokens and three seconds of plan generation, resident in context for every later turn, against the measured reduction in failed actions on a median four-step task. What comes out is a routing rule, not a preference about task length.

   Read chapter