ReAct & Plan-and-Execute

Agent architectures turn a one-shot model call into a stateful system that can request tools, observe results, and continue. This chapter compares ReAct and plan-and-execute patterns so you can choose a control loop for multi-step product work.

Imagine asking a smart assistant to not just draft a reply about a delayed shipment, but to check the order record, request a carrier update, and create a replacement-shipment task if the package is lost. A plain LLM call is passive: it produces tokens, but it doesn't execute side effects on its own. Agent runtimes bridge that gap by treating the model as a reasoning engine that can choose tools, update state, and coordinate multi-step work.

Most product paths should stay deterministic. An agent becomes useful when the next safe step depends on live evidence that can't be enumerated cheaply in advance, and when your runtime can check its effects.

Before the patterns, one reality check that frames everything below. Anthropic's guidance on building effective agents draws a line between two kinds of systems^[1]. A workflow is a system where LLMs and tools follow predefined code paths that you wrote. An agent is a system where the model dynamically directs its own process and tool use, deciding at runtime how to reach the goal. Both are useful. The guidance is blunt: find the simplest pattern that works and add complexity only when it demonstrably improves outcomes, because agentic systems trade latency and cost for flexibility. Stripped down, an agent is "just LLMs using tools based on environmental feedback in a loop." ReAct and Plan-and-Execute are two named shapes of that loop, not magic. A fixed prompt chain or a single tool-calling call is often the right answer.

Key insight: An agent isn't just an LLM with tools. It's a loop with state, allowed actions, observations, and runtime boundaries. Some agents also need planning or long-term memory; don't add those components until the task requires them. If the steps are known in advance, a workflow is cheaper and easier to debug.

This article builds on two ideas you have already met. Chain-of-Thought prompting studied visible intermediate reasoning traces before answers.^[2] Function calling lets a model request an action using arguments that your code validates and executes. An agent runtime turns these ideas into a loop: request a next move, execute an allowed tool, record an observation, and repeat. We will look at two useful loop shapes: ReAct, which decides one step at a time, and Plan-and-Execute, which drafts a roadmap before moving.

ReAct: reasoning + acting

Why one step at a time?

The ReAct (Reason + Act) pattern is an influential agent loop. Proposed by Yao et al. (2023), it interleaves reasoning traces with actions and observations on the paper's evaluated tasks.^[3] A reasoning-only response can't check a live carrier scan. An acting-only policy may issue tool calls without enough task context. ReAct combines a next-step decision with fresh environmental evidence.

Think of a fulfillment agent resolving a delayed order. It checks tracking (Observation), decides the carrier scan is stale (Reasoning), opens a carrier inquiry (Action), then reads the new status before choosing the next step. ReAct applies this same observe-decide-act loop to AI.

The paper writes this pattern as Thought, Action, and Observation. Treat Thought: as explanatory notation, not as a production API contract. OpenAI's current reasoning documentation describes reasoning tokens as hidden output tokens rather than a raw trace returned to the application.^[4] Store the observable state you can audit: validated tool requests, tool results, bounded decision notes when a user needs an explanation, and budget usage.

The analogy that fits best is a warehouse picker who doesn't have a complete pick list. They walk to the first bin, read the label, decide what to grab, and only then plan the next aisle based on what they just learned. ReAct is that picker. It doesn't assume it knows the whole warehouse layout. It adapts after every shelf.

The figure below shows that feedback loop: every observation becomes the state for the next reasoning step.

The ReAct loop

In practice, a user's request triggers repeated next-move decisions, tool execution, and observations until the model returns a final answer or the runtime stops the loop.

A concrete trace

Here is a paper-style ReAct trace where the agent must resolve a delayed order. The Thought lines make the lesson legible; an application can implement the same control loop without storing private reasoning text.

Notice what happens to state as the loop runs. After the first tool call, the runtime has the goal, the action, and the observation. After another call, it has another evidence record to make available to the next model turn. If every raw result is appended, context grows with the trajectory; long tasks need summaries, external state, or another control pattern. The exact token cost depends on your prompts, tools, and summarization policy.

Building the loop in code

A functional runtime validates each requested move before it executes anything. The model-facing schema in a hosted API can enforce the shape of NextMove; this dependency-free example focuses on application responsibilities: tool allowlisting, step limits, observation storage, and a final answer grounded in those observations.

The model proposes NextMove records. The runtime decides whether a tool is available, whether budget remains, and whether enough evidence exists to return an answer. No free-form private reasoning trace is needed in the audit log.

