LangChain introduced a Plan-and-Execute agent around this split: the planner creates a plan and the executor carries out each task. The pattern becomes operational when the executor can prove what happened and ask for a revised plan.
A plan is a proposed route, not permission for an executor to keep going after the world has changed.
What does the planner produce?
The planner takes a goal and available constraints, then creates steps with an intended outcome, required inputs, and a condition for completion. It may choose a worker, a tool, or a data source for each step. The plan should be visible state, not just prose hidden in a prompt. That makes it possible to inspect before an action and to resume a long run after interruption.
The planner owns the sequence and the executor owns the evidence for each step. An orchestrator-worker pattern uses a related split, especially when the orchestrator delegates independent work to several workers. A supervisor agent adds dynamic routing among specialists when the next worker depends on the state returned so far.
How does the executor stay bounded?
The executor receives one step, the context and tools needed for that step, and the required output. It should not silently redefine the goal or skip ahead to another stage. It can use a ReAct agent loop within that narrow scope. After it finishes, it returns a result, supporting evidence, and a status such as completed, blocked, or needs approval.
That contract keeps failures attributable. A malformed result is an execution problem. A plan that asked for the wrong result is a planning problem. An unapproved external action is a policy problem. Agent handoff makes the return path explicit when control moves between the planner and a specialist.
When should the system re-plan?
Re-plan when a prerequisite fails, a tool returns a condition the plan did not anticipate, the result invalidates a later step, or an approval changes the available route. A plan should be revised from observed state, not from the model’s confidence that it can continue. For a long-running workflow, save the plan and completed step evidence through durable execution so an interruption does not cause a duplicate action on retry.
The smallest useful re-plan is often one changed step, not a new plan for the entire task. That keeps stable work intact and gives an evaluator a clear before and after record.
What are the trade-offs?
Planning adds latency and can become stale. It earns its extra state on jobs with multiple dependent stages, real approval gates, expensive actions, or a need to audit the route. For a short, uncertain task, a ReAct loop that decides the next action after every observation may be faster and more adaptable.
Do not create a planner just to make an agent system look sophisticated. First ask whether the job is already a stable deterministic workflow. If it is, code the workflow and add model decisions only where the inputs genuinely vary. Then evaluate the planner, executor, and re-plan path separately on the failures the system will actually meet.