ReAct, Plan-Execute, Reflexion

At 3:07 a.m., a customer-support agent receives: “Please refund order 1842.”

The order lookup says the purchase was delivered 44 days ago. The normal refund window is 30 days. A support note, found only after searching the ticket system, says a manager approved an exception through September 2. The refund tool then reports that the original payment method is unavailable, so the system must offer store credit instead.

The job is not “produce a plausible answer.” It is “find the relevant facts, respond to what those facts reveal, and avoid promising money that cannot be returned.”

An agent can decide one action at a time, write a complete plan first, or try an answer, inspect it, and repair it. These are reasoning loops: control patterns that decide what the agent does next and when it stops.

The design-patterns lesson covered larger workflow shapes such as prompt chaining, routing, and parallelization. A reasoning loop is the local control system inside that workflow.

Three loops appear again and again:

• ReAct, which interleaves reasoning, tool use, and observation.
• Plan-and-Execute, which plans first and carries out the steps afterward.
• Reflexion, which turns task feedback into verbal self-reflection, stores it, and conditions a retry on that reflection.

They answer one engineering question:

Should the next decision come from the latest observation, from a plan written earlier, or from a failed attempt plus a critique?

The shared mental model

A state is what the agent currently carries: the request, order details, tool results, approvals, and remaining budget. An observation is new information from a tool or evaluator. An action is a tool call or answer. A precondition is a fact required before an action is allowed. A termination condition says the loop is finished.

The model does not directly refund a customer. An orchestrator sends it the current state, receives a proposed action, validates it, runs the tool if allowed, and appends the result. The loop determines whether to stop, retry, re-plan, or continue.

“I believe the exception applies” is not an approval. The approval record in ticket 7719 is.

ReAct: decide after every observation

ReAct means Reason plus Act. The agent chooses one useful action, observes what happened, and chooses again. Its defining property is timing: the latest observation reaches the next decision.

For order 1842, a ReAct trace is:

1. Call lookup_order; it returns “delivered 44 days ago, value $89.”
2. Because the date conflicts with the normal 30-day window, call the policy lookup.
3. The policy allows manager exceptions, so search the support ticket.
4. Ticket 7719 contains approval through September 2. Verify the amount, repayment method, and approval status, then call the payment-status tool.
5. The original card token is closed. Offer store credit or request human approval instead of claiming that $89 was returned.

Each result narrows the next decision. The agent did not need to enumerate the exception branch at step one; it discovered the relevant facts as it worked. That makes ReAct effective in an open world, where the information needed for later actions is unknown initially.

The cost follows the number of decisions. Five model decisions usually mean roughly five model calls, plus tool calls. Long investigations become slow and expensive, and without a progress or stopping rule the agent can repeat searches.

Use ReAct when the next tool depends on live results, the environment changes, or several plausible routes are selected by early facts. For a fixed sequence that deterministic code can perform, it adds unnecessary uncertainty.

Plan-and-Execute: commit early, then carry out

Plan-and-Execute separates a planner from an executor. The planner writes the intended steps first; the executor carries them out, often with ordinary code and tools.

A refund plan might retrieve the order and policy, check eligibility and exceptions, issue the permitted method, and send confirmation. If those operations are deterministic, only planning needs an LLM. The plan is easy to inspect, store, and audit, and it avoids asking a model to reconsider every step.

The trade-off is that a plan is a forecast. Blindly following “issue refund” after the payment tool reports “card closed” is predictably wrong. Production plans need conditions and preconditions: issue the approved method only if eligibility is true, the amount matches, and no refund already exists. If a precondition fails, stop or invoke a bounded re-plan.

The useful hybrid is to plan the broad route once, execute ordinary steps mechanically, and re-plan only when a meaningful condition changes. Use this pattern when the process is known and stable, such as document pipelines, scheduled reports, and operational runbooks. If the task is always “validate fields, call API A, then API B,” use ordinary code instead.

Reflexion: learn from a failed attempt

Reflexion is a loop in which an agent makes an attempt, receives task-tied evaluation, generates a verbal self-reflection about the failure, stores that reflection in working or episodic memory, and conditions its next attempt on the stored reflection. A one-off critique-and-revise pass is a related, broader pattern; without the stored verbal reflection guiding a later attempt, it is not the canonical Reflexion pattern.

