- 1Final answer is assembled from completed sub-task results
- 2Executor handles the first sub-task and returns a result
- 3Planner optionally revises the remaining plan based on new observations
- 4Executor handles subsequent sub-tasks using prior results
- 5Planner LLM call: decompose the task into an ordered list of sub-tasks
- 6Receive the user's high level task
Plan and execute receives the goal, plans the whole task up front into ordered sub-tasks, executes each one, replans only when an observation invalidates the plan, then assembles the final answer.
Imagine planning a road trip before you leave. You sit down with a map and write out every stop in order: gas station, lunch town, the hotel, the beach. That whole list is your plan, made before the car even moves. Then you drive, ticking off each stop one by one. Most of the time you just follow the list. But if you hit a closed road, you pull over and redraw the rest of the route, keeping the stops you have already made. You do not replan the entire trip after every single stop, only when something surprising forces you to. When the last stop is done, you have arrived. A plan and execute agent works the same way: it thinks through the whole journey first, then walks the steps, and only redraws the map when reality breaks the plan.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
plan and execute is an agent control pattern that separates a single up front planning phase from a sequence of execution steps. A planner model reads the user's high level goal and decomposes it into an ordered list of sub-tasks in one call. An executor then walks that list, handling each sub-task in turn and reusing earlier results. The plan is revised only when an observation makes the existing plan wrong, and the run ends by assembling the sub-task results into a single answer.
The whole question of this pattern is ordering. The phases are not interchangeable, and the value of the architecture comes entirely from where each phase sits. Planning happens before execution, not interleaved with it. Replanning happens after execution begins and only on a trigger. Assembly happens last. Get the order wrong and you either have no plan to execute or you have rebuilt a different pattern entirely.
The pattern emerged as a direct response to the weaknesses of purely reactive agents. A reactive agent decides its next move one step at a time, which is flexible but expensive and prone to losing the thread on long horizons. Plan and execute answers that by committing the model to an explicit, ordered plan early, so the rest of the run has a backbone to follow. Understanding the order of its phases is really understanding why that backbone is worth having.
Why planning comes first, and only once
The first two phases are fixed by necessity. The agent receives the user's high level task, then a planner model decomposes that task into an ordered list of sub-tasks. Execution cannot start before this, because there is nothing to execute until the plan exists. The plan is the output that makes the rest of the run possible, and the ordering of these first two phases is the one part of the sequence nobody disputes.
The deeper reason planning sits up front is economic. A planner is typically a strong, expensive model doing the hard reasoning of breaking a goal into steps. By doing that once, you pay the expensive reasoning a single time. The executor that runs the steps can then be a cheaper or faster model, because the difficult decomposition is already done. In a long task this gap compounds: a single planner call followed by many cheap executor calls costs far less than invoking a top tier model on every turn.
There is a second, quieter benefit. The plan is an artefact you can read. Because it is generated in one place and written down before any side effects occur, an operator can inspect it, log it, diff it against later revisions, and even gate execution behind human approval. A reactive agent that decides as it goes leaves no such artefact, so you cannot review its intentions before it acts.
This is the core contrast with a reactive loop. In ReAct, the model reasons about the next action on every single turn. Plan and execute pulls that reasoning out of the loop and front loads it, trading per-step adaptivity for a cheaper, more inspectable run. The order, plan first then execute, is precisely what buys both the cost saving and the inspectable plan.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- LangGraph ships a plan-and-execute reference agent where a planner node emits an ordered task list and an executor node walks it, looping back to the planner only on a replan signal.
- BabyAGI popularised the task list then execute shape: a planner generates sub-tasks, an executor runs them, and new observations can rewrite the remaining queue.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhat signal should trigger a replan, and how do you avoid replanning on every step?
Gate replanning on a concrete trigger, a tool error, an assumption violating observation, or out of bounds data, rather than on a step counter. Have the executor flag plan invalidating results so the planner is called only when the remaining plan is actually wrong.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Replanning after every single step. That collapses plan and execute into a step by step ReAct loop and throws away the cost savings of generating the plan once.
60 second bullets to scan on the way to the call.
Identify which phase produces the ordered list of sub-tasks and what its input is.
Explain why the planner runs before any executor work begins.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.