ReAct vs Plan-and-Execute: Which Agent Pattern, and How to Explain It in an Interview

ReAct is for short exploratory tasks where each step depends on the last result. Plan-and-Execute is for longer tasks where the steps are mostly independent and you want predictable cost. Production systems use both, picking per task class.

That single paragraph is the answer to ninety percent of the “which pattern” interview questions. The rest of this post is how to talk about it in depth, where each pattern actually breaks, and the hybrid most senior teams end up shipping.

This is one of the patterns covered in the Interview Bootcamp chapter of Designing Enterprise Agentic AI Systems.

What ReAct actually does

ReAct interleaves reasoning and action in a single loop. The model thinks about what to do next, picks one tool, calls it, observes the result, thinks again, picks the next tool, and so on. Each turn produces exactly one action. The next action is chosen with full knowledge of every previous result.

A trace looks like this:

THOUGHT: I need to find out which deploy went out before this paged.
ACTION: query_deploys(service="auth", before="2026-05-24T14:00Z")
OBSERVATION: deploy id D-9214 went out 11 minutes before the page.
THOUGHT: I should check the diff to see what changed.
ACTION: get_deploy_diff(id="D-9214")
OBSERVATION: change touched the JWT validator.
THOUGHT: That matches the error class in the page. I should suggest rollback.
ACTION: final_answer("Suggest rolling back D-9214; touches the failing code path.")

Three properties matter. First, the model decides what to do next with the full context of what came before. That makes ReAct adaptive: if a tool returns something surprising, the model can change course. Second, each step burns one full inference call, including all the reasoning. Cost scales with steps. Third, the model itself decides when to stop, by emitting a “final answer” action instead of another tool call.

ReAct is the closest pattern to how a human troubleshoots in front of a terminal. Read, think, type, read, think, type. It is also the pattern the build-an-agent-from-scratch tutorial implements end to end in about 150 lines.

What Plan-and-Execute actually does

Plan-and-Execute splits the agent into two phases. A planner takes the goal and emits a multi-step plan up front. An executor runs each step in order. If a step fails, the executor optionally re-plans the remainder. The planner does not see intermediate results during execution; the executor does not reason about new actions, it just runs what was planned.

A trace looks like this:

PLAN:
  1. query_deploys(service="auth", before=t-15m)
  2. get_deploy_diff(id=<from step 1>)
  3. search_logs(service="auth", since=t-15m)
  4. summarize(deploy_diff=<from step 2>, logs=<from step 3>)

EXECUTE:
  step 1 -> D-9214
  step 2 -> diff touched JWT validator
  step 3 -> 4xx spikes correlated with rollout window
  step 4 -> final summary returned

Three properties matter, mirrored against ReAct. First, the plan is committed before any results are known. That makes Plan-and-Execute predictable in cost: you know how many steps you will run before you start. Second, the steps can sometimes run in parallel, since the planner did not declare dependencies it did not intend. Third, the planner reasons once at the start; the executor is cheap glue. Most of the model spend is one big planning call instead of N smaller ones.

The cost the pattern pays is rigidity. If the third step returns something the planner did not anticipate (the diff touched two services, or the logs are empty), the plan is wrong, and you either re-plan or fail. Production implementations always include a re-plan trigger because the assumption that the planner gets it right on the first try does not survive contact with real systems.

A side-by-side trace

Take a triage task: “page just fired for the auth service, find the likely cause.” Five tools available: query_deploys, get_deploy_diff, search_logs, query_metrics, search_runbooks.

ReAct walks it adaptively. It might call query_deploys first, see a recent deploy, get the diff, decide that is enough, and stop. Four inference calls (one per step), four tool calls.

Plan-and-Execute plans the whole thing first. The planner emits “query_deploys -> get_deploy_diff -> search_logs -> summarize.” One big inference, four tool calls, one small synthesis inference at the end. If the deploy diff alone explains the page, the search_logs call was unnecessary. But the agent does not stop early because the executor is not reasoning, it is following the plan.

