I have shipped agents that froze halfway through a task and agents that confidently reported success on work they never did. Two opposite failures. Both traced back to the same root cause: I had picked the wrong control loop for the job. Not the wrong model, not the wrong prompt. The wrong fundamental architecture for how the agent decides what to do next.
There are really two schools, and most production agents are some blend. Get the blend wrong and you ship something that stalls, loops, or hallucinates its own progress. Get it right and the same model suddenly looks reliable. So let me lay out the two honestly, including where each one bites.
The two loops
ReAct is the reactive loop. Think, act, observe, repeat. The model takes one step, sees the result, and decides the next step from there. It does not commit to a plan up front. It feels its way forward, one tool call at a time, conditioning each move on what actually came back.
Plan-then-execute is the deliberate loop. The model writes the whole plan first, a list of steps, then executes them in order, optionally re-planning if something breaks. The plan is an explicit artifact you can inspect, log, and gate before a single side effect happens.
The difference sounds academic until you watch them fail.
Where ReAct shines and where it rots
ReAct is the right call when the environment is unpredictable and each observation genuinely changes what you should do next. On HANNA, my cold-call voice agent, there is no point planning turn four of a conversation when you don’t know what the human will say on turn one. The whole task is reactive by nature. You say something, you listen, you adjust. A pre-written plan would be theater.
ReAct is also forgiving to build. You don’t need to design a plan schema or a re-planning trigger. You loop: feed the model the history, let it call a tool, append the result, loop again. For exploratory tasks where you can’t enumerate the steps in advance, it is the natural fit.
The rot shows up in three ways.
First, looping. Because each step is decided locally, the agent has no memory of strategy, only of history. I have watched a ReAct agent call search, not find what it wanted, call search again with a trivially different query, fail, and do it a third time. It is locally rational every step and globally stuck. Nothing in the loop says “you already tried this family of moves.”
Second, drift. With no plan to anchor against, a long ReAct trajectory slowly forgets the original goal. By step fifteen the agent is solving a subproblem it invented at step nine, and the user’s actual request has fallen out of attention. This is partly a context problem, and tighter state handling helps, but the loop structure invites it.
Third, no inspection point. The agent is already taking actions before you know what it intends. If those actions touch production, you find out it was wrong after it has already sent the email or updated the record.
Where plan-then-execute shines and where it rots
Planning is the right call when the task has structure you can see in advance and side effects you cannot take back. When I built a voice-driven ordering pipeline — running across a realtime voice/telephony provider, a payments API, a scheduling API, and a workflow-automation engine — the spine of it is a plan: capture the order, price it, charge the card, book the slot, confirm. Those steps have a fixed shape. Charging before pricing is not creative, it is a bug. Writing the plan as an explicit artifact lets me validate it before money moves.
The biggest win is the inspection point. A plan is a checkpoint. I can show it to a human, gate the irreversible steps, log it for the post-mortem when something goes wrong. Autonomy is a cost, not a feature, and a plan is where you decide how much of that cost to pay before anything irreversible happens.
A plan you can read before execution is the cheapest insurance you will ever buy against an agent doing the wrong thing confidently.
The rot here is subtler and more dangerous: hallucinated progress. A pure plan-then-execute agent writes five steps, then marches through them reporting each as done, even when step two actually failed and it never noticed. The plan becomes a script the model performs rather than a strategy it adapts. You get a clean log that says everything succeeded and a system that did half the work. I find this failure scarier than looping, because looping is loud and this is silent.
The other cost is brittleness. Plan up front and the first surprise breaks you. The world rarely matches the plan exactly. If you don’t build a re-planning path, the agent either crashes or, worse, plows ahead pretending the plan still holds.
The honest comparison
| Dimension | ReAct | Plan-then-execute |
|---|---|---|
| Best for | unpredictable, exploratory tasks | structured tasks with known shape |
| Inspection before side effects | none | the plan is your checkpoint |
| Characteristic failure | looping, goal drift | hallucinated progress, brittleness |
| Re-planning cost | implicit, every step | must be designed in explicitly |
| Latency / token profile | many small steps add up | fewer, fatter reasoning bursts |
| Gating irreversible actions | hard, actions happen mid-loop | natural, gate the plan |
Notice the failure rows are near-opposites. ReAct fails by never committing. Planning fails by over-committing. That symmetry is the whole insight.
What I actually ship: a plan with a reactive inner loop
Neither pure form survives contact with a real workload, so I build a hybrid, and the structure matters.
The outer loop is a plan. The agent decomposes the task into a small number of checkpointed steps, and I gate the irreversible ones. The inner loop, inside each step, is ReAct. Within “qualify this lead,” the agent can think, call a tool, observe, and adjust freely, because that sub-task genuinely is exploratory. The plan keeps it anchored to the goal. The reactive inner loop keeps it from being brittle.
The glue between them is a re-plan trigger. After each step I have the agent answer a blunt question against the actual observed result, not against its own narration:
Did this step achieve its stated goal? (yes / no / partial)
If no or partial: does the remaining plan still make sense,
or do we re-plan from here?That single check is what kills hallucinated progress. The agent cannot mark a step done just because it executed; it has to look at the result and judge. And it kills looping too, because the outer plan gives the inner loop a budget and a definition of done that pure ReAct never has. This plan-outer, react-inner shape is the default control loop I’m building into Vontra, the AI-native business operating system, precisely because its agents touch invoices and records and cannot be allowed to wander.
A heuristic for choosing
When I scope a new agent I ask three questions before I write any code:
- Can I enumerate the steps in advance? If yes, lean planning. If the steps depend on what I observe, lean reactive.
- Are there irreversible side effects? If yes, I want a plan as a gate, even if the inner work is reactive. Sending money, sending email, deleting data — those want a checkpoint.
- How long is the trajectory? Short tasks tolerate pure ReAct. Long ones drift without a plan to anchor them.
Most real work answers “some steps known, some discovered, yes there are side effects, and it’s long.” That answer is the hybrid. Which is why I almost never ship either school in its pure form.
The reason this is the highest-order decision is that it constrains everything downstream. It decides where your inspection points are, which shapes how you gate irreversible actions. It decides how state flows between steps, which is its own discipline. It decides your latency and token profile, because a forty-step ReAct loop and a five-step plan cost wildly different amounts. Pick the loop first. Then design the tools, the context, and the budgets around it. I have tried to do it in the other order, bolting a control structure onto an agent I’d already built, and it never fits. The loop is the skeleton. Everything else is muscle hung on it.