The evaluator must be tied to the task: a test suite, schema validator, policy checker, database query, or human review signal. Asking the same model “are you sure?” is not dependable evaluation.

Suppose the first answer for order 1842 says, “The refund cannot be issued because the 30-day window has passed.” A policy checker compares it with the ticket and finds the manager exception. Useful feedback says: “The answer omitted exception ticket 7719. Re-check it and state whether the approved repayment method is available.” From that feedback, the agent generates a verbal reflection such as: “I treated the default window as decisive without checking approved exceptions. Before answering, I must retrieve exception records and verify the repayment method.” It stores that reflection, and the retry is explicitly conditioned on it: the agent can then explain the valid exception, discover that the card is closed, and offer store credit without claiming the refund was returned.

Reflexion pays off when a first attempt can fail and failure can be detected reliably. It is weak when correctness is subjective or the evaluator is another unconstrained language-model opinion. A fluent critique can defend a wrong answer or generate repeated wrong answers.

Retries also need a hard limit. If an attempt takes three model decisions, critique takes one, and the retry takes three, one cycle costs seven model calls. Reflexion is a quality strategy, not a free correction.

The arithmetic behind the choice

Suppose the blended model cost is $0.012 per call and average model latency is 1.1 seconds. These are planning assumptions, not a benchmark; tools add their own latency.

The arithmetic is call count multiplied by assumed per-call cost. Plan-and-Execute is attractive when its plan is usually right. ReAct earns its extra calls when observations prevent wasted or dangerous work. Reflexion earns them when a verifier catches errors that another attempt can repair.

A lower call count is not automatically better: one incorrect refund can cost more than dozens of model calls. Reflexion is not automatically safer either; retrying after an unnoticed side effect can duplicate it.

Choosing and operating a loop

Use ReAct when you discover the next useful step from live results. Use Plan-and-Execute when requests follow stable phases. Use Reflexion when a reliable checker can identify defects. For expensive or irreversible actions, combine a bounded plan with adaptive evidence gathering and verification before commit.

A common composition is Plan-and-Execute outside, ReAct inside an uncertain evidence-gathering step, and a reflection pass before the final side effect. Add that machinery only when measured failures justify its cost.

Make progress and plans structured. Store the current phase, completed tools, important facts, remaining budget, step dependencies, conditions, and allowed actions. A transcript or free-text plan is difficult to validate and can hide repeated work.

Separate reads from writes. Looking up a ticket and issuing store credit do not deserve the same authority. Validate arguments, check permissions, and put human approval around high-impact writes.

Budget every path. Set limits for steps, model calls, wall-clock time, retries, re-plans, and spend. Define the fallback: return a safe draft, preserve state for resumption, or escalate.

Trace causes, not private monologues. Record the loop type, iteration, tool and validated arguments, result status, evaluator findings, token usage, and stop reason. These fields explain why an agent called a refund tool twice.

Failure modes you will actually see

ReAct repeats a tool

Nearly identical searches and no new facts mean the loop has no notion of progress. Track visited actions, add a no-progress termination rule, and provide better tool errors. After repeated equivalent failures, use another source or escalate instead of increasing the step limit.

Plan-and-Execute follows a stale assumption

A tool rejects a valid-looking step, such as issue_refund returning “payment method unavailable,” while the executor continues to confirmation. Check preconditions immediately before side effects. On failure, preserve the observation and select a safe branch or perform one bounded re-plan. A re-plan must not erase the fact that the card is closed.

Reflexion approves a bad answer

If the reflection says “accurate” despite a failed policy comparison, the evaluator is too weak or too correlated with the generator. Replace vague self-critique with concrete checks and measure false approvals against labeled tests. A second model is not automatically independent.

A retry repeats a side effect

A timeout does not prove that the first tool call failed. Use an idempotency key such as refund-order-1842, and check the ledger before retrying. Whenever possible, draft, verify, approve, and only then commit. See agent safety controls.

Quick check

Next

These loops run inside a single agent. When one agent is not enough, see multi-agent orchestration — and ask the equally important question of when not to go multi-agent.