When ReAct breaks

ReAct's tight interleaving of decisions and actions creates specific failure modes worth knowing:

Infinite loops. ReAct agents can get stuck repeating the same action when a tool returns unhelpful results. If a search returns no results, the agent might search again with the identical query instead of reformulating. Enforcing a maximum step count and tracking action hashes prevents this from running indefinitely.

Context overflow. Each step may append actions, observations, and summaries to the context window. For tasks requiring many steps, that context can eventually exhaust the model's limit. Strategies include summarizing older evidence, storing full results outside the prompt, or switching to a longer-context model.

Grounding failures. ReAct's key strength is grounding reasoning in actual observations rather than the model's internal beliefs. When a tool returns misleading or incomplete data, the agent can chase a false trail. Reliable implementations include sanity checks on tool outputs before feeding them back as observations.

Interface errors. If the model's requested action doesn't satisfy the expected tool schema, the runtime must reject it. JSON mode only gives valid JSON syntax; it doesn't ensure correct tool fields. Use strict tool schemas where supported and validate the resulting arguments and policy in application code.^[5]

Self-consistency without duplicated effects

Self-consistency samples multiple reasoning paths and selects a common answer, originally for reasoning tasks with a defined final response.^[6] Applying that idea to an agent requires a boundary: candidate trajectories can inspect fixed, read-only evidence or run in a sandbox, but they shouldn't each issue real refunds, replacements, or messages. After selecting a proposal, the runtime still applies policy and executes at most one approved effect.

Self-consistency multiplies model and read-only tool work by the number of samples. It can support a reviewable recommendation, but it isn't permission to repeat writes.

Reflexion: learning from a failed attempt

Self-consistency samples many trajectories in parallel and votes. Reflexion (Shinn et al., 2023)^[7] takes the opposite approach across attempts: when a trajectory fails, the agent writes a short natural-language reflection on why it failed and stores that note in memory, then retries with the reflection added to its context. The original paper calls this "verbal reinforcement learning," because the agent improves through written self-critique rather than weight updates. On the HumanEval coding benchmark, Reflexion reported 91% pass@1, above the 80% GPT-4 baseline the paper cites.

The mechanism fits the order-recovery example directly. Suppose a ReAct attempt closes a non-delivery ticket using a stale carrier scan, and an evaluator flags it as wrong. A Reflexion-style agent records a lesson such as "don't trust a carrier scan older than 24 hours; check for a fresher event first," then carries that lesson into the next attempt. Reflexion works best when three conditions hold: you get a clear pass or fail signal, the lessons stay short and task-specific, and retries are allowed. It's a memory technique layered on top of ReAct, not a replacement control loop.

The failure signal comes from an evaluator or environment check, not from the agent deciding that its own unsupported story sounds convincing.

Plan-and-Execute

Why plan first?

ReAct is powerful, but it's local: it chooses the next action from the latest observation rather than from a committed global plan. For complex tasks such as "audit every delayed order from yesterday and draft recovery actions," a ReAct agent might get lost in one carrier exception and forget the overall recovery workflow.

If ReAct is like a support rep resolving the next visible issue, Plan-and-Execute is like a warehouse incident runbook. First, the planner maps the recovery steps, then executors handle tracking checks, inventory checks, customer messaging, and refund decisions in order.

Plan-and-Execute decouples planning from execution. It's a practical runtime pattern related to plan-first prompting techniques such as Plan-and-Solve,^[8] but it doesn't imply one standard protocol. A plan may be a linear checklist or a dependency graph:

1. Planner: An LLM generates a multi-step plan based on the user request.
2. Executor: An agent (often a ReAct agent itself) executes each step of the plan.
3. Replanner: The system reviews the results and updates the plan if necessary.

These roles don't have to be different models. Small systems often use one model in separate planning and execution prompts, while cost-optimized systems route planning to a stronger model and execution to cheaper specialists.

The figure below shows the key separation: a planner owns the global shape, executors own local work, and verifier/replanner steps keep the plan from going stale.

The Plan-and-Execute flow

This architecture cleanly separates planning from execution. A planner drafts the initial steps, executors work through them, and a validation loop checks whether the remaining plan still makes sense. That global plan reduces goal drift on long tasks, but it doesn't eliminate it. A weak initial plan can still send every executor in the wrong direction.

The same order, planned

Return to the Order A102 example. A Plan-and-Execute agent would first emit a plan, then execute it:

Planner output

Executor trace

