Planning in Agents: Goals to Steps

A goal is not a plan. Planning in agents turns one distant goal into ordered steps with checks, works them top to bottom, and replans the rest when a step fails.

One six-step trip plan totals 1200 plus 1600 plus 400 to 3200 against a 3500 budget, then a sold-out hotel triggers one replan to land at 3100.

Why Does This Exist?

Complex goals never fit one call. A ten-day Japan trip under $5000 needs flights, hotels, and activities in order, with bookings that sell out mid-run. A research report needs sources gathered, themes found, and sections drafted, with dead ends along the way. Ask for all of it at once and the agent improvises: it skips constraints, invents bookings, and polishes the wrong plan.

Planning bridges that gap. It turns one goal into a short list of executable steps with checks, runs them in order, and revises the remainder when the world disagrees. Without it the agent only reacts. With it the agent stays coherent across a morning of tool calls.

This page covers the two orders and the replan. Distant goals with checkpoints live in long-horizon planning. Breaking goals into pieces lives in task decomposition. The step loop inside each step lives in ReAct, and what the run remembers lives in memory systems in agents.

Basics first: the model writes the next token from the tokens before it, so written steps become working memory it can reread. If that is new, everything below still follows, but the loop reads cleaner once you know that writing more of the right tokens is how the model thinks longer.

Think of It Like This

A chess player with a scoresheet, not just sharp eyes

A weak player stares at the board and moves the threatened queen. Fast, and blind to the fork two moves later. A strong player writes a short line first: develop, castle, press the weak pawn. Each move then serves the line, and when the opponent surprises them they cross out the rest and write a new line from the current board.

The written line is the plan. Each move is an execution step. Crossing out the rest is replanning. The scoresheet matters because memory lies under pressure, and the board after move twelve never matches the board imagined at move one.

Where it stops: chess pieces move exactly as written and the opponent moves on turn. Agent tools time out, return junk, and act in the world before failing. A chess line never books a nonrefundable room while thinking, but an agent plan can, which is why checks must gate outside effects.

How It Actually Works

Call the goal $G$ , which means the distant outcome. Call the steps $s_1$ through $s_n$ : ordered, executable, each with a done rule. Call the observation $o_i$ : the tool result after running $s_i$ . Two orders cover nearly every production agent.

Plan first, then execute in order

The planner writes $s_1$ through $s_n$ before any tool runs. The executor works top to bottom, comparing each $o_i$ against its check. On success it continues. On failure it stops and the planner rewrites only $s_{i+1}$ through $s_n$ from the current state. Finished steps never rerun. This is the PLAN, EXECUTE, EVALUATE, REPLAN circle, and it shines when steps have ordering constraints or the job runs past about ten steps.

Decide one step at a time

The interleaved order skips the upfront plan. The agent reads the goal plus all past steps and observations, writes one thought, calls one tool, reads the result, and repeats. That loop lives in ReAct. It adapts the moment a search returns nothing, at the price of one model call per step and a lengthening prompt. Pick it when each step depends on the last result. Pick plan-first when coherence across many steps matters more.

Worked example: one trip, one replan

The goal $G$ is a short trip under a $3500 budget. Three costs carry it: flights 1200, hotel 1600, and food 400. Add them: $1200 + 1600 = 2800$ , then $2800 + 400 = 3200$ . The buffer is $3500 - 3200 = 300$ , so the plan passes and the diagram draws exactly this run. Six steps carry those costs: two to book flights, two for the hotel, two for food.

Under plan-first, the planner writes all six, the executor runs them, and then the hotel sells out. The only room costs 1900, which pushes the total to $1200 + 1900 + 400 = 3500$ , exactly at budget with zero buffer. The watcher flags it, the planner swaps in a 1500 hotel, and the new total is $1200 + 1500 + 400 = 3100$ , leaving a $3500 - 3100 = 400$ buffer. Four steps ran, one replan fixed the rest.

The trade is now concrete. Planning pays one call upfront and holds long tasks together, but risks a stale first draft. Interleaving adapts without that upfront cost and risks wandering. Both assume the toolbox is fixed and observations arrive as short readable text.

Code

The point here is the stop rule and the one replan, not the arithmetic. This stdlib-only sketch runs the same trip numbers through a capped loop plus a grounded replan:

1def trip_total(flights: int, hotel: int, food: int) -> int:2    return flights + hotel + food3
4
5base = trip_total(1200, 1600, 400)6print(base)  # -> 32007print(3500 - base)  # -> 3008print(trip_total(1200, 1900, 400))  # -> 35009print(trip_total(1200, 1500, 400))  # -> 3100

Four outputs match the worked example: 3200 with a 300 buffer, the 3500 sold-out total, and the 3100 replanned landing. In production the same totals gate real bookings instead of integers.

Watch Out For

A twenty-step plan for a three-step task

The symptom is a simple question that returns late and wrong. The planner wrote research, compare, draft, review, and format for a lookup that needed one search, so tokens burn, failure points multiply, and the executor drifts between steps that never needed to exist.

Fix it by calibrating granularity to the task. Decide with a light rule whether to decompose at all, keep steps near one tool call each, and prefer the interleaved loop from ReAct when one lookup answers the question.

Steps that name tools you never built

The symptom is a beautiful plan that dies on step one: check visa rules via the visa API, when no visa tool exists. The planner wrote what sounded logical, not what your toolbox contains.

Fix it by pasting the tool list with one-line descriptions into the planner prompt, and by rejecting any step that names an unknown tool before executing anything. Ground the plan first, then run it.

The Quick Version

Planning turns one goal into ordered steps with checks, then works them top to bottom and replans the rest on failure.
Plan-first suits long tasks with ordering constraints, while interleaved steps suit jobs where each move depends on the last result.
Flights 1200 plus hotel 1600 plus food 400 total 3200 against a 3500 budget, leaving a 300 buffer.
A sold-out 1900 hotel pushes the total to 3500 with zero buffer, and one replan to a 1500 hotel lands at 3100.
Twenty steps for a three-step task waste tokens and add drift, so calibrate granularity first.
Planners must see the real tool list, or they schedule tools that do not exist.