ReAct vs Plan-and-Execute: AI Agent Reasoning Patterns

You wired up an agent, gave it tools, and now you are staring at two names that keep getting used as if they were the same thing. Most posts blur ReAct and Plan-and-Execute into one fuzzy idea. ReAct vs Plan-and-Execute is not a style choice; they are two different control loops for an agent, and the split decides how it thinks, how much it costs, and how it fails.

What is the difference between ReAct and Plan-and-Execute?#

The react vs plan and execute difference is timing. ReAct interleaves reasoning and acting one step at a time, choosing each next action only after seeing the last result. Plan-and-Execute writes the whole multi-step plan up front, then runs the steps in order, re-planning only when a step fails or the plan runs out.

ReAct decides the next step only after reading each observation. The loop repeats until the model answers or hits a cap.

ReAct comes from Yao et al. 2022 (arXiv:2210.03629), short for Reasoning and Acting. The loop is a repeated Thought, Action, Observation cycle. Plan-and-Execute is the pattern documented in the LangGraph agent guides, where a planner model drafts every step first and an executor works the list. Same tools, same model, two very different shapes of thinking.

The reason people conflate them is that both are usually implemented on top of tool calling, so from the outside an agent looks like a black box that calls tools and returns an answer either way. The give-away is where the branching lives. In ReAct the branch is inside every turn: the model can change direction after any observation. In Plan-and-Execute the branch is rare and explicit: the plan holds until something forces a re-plan. Keep that distinction and most of the confusion in the surrounding write-ups falls away.

How does the ReAct loop actually work?#

ReAct runs one decision at a time. The model writes a Thought about what it needs, picks an Action such as a tool call, then reads the Observation the tool returns. That observation feeds the next Thought. The loop repeats until the model decides it has an answer or hits a cap.

That interleaving is the whole point. Because the agent sees each result before choosing the next move, it adapts to surprises: a failed search, an empty database row, a number it did not expect. This is why ReAct suits open-ended tasks where you cannot know step 4 until step 3 returns. If you are new to how a single agent decides between reasoning and calling a tool, the split we cover in AI Agent vs Chain in n8n is the same idea one level down.

The cost is real. Every cycle sends the growing transcript back to the model, so a 7-step task means 7 reasoning passes over an ever-longer context, and token spend climbs with each loop. Worse, a confused agent can circle the same 2 or 3 actions forever, which is why every serious ReAct setup ships a max-iterations cap.

There is a subtler failure than the infinite loop. Because the agent only ever sees the transcript so far, a bad early observation can quietly poison every later Thought. A stale search result or a mis-parsed row becomes the ground truth the agent reasons from, and it will confidently build 4 more steps on a wrong foundation. ReAct does not detect this on its own. That is why logging every Thought, Action, and Observation is not optional: when a run goes sideways, the transcript is the only place the drift is visible. The paper's own framing is that reasoning traces help the model track and update its plan, but that same trace is what you read back when it goes wrong.

What is the Plan-and-Execute pattern?#

Plan-and-Execute front-loads the thinking. A planner model reads the goal once and emits an ordered list of steps. An executor then runs each step, often with cheaper or tool-specific calls, and a re-planner revisits the list only when a step fails or new facts change the goal. The heavy reasoning happens a single time, not on every action.

The heavy reasoning happens once, up front. Re-planning is a deliberate checkpoint, not per-step adaptation.

The upshot is fewer reasoning-level model calls and a plan you can read before anything runs, which makes behavior more predictable and easier to audit. The trade is brittleness: a plan written at step 0 can be wrong by step 3 if the world moved underneath it. Good implementations add an explicit re-plan step, but that re-plan is a deliberate checkpoint, not the automatic per-step adaptation you get free in ReAct.

There is also a cost split worth naming. The planner call is the expensive one, because it reasons over the whole goal at once, but you pay it a single time rather than on every action. The executor steps can then run on a cheaper model, or even on plain tool calls with no reasoning at all, since the thinking already happened. That separation is the real economic pitch of the pattern: concentrate the reasoning spend in 1 place, then execute cheaply. It only holds if the plan survives contact with reality, which is exactly what the re-plan step is insurance against.

ReAct vs Plan-and-Execute: which trade-offs matter?#

Judge the two loops on 5 axes: adaptivity, token and cost, latency, predictability, and typical failure mode. ReAct wins adaptivity and loses on cost and predictability. Plan-and-Execute wins predictability and cost on the reasoning side but loses adaptivity mid-run. The table below lays out the same rows side by side.

These are tendencies, not laws: a tightly capped ReAct agent can be cheap, and an aggressive re-planner can be adaptive.

Notice these are tendencies, not laws. A ReAct agent with a tight cap and good tools can be cheap; a Plan-and-Execute agent that re-plans aggressively can approach ReAct's adaptivity at ReAct's cost. Hybrids exist precisely because the clean split blurs once you tune either loop. Treat the axes as a starting map, then measure your own workload.

The failure-mode row is the one most people skip, and it is the most useful. When a ReAct agent breaks, it usually breaks loud: it loops, or it burns through the iteration cap without an answer, and you notice. When a Plan-and-Execute agent breaks, it often breaks quiet: it marches confidently through a plan that stopped matching reality 2 steps ago and hands back a tidy, wrong result. Loud failures cost tokens; quiet failures cost trust. Knowing which kind of wrong each loop tends toward tells you what to monitor and where to put the human check.

How does this map to n8n and LangGraph agents?#

The two loops show up directly in the tools you already use. n8n's AI Agent node runs a tool-calling ReAct-style loop with a Max Iterations setting that caps the cycle. A Plan-and-Execute shape in n8n looks more like a dedicated planner model whose output drives sub-workflows, one per step. LangGraph ships both as reference graphs.

In n8n, the AI Agent node is the ReAct end: it thinks, calls a connected tool, reads the result, and repeats until it answers or hits the iteration cap you set. Wiring those tools is its own skill, covered in how to give an n8n AI Agent tools. The Plan-and-Execute shape is closer to a planner node that emits a step list, then a loop that runs each step, an arrangement that starts to resemble multi-agent orchestration in n8n once each step gets its own specialized worker.

LangGraph documents both patterns as explicit graphs. The LangGraph how-to guides include a plan-and-execute example with a planner node, an executor node, and a re-plan edge, alongside the tool-calling ReAct agent as the default. Reading both graphs side by side is the fastest way to feel the difference in code rather than in prose.

Which agent reasoning pattern should you use?#

Default to ReAct when the task is open-ended and each step depends on the last result, and reach for Plan-and-Execute when the steps are known up front and you want predictable, auditable, cheaper reasoning. Most production systems end up hybrid: a plan for the skeleton, a ReAct-style loop inside any step that needs to adapt.

Start from whether the steps are known up front; every path ends at cap it, log it, and measure on real tasks.

Start with the loop that matches your task's shape, cap and log it, then measure. If a ReAct agent burns tokens looping, add a plan. If a Plan-and-Execute agent keeps following stale plans, loosen it toward per-step adaptation. The names are less important than the one question underneath both: when should this agent be allowed to change its mind?

The honest closing note is that neither pattern is a 2026 upgrade over the other. ReAct is from 2022 and is still the sensible default for exploratory tool use; Plan-and-Execute is the sensible default when the work is a known checklist and cost or auditability matters more than adaptivity. What changed over the last few years is not the loops but the models running inside them, which are far better at both planning and self-correction than the ones the original ReAct work was tested on. Pick the loop for your task, instrument it, and let the measurements, not the label, decide whether to switch.