Plan and Execute

Plan-and-execute splits the loop:

1. Planner — write a short list of steps (and maybe which tool each step needs)
2. Executor — walk the list, calling tools
3. Replan (optional) — if a step fails or the world disagrees, write a new list

You still have the six parts. The planner is a model call (or a template) whose parser output is a plan, not a single action. The executor of the plan is a loop over steps; each step may still call the tool executor. Stop still caps the whole run. Memory still stores what happened — including the plan itself.

This is cheaper than ReAct when the path is obvious: research with three known sources, a refund that always needs lookup then policy then write. You pay for one planning call, then cheap steps, instead of re-deciding the next tool from scratch every turn.

It is worse when every observation can invalidate the rest of the plan: live incidents, bargaining, anything that waits on a human or another system. A plan that cannot be updated is a script. A plan you throw away after every step is ReAct with extra tokens.

When the path is obvious

A refund window check is a path:

1. Lookup the order
2. Compare days_ago to policy
3. Approve or deny

You do not need a thought at each hop if policy lives in code. The planner can emit those three steps. The executor walks them. The model should not re-invent the window as “90 days” in a thought. Policy in code is the point of this costume.

Research with three known sources is similar: fetch A, fetch B, fetch C, then write. ReAct might fetch A twice and forget C. A plan lists C.

When the world moves

Live incident: you planned “restart the box,” then the observation says the box is gone. The rest of the plan is harmful. Replan or switch to ReAct. Bargaining: the user’s new message invalidates “send the standard email.” HITL: you planned refund, the human denied — do not execute step 3.

A frozen plan dies when the world moves. That is the quiz. Use ReAct (or replan) there.

Replan is not restart

When a step fails, replan from here unless the goal changed. Keep done steps marked done. Keep the old plan in the trace. Restarting from step 1 re-runs side effects. Lookup might be safe to retry. Charge is not.

The next lesson makes the plan a list of objects with status. Here, know the control flow: planner → walk → maybe planner again, not planner → walk → throw away memory.

Policy in code, not in the model

The live box looks up an order, checks window_days in a dict, then decides. The planner did not “reason” about 30 days. The executor applied POLICY. That split is the win. If the model writes the plan as “be fair about refunds,” you are back to vibes.

The planner chooses structure. Code chooses rules. ReAct mixes them every turn. Plan-and-execute lets you mix less.

Plans are visible

Product managers can read a three-step plan. They cannot read a 40-step ReAct thought dump. Store the plan as JSON on the run record. When you replan, keep the old plan. Operators ask “what did it intend?” before “what did it think?”

UI progress is “step 2 of 3.” You cannot do that with a paragraph. Next lesson.

Cost and latency

One plan call plus N tool calls can beat N full ReAct turns if each ReAct turn restates tools and history. It can lose if you replan every step. Measure. Do not assume plan-and-execute is “more advanced” and therefore better. It is a costume for stable paths.

What this is not

This is not a multi-agent crew (planner agent, worker agents, critic agents talking). It is one runtime with a planner function and an execute-plan function. Specialists that talk to each other are the next track. You can staff a planner as a separate prompt later. You do not need a society to walk a list.

Common mistakes

• Frozen plans for live incidents.
• Policy only in the planner’s English.
• Replanning from step 1 after a write.
• No stop cap on the walk (a 40-step plan is still a furnace).
• Treating a paragraph as a plan.
• Using plan-and-execute to skip observations: each tool step still observes.

Run to execute this in your browser. Nothing is sent to a server.

The plan is data. The executor walks it. Policy lives in code, not in the model. Order 99 is 12 days ago, inside 30, so the answer is approve 40. Change days_ago in lookup_order to 90 and the same plan denies. You did not re-prompt. You changed the world.

planner ignores goal on purpose in this fake: the path is stable. A real planner would parse the goal for the order id. The id here is an argument to execute_plan. That is allowed: not every field must come from the model.

How agents use this

Store the plan as JSON on the run record. When you replan, keep the old plan in the trace. Product managers can read a plan; they cannot read a 40-step ReAct thought dump.

Pick the costume from the world: stable path → plan-and-execute; moving world → ReAct or replan. Do not pick it from a blog post about “agentic.” The next lesson types the plan so you can skip, retry, and show status.

A plan is still a loop with six parts: the planner is a model (or a template), the plan parser fail-closes, each tool step has an executor and an observation, stop still caps the walk. Do not drop observe-before-finish because a list exists. Step 3 still reads what step 1 fetched.