ReAct & Plan-and-Execute

Structured output gave the runtime a reliable shape for one model response. Agent architectures ask the next question: who decides the next step when one response isn't enough?

Agent architectures turn a one-shot model call into a stateful system that can request tools, observe results, and continue. ReAct and plan-and-execute patterns give you two control loops for multi-step product work.

A code assistant that inspects a failed CI job needs to read the error log, check the changed files, explain the failure, and open a rollback proposal if the release broke production. 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]Reference 1Building Effective Agentshttps://www.anthropic.com/research/building-effective-agents}. 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 a special runtime category. A fixed prompt chain or a single tool-calling call is often the right answer.

Agent loop: An agent needs more than 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.

Two ideas you have already met become the agent loop. Chain-of-Thought prompting studied how intermediate reasoning steps in demonstrations can elicit multi-step reasoning before answers.^{[2]Reference 2Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.https://arxiv.org/abs/2201.11903} 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. Two useful loop shapes matter most here: 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]Reference 3ReAct: Synergizing Reasoning and Acting in Language Models.https://arxiv.org/abs/2210.03629} A reasoning-only response can't inspect a live CI failure. An acting-only policy may issue tool calls without enough task context. ReAct combines a next-step decision with fresh environmental evidence.

A code agent resolving a failed release follows the same loop. It checks the CI failure (Observation), decides the error points at a migration (Reasoning), reads the migration diff (Action), then runs a targeted test before choosing the next step. ReAct applies this observe-decide-act pattern 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]Reference 4Reasoning modelshttps://developers.openai.com/api/docs/guides/reasoning} 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 an on-call engineer debugging from live evidence. They read one signal, form a hypothesis, run the next narrow check, and update the route from what came back. ReAct is that loop. It doesn't assume the whole incident path is known upfront. It adapts after every observation.

This visual 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

This paper-style ReAct trace asks the agent to triage a failed deployment. 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 validate correct tool fields. Use strict tool schemas where supported and validate the resulting arguments and policy in application code.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

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]Reference 6Self-Consistency Improves Chain of Thought Reasoning in Language Models.https://arxiv.org/abs/2203.11171} 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 open real pull requests, roll back services, or post incident updates. 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]Reference 7Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} 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 reported in the same paper.

The mechanism fits the deployment-debugging example directly. Suppose a ReAct attempt declares a release fixed after reading one stale CI log, and an evaluator flags it as wrong because the targeted test still fails. A Reflexion-style agent records a note such as "verify the current run before proposing a deploy retry," then carries that note into the next attempt. Reflexion works best when three conditions hold: you get a clear pass or fail signal, the notes 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 useful, 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 failed workflow from yesterday and draft recovery actions," a ReAct agent might get lost in one flaky test and forget the overall release-readiness workflow.

If ReAct is like an on-call engineer resolving the next visible signal, Plan-and-Execute is like an incident runbook. First, the planner maps the recovery steps, then executors handle CI checks, log reads, owner lookups, patch drafting, and rollout 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]Reference 8Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models.https://arxiv.org/abs/2305.04091} 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.

This visual 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 release, planned

Return to the R1842 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 release example, CI metadata, changed files, and deployment health 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.

Read it as a gate, not a spectrum. First ask whether a fresh tool result can change next safe action. If not, planner overhead buys nothing and ordinary workflow code is better. If yes, then ask how much route is known upfront: ReAct for discovered paths, Plan-and-Execute for stable decomposition, hybrid when both appear in same task.

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 failed workflows, 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.

Production 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 CI query remains an observation; a revised plan shouldn't issue the same write again.

How tool calls flow

Calling a tool is shorthand. 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 structured output rather than plain text.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs} 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]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

Tool use connects model decisions to fresh, authorized evidence and controlled effects. A CI-status tool can return the latest failed step; a write tool can open a rollback proposal 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. In a supported strict schema mode, the provider enforces the declared structure and types. The application still validates authorization, resource existence, semantic constraints, and policy, including whether this actor may inspect the requested CI run.

This example deliberately leaves include_logs optional because it's an application-level schema. If you submit a schema in OpenAI strict mode, every property must appear in required; represent a conceptually optional field with a nullable type instead.^{[5]Reference 5Structured outputshttps://developers.openai.com/api/docs/guides/structured-outputs}

The execution loop

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

1. User: "Why did CI run R1842 fail?"
2. LLM: Returns a tool call record or JSON such as {"tool": "get_ci_status", "args": {"run_id": "R1842"}}
3. Runtime: Pauses generation. Parses the tool call payload. Calls API. Gets "failed: migration-test duplicate column".
4. Runtime: Feeds the result back as a tool-result message containing "failed: migration-test duplicate column"
5. LLM: "Run R1842 failed in migration-test because the migration re-adds an existing column."

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 deployments, repositories, or incident communications.

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 step and token budgets, and return 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

The partial ReAct trace below comes from a different release. 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 compared a healthy region on an older commit with an unhealthy region on the new commit, but never verified that the affected region was rolled back or recovered. A different region's health doesn't prove the incident is resolved. The agent should have checked the service health in us-east after rollback or kept the incident open.

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

Assume the monitoring system returns current latency for the affected region. The runtime can block closure until the target region meets its recovery threshold.

Agent architecture choices

• Start with the simplest pattern. An agent is "just LLMs using tools based on environmental feedback in a loop"^{[1]Reference 1Building Effective Agentshttps://www.anthropic.com/research/building-effective-agents}. 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 fits 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]Reference 1Building Effective Agentshttps://www.anthropic.com/research/building-effective-agents}
• 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]Reference 7Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} adds a memory of written lessons from failed attempts on top of a ReAct loop. It's 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. These control-loop terms set up 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 needs owned state. Log 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.