Plan and execute wins when a task has many branching steps, where ReAct drifts off goal as accumulated observations pile up. An upfront plan keeps the executor anchored.
Imagine cooking a five-course dinner. ReAct is like deciding each dish only after you finish the last one, with no menu. By dish four you have forgotten you wanted a light meal, because the kitchen is full of distractions. Plan and execute is like writing the full menu first, then cooking each course while just glancing at the list. The list keeps you on track even when something burns. The trade-off: if a guest suddenly arrives with an allergy, the fixed menu is now wrong and you have to rewrite it. So a written plan helps most on long, complicated dinners where staying on goal is the hard part, and helps least on a quick snack you could make without thinking.
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.
This question asks you to pick the regime where plan and execute beats vanilla ReAct, and the discriminating detail is the failure mode, not the surface size of the task. The correct option is the one about many branching steps where mid-task drift is the primary way the agent fails. The trap is to reach for the speed answer or the context-window answer, both of which sound plausible and both of which get the mechanism backwards.
Both patterns are ways of structuring the agent loop, the cycle where a model observes state, reasons, acts through a tool, observes the result, and repeats. They differ in when and how planning happens. ReAct plans implicitly, one step at a time, deciding the next move only after seeing the last result. Plan and execute plans explicitly and up front, committing to an ordered task list before any tool runs. That single structural choice changes how each pattern behaves as a task gets longer, and it is the heart of the answer.
The useful way to hold this in your head is that the two patterns trade adaptivity against stability. ReAct buys maximum adaptivity and pays with fragile long horizon focus. Plan and execute buys stable long horizon focus and pays with brittleness when reality diverges from the plan. The interview grade answer names that tradeoff explicitly and then says which side of it the question's scenario lands on.
How ReAct actually decides each step
ReAct interleaves reasoning and acting in a single loop. On every turn the model receives the full running transcript, the original goal plus every prior action and observation, writes a short reasoning trace, and then emits one tool call. The result is appended, and the cycle repeats.
This tight coupling between the transcript and the next action is exactly what makes ReAct adaptive. If a tool returns something unexpected, the very next reasoning step sees it and can pivot immediately. There is no stale plan to fight against, so ReAct handles novelty and surprise gracefully.
The cost of that coupling shows up on long horizons. The transcript only grows, and every observation in it is attention surface that competes with the original instruction. By the twentieth turn the goal is a tiny fraction of the context, while ten kilobytes of recent tool output sit right next to the prompt. The model starts optimising for whatever the last observation emphasised rather than the task it was given. That slow slide off target is what practitioners call drift, and it is the dominant failure mode of long ReAct runs.
Drift compounds with two other long-run pathologies. The first is the cascading error rate: if each step succeeds with probability around ninety percent, a twenty-step chain succeeds end to end only about one time in eight, because the per-step failures multiply. The second is context pollution, where a single malformed tool result or a misread error gets re-read on every subsequent turn and quietly poisons later reasoning. ReAct has no structural defence against either, because it carries the entire history forward and re-derives intent from it each turn. The longer and more branched the task, the more these effects dominate, which is exactly the scenario the correct option describes.
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 template where a planner node writes a step list and an executor node consumes it, with an explicit edge back to the planner for replanning.
- BabyAGI popularised the task list loop: an LLM generates a queue of tasks up front, then works the queue, prepending new tasks when results demand it.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you detect that an executor's plan has gone stale and a replan is needed?
Compare each observation against the plan's preconditions for the next step. If an assumption is violated, an error appears, or progress stalls, route back to the planner to regenerate the remaining tail rather than the whole plan.
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.
Picking plan and execute for speed. It usually adds a planning call, so it is not faster. Its real win is goal stability on long branching tasks, not lower latency.
60 second bullets to scan on the way to the call.
State the core difference between interleaved reasoning and upfront planning.
Explain why accumulated observations cause drift in long ReAct runs.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.