The executor for Step 4 might itself be a small ReAct agent that reasons about the inputs and picks the best action. That's a common hybrid pattern: a global planner keeps the big picture, while local ReAct loops handle individual decisions.

A useful plan records dependencies rather than pretending all five steps are sequential. In this order example, tracking, inventory, and customer preference can be fetched independently. The action decision must wait for all three.

This representation exposes concurrency without overstating it. The first three reads can run together only if the runtime supports concurrent execution and the tools don't share a conflicting resource.

Comparing the two approaches

Choosing between ReAct and Plan-and-Execute requires balancing cost, task complexity, and reliability. ReAct is useful for short, evidence-dependent decisions, but it can drift on long tasks because it lacks an explicit global plan. Plan-and-Execute gives you that plan, but it can produce brittle execution if you don't pair it with validation and replanning.

When to use each

Use ReAct when:

• The environment provides immediate feedback after each action
• Task length is bounded by an explicit runtime budget
• You need to ground decisions in live data (search, database lookups)
• The optimal path isn't predictable upfront

Use Plan-and-Execute when:

• The task has a clear overall structure (audit shipments, draft a recovery report)
• Steps have dependencies that benefit from upfront sequencing
• You can parallelize independent sub-tasks
• Executor steps are well-scoped and locally checkable (running tests, scraping pages, querying APIs with known schemas)

The brittleness problem

Plan-and-Execute's main weakness is the brittleness of the initial plan. If the planner misinterprets the user's intent, the entire execution pipeline is misaligned. Worse, downstream executor steps often depend on outputs from earlier steps, so a wrong assumption in Step 1 can invalidate Steps 2 through N. A ReAct loop gets an earlier opportunity to react to new evidence, but it can still repeat a bad decision without runtime checks.

Robust implementations address this by:

• Constraining the planner's output format: Use structured prompts that limit the planner to a fixed set of step templates rather than free-form generation.
• Adding a validation step: After the planner generates the initial plan, a second pass checks that each step is achievable and that prerequisites are satisfied.
• Triggering replanning early: Rather than waiting for an executor to fail, check intermediate outputs against the original goal and replan if the delta exceeds a threshold.

When evidence breaks an assumption, patch only unfinished work. The completed carrier query remains an observation; a revised plan shouldn't issue the same write again.

How tool calls actually flow

While we conceptually say an agent "calls" a tool, the side effect still happens in your runtime (your Python or TypeScript code). At the API boundary, the model may emit raw JSON, a structured tool-call object, or another schema-constrained payload rather than plain prose.^[5] Your application is the part that validates arguments, executes the external call, and feeds the result back into the next model turn.

To make this work, the LLM needs to know exactly what tools are available and how to use them. In practice, the runtime passes structured tool definitions either in the prompt or through the provider's tool-calling API. Those definitions are usually JSON-schema-like rather than the full JSON Schema spec, and the model uses the field descriptions, enums, and required keys to construct a valid request.^[5]

Tool use connects model decisions to fresh, authorized evidence and controlled effects. An order-status tool can return the latest carrier event; a write tool can create a reshipment only after application policy approves it.

Tool definition

Tools need an argument contract so the LLM knows the allowed request shape. Tool-calling APIs can expose such schemas directly to the model. The example below defines a closed JSON-schema-like contract, then shows application checks that still matter: type validation and whether this merchant may see the requested order.

The execution loop

The underlying mechanics of "Tool Use" involve a hidden round-trip handled by your application:

1. User: "Where is order A102?"
2. LLM: Returns a tool call record or JSON such as {"tool": "get_order_status", "args": {"order_id": "A102"}}
3. Runtime: Pauses generation. Parses the tool call payload. Calls API. Gets "delayed, ETA Friday".
4. Runtime: Feeds the result back as a tool-result message containing "delayed, ETA Friday"
5. LLM: "Order A102 is delayed and now expected Friday."

This hidden round-trip relies entirely on your application code. The LLM doesn't execute the API request itself; it merely generates the structured request representing the intended call. The host application needs to securely execute the external call, manage connection timeouts, handle authentication, and then format the response back into a format that the LLM can ingest for its next reasoning step.

Common mistake: Treating schema validation as sufficient. Constrained outputs reduce syntax errors, but your runtime still needs to handle semantically bad arguments, missing auth, and tool timeouts.

A write needs another boundary: retrying the same agent turn must not create duplicate effects. Give each intended effect an idempotency key owned by your application, not invented afresh on every model retry.

When agents break

An unconstrained loop can spend far beyond the intended request budget or issue duplicate writes. Production systems need runtime controls before an agent is allowed to affect orders, refunds, or customer communication.

