The agent loop guide earlier in this series covered plan-act-observe as a single shape. In practice, there are a few genuinely different ways to structure that reasoning, and picking the wrong one for a given task is a common reason agents feel unreliable even when the tools and prompts are otherwise solid.
ReAct: interleaved reasoning and acting
ReAct (Reasoning + Acting) is the pattern this series has assumed by default: the model reasons about one step, takes one action, observes the result, and reasons about the next step - reasoning and acting are tightly interleaved, one step at a time. Its strength is responsiveness: because the model re-plans after every single observation, it adapts quickly when something unexpected comes back from a tool. Its weakness is that it can be short-sighted - deciding each step in isolation sometimes misses a better multi-step strategy that would have been obvious if planned out in advance.
Plan-and-execute: commit to a plan, then work through it
Plan-and-execute splits the two phases apart: the model first produces a multi-step plan for the entire task, then executes that plan step by step, only replanning if something goes wrong. This trades ReAct's responsiveness for more coherent, deliberate multi-step reasoning - a model asked to plan the whole task up front often produces a more sensible strategy than one deciding purely one step at a time. The cost is that a plan made with incomplete information can turn out wrong partway through, and a good plan-and-execute implementation needs a real mechanism for detecting that and replanning, not just blindly executing a stale plan.
ReAct re-plans after every step. Plan-and-execute commits to a full plan and works through it, replanning only when it has to.
Reflection: self-critique before finishing
Reflection adds a distinct step after the model produces a result: before returning it, the model (or a separate reflection pass) evaluates its own output against the original goal and either accepts it or revises it. This catches a category of error neither ReAct nor plan-and-execute address on their own - a technically successful sequence of tool calls that nonetheless produces an answer that doesn't actually satisfy what was asked. Reflection is commonly layered on top of either of the other two patterns rather than used alone; it's an added quality check, not a replacement for the underlying loop structure.
These aren't mutually exclusive
Real production agents frequently combine patterns - a plan-and-execute agent whose individual steps are themselves small ReAct loops, with a reflection pass at the very end before returning to the user. Treat these as a vocabulary for describing what an agent is doing, not a menu where you pick exactly one and never mix.