Now invert the task. “Generate a quarterly cost report from these five datasets.” The steps are mostly independent: each dataset gets queried, summarized, and the results aggregated. Plan-and-Execute plans the five queries up front, runs them in parallel, then synthesizes. Total wall-clock latency is one query plus synthesis. ReAct would walk through each dataset sequentially because it has no notion of parallel steps, which is slower and more expensive.

The shape of the task determines which pattern wins. Adaptive, branching, “next step depends on this result” favors ReAct. Independent, parallelizable, “I know the structure of the work” favors Plan-and-Execute.

When to use which, in one paragraph each

ReAct: when the agent has to react to what it sees, when failure modes are recoverable in-flight, when the task is short, when latency budget is per-step rather than total, when the user is on the other end of the loop and you want a streaming feel.

Plan-and-Execute: when the task is long and the steps are knowable up front, when you need parallelism, when cost predictability matters more than minimum latency, when failures should be handled by re-planning rather than mid-flight reasoning, when the agent is running asynchronously and a human will see only the final result.

The hybrid that ships in production

Most production agentic systems do not pick one pattern. They route between them. A small router model classifies the incoming task (“is this an interactive triage” vs “is this a batch report”) and dispatches to the right pattern. Or, more commonly, the outer loop is Plan-and-Execute (decompose the goal into sub-goals) and each sub-goal is solved with ReAct (adapt to what shows up in the sub-task).

A concrete example. An incident-response agent has a top-level plan: “gather evidence, propose cause, draft message, hand to on-call for approval.” Each of those is a sub-goal. Inside “gather evidence,” the agent uses ReAct to explore (query metrics, follow a lead, query logs, follow another lead). Inside “draft message,” there is no further branching, so a single planning step generates the message. Inside “hand to on-call,” the agent stops and waits for human input.

This composition is what frameworks like LangGraph and OpenAI’s Agents SDK make ergonomic, but it is not framework-only. You can implement the same shape in plain code, as the build-an-agent-from-scratch tutorial shows for the ReAct part. Wrapping a planner around it adds maybe forty lines.

How to talk about this in an interview

The interview answer has three pieces.

Name the trade-off. “ReAct is adaptive at the cost of per-step inference, Plan-and-Execute is predictable at the cost of rigidity.” Without this sentence the rest of the answer sounds like opinion.

Map to task class. Give an example task where each one fits. Incident triage for ReAct. Batch report generation for Plan-and-Execute. Concrete examples beat abstract argument.

Name the hybrid. The strongest signal is the candidate who says “and in practice we ran both, with the outer loop planning and the inner loop ReAct-ing, because real tasks are not pure either pattern.” That sentence tells the interviewer you have actually built one of these, not just read about it.

Avoid the failure modes. Do not say “I prefer ReAct because it is simpler” (it is more expensive at scale). Do not say “I prefer Plan-and-Execute because it is more predictable” (it cannot handle branching tasks). Do not say “I use LangGraph” as the entire answer (the question is about patterns, not frameworks). The trade-off is the answer.

The deeper version of this discussion, plus a dozen other patterns interviewers probe (planner/tool-registry/executor, bounded autonomy, structured output, model routing), lives in the agentic AI interview questions post.

Where to take this next

If this discussion landed, the next move depends on which way you came in. For the production architecture and the engineering judgment that surrounds these patterns, Designing Enterprise Agentic AI Systems is the long form. The Agents and Architecture chapters cover ReAct, Plan-and-Execute, planner/tool-registry/executor, and multi-agent decomposition together with the cost, evaluation, and reliability work that surrounds them.

If you are still building intuition for the agent loop that underlies both patterns, Understanding Agentic AI Systems is the on-ramp, and the build-an-agent-from-scratch tutorial is the working code.

For more questions in the same shape, the agentic AI interview questions post is the densest single resource on this site.