Agents operate in dynamic environments where external state can change between steps. When a tool returns an unexpected format, or an API call times out, a naive agent might blindly retry the exact same action or invent a response. Because an observation influences later moves, errors can compound. A single unsupported conclusion can derail the execution plan.

To build reliable agents, engineers need strong guardrails at the runtime layer. This means treating the LLM as an unreliable sub-component rather than a deterministic program. You need to validate all structured outputs, enforce hard limits on execution steps, and provide clear, actionable error messages back to the model when a failure occurs.

Detecting cycles in code

To prevent loops, track normalized actions in a short recent window. The detector below catches repeated single actions and short alternating patterns. A production detector also needs progress signals, because an agent can repeat a valid read while receiving new pages of results.

Try it yourself

Below is a partial ReAct trace for a different order. Three steps are shown, but the fourth step contains a mistake. Read the trace, identify what goes wrong, and decide what the agent should have done instead.

What went wrong? The agent checked that the GPS tag was in Paris, but it never compared the GPS coordinates to the exact delivery address. A package left at the wrong building in the same city is still a failed delivery. The agent should have checked the distance to the address coordinates. If the distance was above a threshold, it should have flagged a possible misdelivery rather than closing the ticket.

The fix: Add an enforced verify_delivery_distance precondition before the close action. A prompt reminder is useful context, but it can't block a write when the model ignores it.

Assume an address service returns reference coordinates for the delivery address. The runtime can calculate the distance and route distant proof to investigation instead of trusting the model's interpretation.

Key takeaways

• Start with the simplest pattern. An agent is "just LLMs using tools based on environmental feedback in a loop"^[1]. If the steps are known in advance, a fixed workflow or a single tool-calling call beats an autonomous loop on cost, latency, and debuggability. Reach for ReAct or Plan-and-Execute only when the next step genuinely depends on what the model observes.
• ReAct is a useful pattern for short, interactive tasks whose next move depends on fresh evidence. In practice, start with a small tool-calling loop and add orchestration only when evaluations justify it.^[1]
• Plan-and-Execute fits work with a stable global structure and checkable local steps. It separates planning from execution while requiring validation and replanning.
• Reflexion^[7] adds a memory of written lessons from failed attempts on top of a ReAct loop. It is a refinement, not a separate control architecture.
• Multi-agent systems can use a Plan-and-Execute shape when planner, executor, and verifier roles become separate workers. This chapter gives you the control-loop vocabulary you will need before later orchestration work.
• Memory matters for both architectures. ReAct trajectories grow one observation at a time, while Plan-and-Execute systems need somewhere to store intermediate outputs between phases. A dedicated article on agent memory and persistence follows later in the path.
• Observability is key. Log state you actually control: validated tool calls, planner outputs, redacted observations, approvals, retries, and budget usage. Don't make raw chain-of-thought your audit artifact.

Mastery check

Key concepts

• ReAct Pattern
• Plan-and-Execute
• Chain-of-Thought
• Tool Use
• Self-Consistency
• Reflexion
• Cycle Detection
• Replanning

Evaluation rubric

• Foundational: Implement a ReAct-style loop with validated actions, observations, and runtime-owned budgets
• Intermediate: Design a Plan-and-Execute architecture with distinct Planner and Executor roles
• Advanced: Compare the latency, token-cost, and recovery trade-offs between ReAct and Plan-and-Execute
• Advanced: Explain how localized executor context and external memory reduce prompt growth
• Advanced: Implement failure recovery mechanisms like replanning, cycle detection, and step-limit guardrails

Follow-up questions

Common pitfalls

• Symptom: a ReAct agent gets lost in long audits or migrations. Cause: the task needs a stable global plan, but the loop only sees the next local step. Fix: switch to Plan-and-Execute or use a planner plus local ReAct executors.
• Symptom: tool calls repeat until the budget is gone. Cause: loop detection and hard step limits live only in the prompt, not in runtime code. Fix: enforce step caps, cycle detection, and timeout budgets outside the model.
• Symptom: the agent gets slower and forgets earlier intent after many turns. Cause: every raw observation and intermediate update was appended forever. Fix: retain authoritative state outside the prompt, summarize older evidence, restate the goal periodically, and keep only recent detail in context.
• Symptom: every executor follows a bad plan faithfully. Cause: the initial Plan-and-Execute plan was treated as truth instead of a draft. Fix: validate the plan early and patch the remaining plan when new evidence breaks old assumptions.