Explain the ReAct agent pattern and how it compares to Plan-and-Execute and Reflexion.

How to think about it

ReAct is an agent control loop that alternates between deciding what to do, taking an action, and observing the result before deciding again. Plan-and-Execute plans several steps up front, while Reflexion adds a critique-and-retry loop after an attempt fails; they are different control patterns, and a production system can combine all three.

Why ReAct works

The interviewer is testing whether you understand that an agent does not need to solve the whole task in its head before touching the outside world.

A ReAct agent receives a task, chooses either a tool action or a final answer, and gets an observation after each tool action. An observation is simply information returned by the environment: a database result, a search result, an error message, or a human response. The next decision uses that new information.

The original ReAct formulation names these stages Thought, Action, and Observation. The important mechanism is not the labels. It is the feedback loop:

1. Decide what information or action is needed.
2. Call a tool or act on the environment.
3. Read the result.
4. Change the next decision if the result changes the situation.
5. Stop when the task is complete or the agent cannot proceed safely.

That loop is useful because many real tasks contain facts you cannot know in advance. A support agent may need to inspect an order before it knows which policy applies. A coding agent may need to run a test before it knows whether its fix works. A research agent may discover that its first search result is irrelevant.

A fixed sequence assumes the world will behave as expected. ReAct asks the world what happened and adjusts.

In a production system, I would not blindly expose raw chain-of-thought to users or store it as if it were an audit record. I would log the tool selected, validated arguments, observation, decision state, latency, and stop reason. A short rationale such as “tracking status is insufficient; check the delivery exception” is more useful and safer than treating private free-form reasoning as a trustworthy explanation.

Concrete example: a late package

Suppose it is August 28, 2026. A customer says:

“Order 84721 was promised for August 20. Please refund it if the policy allows.”

Assume the store policy allows a refund when an order is more than seven days late. The agent has tools for reading the order, checking carrier tracking, and looking up the policy. The tool names here describe capabilities, not a particular vendor API.

A ReAct trace might look like this:

Step	Agent decision	Observation
1	Read the order record	Promised August 20; current status is “in transit”
2	Check tracking because “in transit” does not explain the delay	Last scan was August 18; carrier reports an address exception
3	Check the late-delivery policy	Refund is allowed when the order is more than seven days late
4	Request the refund because the customer gave conditional approval	Refund request accepted

The key decision happens between steps two and three. The agent does not treat “in transit” as the answer. It notices that the order is eight days past its promised date and investigates the carrier exception before applying the policy.

A simple conceptual version is:

repeat until the task is complete or the action budget is exhausted:
    choose a tool action or a final answer from the current state
    if a tool action was chosen:
        validate its arguments
        execute it
        append the result to the state
    otherwise:
        return the answer

If tracking instead reported “delivered August 21,” the next step would change. The agent might ask the customer to check the delivery location rather than request a refund. That conditional adjustment is the heart of ReAct.

How Plan-and-Execute differs

Plan-and-Execute separates a task into two stages. A planner creates a multi-step plan, and an executor carries out those steps. The planner and executor may use the same model or different models.

For the package example, the planner might produce:

1. Read order 84721.
2. Inspect carrier tracking.
3. Look up the late-delivery policy.
4. Request a refund if the order qualifies.

The executor then works through that plan.

This gives the system a useful global view. The plan can be shown to an operator, checked for dangerous actions, and used to identify independent steps that can run in parallel. For a long task such as preparing a market report from six independent data sources, planning first may reduce aimless tool calls and make progress easier to monitor.

But Plan-and-Execute is not automatically more efficient. Creating a plan costs tokens and latency. A rigid plan can also become stale. If the carrier says the package was delivered, blindly executing “request a refund” is worse than pausing and replanning. Strong implementations therefore allow branches, validation, and replanning after important observations.

The clean distinction is:

