ReAct, Reflection, or Planner–Executor: Which Agent Pattern Fits?

Use ReAct when the next useful action depends on what a tool returns. Use reflection when a draft or attempt needs revision against meaningful feedback. Use planner–executor when a task benefits from an explicit breakdown into steps and dependencies.

These patterns can work together. A planner can assign a task to an executor that uses ReAct, then a reflection step can help revise an unsuccessful attempt. Start with a simpler workflow when its steps are already known and its result is straightforward to check.

For digital and IT leaders, business owners, and curious readers, the useful distinction is what each pattern contributes to the work. The names alone do not establish accuracy, safety, or value.

Three patterns answer different questions

ReAct: what should happen next?

ReAct combines reasoning and acting. A language model interprets the task and available observations, selects an action, receives its result, and continues. An action might search a document or query a tool; it need not change anything outside the system.

The original ReAct paper interleaves reasoning with actions and observations. Its reasoning can include making and updating plans, so describing ReAct as “an agent without planning” would be misleading.

AMF’s practical fit test is whether an observation should change the next step. If a catalog search reveals an unfamiliar product code, a second lookup may be useful. If every request always needs the same three lookups, fixed orchestration may be easier to inspect.

An adaptive loop also needs an end. Set limits on tool calls and elapsed time, and define what to return when evidence remains missing.

Reflection: what should change after feedback?

In this article, reflection means examining an output or attempt and using feedback to guide a revision. That feedback could identify a failed requirement, an unsupported statement, or an execution error.

Reflexion, with an “x,” names a specific research framework. The Reflexion paper describes agents that turn feedback into reflective text, retain it in memory, and use it in subsequent trials. This changes the context available to the model rather than updating its learned weights. The paper considers both external and internally generated feedback.

A one-off instruction to “check your answer” does not implement all of that framework. Ask what the check examines, what evidence it uses, and how a detected problem changes the next attempt.

AMF recommends requiring a specific correction, such as “remove the recommendation because the source does not establish compatibility,” rather than accepting a general statement that the work looks good.

Planner–executor: how should the work be organized?

A planner–executor design separates making a plan from carrying out its steps. The planner identifies the work; an executor performs it and returns results. The system may then revise the plan.

LangChain’s implementation description illustrates this division with a multi-step planner, tool-using executors, and a replanning step. It is a vendor’s design example, not independent evidence that planning always improves performance.

Planning is useful when dependencies deserve explicit attention: establish requirements before comparing candidates, or resolve conflicting inputs before drafting a recommendation. A generated plan also needs revision when new evidence invalidates an assumption.

The roles do not require different model brands or a team of autonomous agents. A system can separate planning and execution into stages while using the same underlying model.

They can compose without becoming one big agent team

Consider the responsibilities at different levels:

• Planner: Identify the required outputs and their dependencies.
• ReAct executor: Choose useful tool actions while completing one step.
• Reflection: Diagnose a failed check and propose a targeted revision.

This combination is technically coherent. The Reflexion paper explicitly includes ReAct as an actor option, demonstrating that the concepts are not mutually exclusive.

Composition is an option, not a requirement. AMF’s recommendation is to add a responsibility only when you can explain what would otherwise be missing. A fixed checklist can supply structure without a model-generated plan. A calculation can check arithmetic without an AI critic.

A worked example: recommend compatible equipment

The following scenario and all catalog details are hypothetical. No system was tested.

An office manager wants a recommendation for a docking station that supports two external monitors with a specified laptop. The assistant may read an approved equipment catalog and compatibility guide, then prepare a recommendation. It may not purchase anything.

The supplied documents contain these invented facts:

• The requirement is two external monitors.
• Dock A’s entry confirms only one monitor with this laptop.
• Dock B’s entry confirms two monitors with this laptop.
• Dock C’s entry lists two monitors generally, but does not identify this laptop.

The acceptable output is a supported recommendation, a reason for excluding alternatives, and any unresolved uncertainty.

Here is a small decision card for this task:

Now suppose a draft recommends Dock C because its general entry mentions two monitors. A useful reflection step identifies the missing laptop-specific evidence and revises the recommendation to Dock B. “Be more careful” would not explain the defect.

If the tool returns an additional compatibility record for C, the executor can inspect it and update the comparison. If no such record exists, a second critic’s agreement cannot fill the gap.

For this bounded task, AMF would begin without a separate planning agent. A model-generated plan becomes a candidate when requests vary enough to require different subtasks, such as reconciling several device requirements and identifying which comparisons can proceed independently.

Self-critique needs evidence and limits

Huang and colleagues’ research on intrinsic self-correction found that the tested models struggled to correct reasoning without external feedback and sometimes made their answers worse. The experiments used particular GPT-3.5, GPT-4, GPT-4-Turbo, and Llama-2 configurations on reasoning benchmarks. Those results do not establish a universal limit for every current model or revision task.

The operational lesson AMF draws is narrower: inspect the feedback mechanism. Another model’s confidence is weaker evidence than a source passage that resolves the disputed fact. Even an external check has limits; a compatibility guide may be incomplete or outdated.

Bound the number of revisions. Preserve the original candidate and the reason for each change so a reviewer can see whether the revision fixed a defect or merely changed the wording.

Choose the smallest useful addition

Anthropic’s engineering guidance recommends starting with simple solutions and adding complexity when needed. It also notes the cost and waiting-time tradeoffs of agentic systems. This is vendor guidance, not a measurement of your workflow.

AMF’s proposed next step is to complete this sentence:

“We need this additional stage to solve this specific task difficulty.”

Replace “this specific task difficulty” with a checkable contribution: adapt a lookup, preserve task dependencies, or correct a defined error using evidence. Then compare delivered work, waiting time, resource use, and human correction effort.

Use When Do Extra AI Agents Earn Their Cost? for that comparison. Keep permissions and recovery separate from pattern selection, using A Practical Architecture for Agentic AI Workflows. A more elaborate plan does not grant broader authority.

Provenance

Prepared for Agent Model Fit with AI-assisted primary-source inspection, analysis, and drafting on November 6, 2026. The pattern-selection guidance and equipment decision card are AMF synthesis. The scenario is hypothetical; no implementation, benchmark replication, human review, or measured business outcome is claimed.