Plan, Then Act

Plan, then act

In the last lesson you turned a goal into an ordered list of subtasks. The tempting next move is to interleave thinking and doing: decide one step, run it, look around, decide the next. That reactive loop feels efficient, but it has a nasty property — nobody can see the whole route until it's already half-executed. If the third action is wrong, you only find out after the first two already touched the world. You can't review a plan that doesn't exist yet.

Plan-execute splits the work cleanly in two. First the agent builds the complete plan — the full list of actions — without moving anything. Then a separate phase runs that fixed plan against the world state, one action at a time. The payoff: the plan becomes a concrete artifact you can inspect, log, cost-estimate, or hand to a human for approval before any irreversible thing happens. An agent about to send emails or spend money should show its route first.

Think of a robot on a number line, start 0, goal 4. The plan phase emits ["right","right","right","right"] — four actions derived purely from goal - start, with the robot still at 0. Only then does execution walk it: pos goes 1, 2, 3, 4, and you can verify the printed plan matches what actually happened. If they ever diverge, you have a bug you can see.

The starter leaves plan empty and the robot never moves. Fill the plan first — push one "right" for every step from start to goal — print it, then let the execute loop run it. Done means the printed plan has four rights and the final line reads pos=4, landing exactly on the goal.