For a task with uncertain steps, occasional tool failures, and a strict latency budget, how would you choose between ReAct, Plan-Execute, and Reflexion? What evidence would cause you to change the pattern later?

How to think about it

For the task as stated, I would start with bounded ReAct: let the agent choose its next action from the latest tool result, but cap its turns, tool calls, and wall-clock time. I would move toward Plan-Execute if traces showed that the same plan worked repeatedly, and add Reflexion only when a verified critique improved recovery enough to justify another model call.

What the interviewer is really testing

The choice depends on where the uncertainty lives.

ReAct means interleaving a decision with an action and its observation. The agent decides which tool to call, sees the result, then decides what to do next. It suits tasks where the correct next step depends on information that is not available at the start.

Plan-Execute separates the work into two stages. A planner creates a sequence of steps or subgoals, and an executor carries them out. This is useful when the task can be decomposed in advance, especially when independent steps can run in parallel.

Reflexion adds a deliberate critique-and-retry loop. After a failed or weak attempt, the system asks for a diagnosis, records feedback, and tries again. It is most useful when failures repeat and the system has a reliable way to tell that an attempt was wrong.

Those patterns solve different problems. ReAct handles uncertainty about the environment. Plan-Execute handles predictable structure. Reflexion handles learnable failure.

A strict latency budget changes the order of priorities. Every model call, serial tool call, retry, and network timeout consumes that budget. A clever plan that arrives 900 milliseconds too late is not clever in production.

The practical comparison

Pattern	Mechanism	Good fit	Main cost
ReAct	Decide, act, observe, decide again	The next step depends on live results or branching	Serial model and tool calls
Plan-Execute	Plan first, then execute the steps	Stable workflows with independent or predictable steps	A bad early plan can waste the whole run
Reflexion	Critique a failed attempt, then retry	Repeated, diagnosable failures with trustworthy feedback	Extra latency, tokens, and possible error loops

For the question’s combination of uncertain steps and occasional tool failures, ReAct is the safest starting point. It can notice that a tool returned an empty result, distinguish that from a genuine business result, and choose a fallback. Plan-Execute may commit to a path before it knows which tools are healthy. Reflexion is usually too expensive for the synchronous first attempt.

That does not mean “let the model think forever.” Production ReAct needs a deadline propagated through the entire run. For example:

• at most two model decisions;
• at most three tool calls;
• no tool call waits longer than 400 milliseconds;
• stop at 2 seconds and return a partial answer or a clear escalation.

The exact values depend on the service. The important point is that the limits are explicit.

A concrete example

Suppose an incident assistant must answer, “Why did checkout error rates rise, and is the current deployment involved?” The service has a 2.5-second p95 latency target, where p95 means 95 percent of requests must finish within 2.5 seconds.

The assistant has three tools:

1. a metrics query;
2. a deployment-history query;
3. a runbook search.

The steps are not fully known in advance. If metrics show a sharp increase immediately after a deployment, deployment history matters. If metrics show a regional problem with no recent deployment, the assistant should search the regional runbook instead.

A bounded ReAct run could look like this:

1. Call metrics.
2. Observe that checkout errors rose from 0.4 percent to 7.8 percent in one region.
3. Call deployment history because the timing may matter.
4. If that tool times out, search the runbook or report that deployment correlation could not be verified.
5. Stop at the deadline.

The important behaviour is not the word “ReAct.” It is that the second action depends on the first observation.

A Plan-Execute version might create this plan immediately:

1. Query metrics.
2. Query deployment history.
3. Search the runbook.
4. Summarise the evidence.

That plan is attractive if the three queries are independent. The executor can run them concurrently, reducing wall-clock time. But if runbook search requires knowing the affected region, or if deployment history is unavailable and the executor has no repair rule, the fixed plan becomes wasteful.

A Reflexion version would first produce an answer, run a verifier, and ask the model to critique the answer if verification failed. That could improve quality when the verifier can say something concrete, such as “the answer claims a deployment occurred, but the deployment tool returned no matching record.” It is a poor fit if the only feedback is “the answer feels incomplete.” Vague criticism tends to produce a more confident version of the same mistake.

Warning: a failed tool call is not proof that the plan is wrong. It may be a timeout, an authentication error, rate limiting, or a genuinely empty result. The controller should classify tool failures and apply deterministic timeout and fallback rules before asking a model to improvise.

The senior-level answer is usually a hybrid

The textbook categories are useful, but a production agent does not need to choose one pattern for every phase.

I would use a small deterministic state machine around the model:

• validate the request and establish the deadline;
• use a short ReAct loop for uncertain decisions;
• run independent, already-known queries in parallel;
• retry only transient failures, with a strict retry budget;
• use Reflexion asynchronously to improve future prompts, routing rules, or tool descriptions.

This separates two concerns that are often confused. The model can decide what evidence is needed. The runtime, not the model, should enforce timeouts, authentication handling, idempotency, and maximum retries.

Reflexion also does not automatically create lasting learning. A critique is useful only if it is grounded in a reliable signal: a test result, a database invariant, a human correction, or another verifiable outcome. Otherwise the system may spend 700 milliseconds explaining why a correct answer was “probably wrong,” then make it worse.

The trade-off is particularly sharp under latency pressure. Plan-Execute can win even when the task is somewhat uncertain if parallel execution saves more time than adaptive reasoning costs. ReAct can win even when it uses more calls if a fixed plan regularly takes irrelevant branches. The right comparison is measured end-to-end latency and correctness, not the number of boxes in an architecture diagram.

What evidence would change the pattern?

I would instrument each run with:

• end-to-end p50, p95, and p99 latency;
• number of model turns and tool calls;
• timeout and error type for every tool call;
• whether the agent recovered from the failure;
• task correctness, ideally against a labelled evaluation set;
• how often a plan was changed or abandoned;
• how often Reflexion caused a successful correction rather than another attempt.

I would move toward Plan-Execute if, for example, traces showed that 90 percent of requests followed the same four steps, those steps were mostly independent, and parallel execution kept p95 below the target. Stable plans are evidence that upfront planning is buying useful structure rather than guessing.

I would keep or expand ReAct if plan edits were common and materially improved correctness. A plan that changes on 40 percent of runs is not really a plan; it is an expensive guess before the real work begins.

I would add Reflexion only if failed runs had a repeatable diagnosis and offline evaluation showed a meaningful correction rate. For example, if a verifier found that 30 percent of failures came from confusing “empty result” with “tool timeout,” and a critique-and-retry fixed most of those cases within the allowed budget, Reflexion may earn a place. If it merely raises token use and p99 latency, remove it.

What they’ll ask next

“Why not use Reflexion for every tool failure?”
Because most tool failures are operational, not reasoning failures. A timeout needs a timeout policy or fallback. Critiquing it with another model call adds delay without fixing the network.

“How do you measure whether the plan is stable?”
Log the planned steps and the executed steps. Track plan-abandonment rate, branch frequency, correctness, and the latency saved by parallel execution. Stability means the plan is both repeatable and useful, not merely short.

“What happens when the deadline expires halfway through?”
Return only claims supported by completed tool results, mark missing evidence explicitly, and escalate when the answer is unsafe or incomplete. Never fabricate the result of a tool that did not finish.

One line to say in the room

“I’d start with bounded ReAct for live uncertainty, use Plan-Execute when traces prove the workflow is stable and parallelizable, and earn Reflexion only with verified evidence that critique-and-retry improves outcomes within the latency budget.”