• ReAct chooses the next step from the latest observation.
• Plan-and-Execute chooses a broader sequence before execution begins.
• Replanning lets Plan-and-Execute recover when the original assumptions stop being true.

ReAct tends to be more adaptive but may make many serial tool calls. Plan-and-Execute tends to be more predictable and easier to schedule, but it can be brittle when the environment changes.

How Reflexion differs

Reflexion is a feedback pattern in which an agent critiques a failed or weak attempt, records that critique, and tries again. The feedback may come from a test suite, a rule-based verifier, a user, or another evaluator.

Imagine the package agent reads only the order record and answers:

“The order is still in transit, so the refund policy does not apply.”

A verifier compares the answer with the promised date and policy. It flags the response because “in transit” does not cancel an eight-day delay. The agent creates a reflection:

“I used the carrier’s current status but failed to compare the promised date with today and failed to inspect the late-delivery policy.”

On its retry, it checks tracking and policy, then reaches the correct decision.

Reflexion is not necessarily a model-weight update. In many implementations, the reflection is stored as text in the agent’s working or episodic memory and supplied on the next attempt. That can improve repeated performance, but it is not magic learning. If the evaluator is wrong, the reflection can reinforce the wrong behavior. If there is no new evidence, the agent may simply produce a more confident version of the same mistake.

This is why Reflexion works best with a meaningful evaluator. A compiler can verify whether code builds. A test suite can verify behavior. A policy engine can verify eligibility. “Ask the language model whether its answer feels correct” is a much weaker signal.

The senior-level answer: these patterns compose

These are not mutually exclusive competitors.

A practical architecture might:

1. Use Plan-and-Execute to create a high-level plan.
2. Use ReAct to execute each step and respond to observations.
3. Run a verifier at the end.
4. Use Reflexion only when verification fails.
5. Retry within a strict budget and require human approval for irreversible actions.

For the refund example, the plan supplies the intended workflow, ReAct handles the changing tracking result, and Reflexion handles a failed policy decision.

The production safeguards matter as much as the pattern. I would use an allowlist of tools, schema validation for arguments, a maximum of six steps for this support flow, timeouts, duplicate-action detection, and idempotency for the refund operation. Idempotency means repeating the same request does not issue two refunds. A final answer should also state what evidence was used and what action was actually taken.

A common failure appears first in traces as the same tool call repeated with identical arguments. The usual causes are that the observation was not appended to state, the tool returned an unhandled error, or there is no stopping condition. The fix is not “give the model a stronger prompt.” Persist the observation, classify tool errors, detect repeated calls, cap the step budget, and fall back to a human or a clear failure response.

Pattern	Best fit	Main risk
ReAct	Uncertain, interactive tasks	Serial calls, loops, tool misuse
Plan-and-Execute	Long workflows with stable dependencies	Stale or overconfident plans
Reflexion	Recovering from evaluable failures	Costly retries and bad self-critique

What they’ll ask next

Does ReAct require exposing chain-of-thought?
No. The pattern requires useful intermediate state and observations, not a public transcript of private reasoning. In production, log structured decisions, tool calls, results, and verification outcomes.

When would you choose Plan-and-Execute over ReAct?
Choose it when the task has many predictable steps, independent work that can be parallelized, or a need for an inspectable plan. Choose ReAct when the next action depends heavily on information discovered during execution.

Can Reflexion be combined with ReAct?
Yes. ReAct handles step-by-step interaction; Reflexion can run after a failed verifier or user correction and feed the critique into a bounded retry. It should not retry irreversible actions without an approval boundary.

How do you prevent an agent from looping forever?
Set a step, time, and cost budget; detect repeated tool calls; validate tool results; define explicit success and failure states; and stop for human review when the agent cannot make progress.

Say this in the interview

“ReAct is an adaptive decide-act-observe loop, Plan-and-Execute creates and follows a broader plan, and Reflexion adds evaluator-driven critique and retry; in production I would often combine them with budgets, verification, and approval gates.”