Planning patterns for AI agents: ReAct, planner–executor, orchestrator–worker, and beyond

Imagine telling an AI agent: “develop the best plan for increasing the profitability of our trade promotions next quarter.” This sounds like one task. It is not.

To complete it properly, the agent may need to understand the commercial objective, retrieve historical promotion results, estimate baselines, model uplift and cannibalization, retrieve retailer fees, check inventory and capacity, compare scenarios, identify risks, and submit a proposal for approval. Beyond the work itself, it must decide: what work is required, in what order, which tasks depend on others, which can run in parallel, which tools or specialists perform each task, when the plan should change, how progress is evaluated, when the work is complete, and when a human must intervene. This is the domain of agent planning — what connects a high-level goal to an organized sequence of decisions and actions.

Some tasks need no explicit plan; others need a fixed workflow, one adaptive loop, a plan created before execution, dynamic replanning, parallel workers, independent evaluation, branching search, a classical optimizer, or human judgment. There is no single best architecture for every agent.

Agent planning is not about making the model produce the longest plan. It is about choosing the simplest control structure that can reliably move from the current state to the desired outcome.

Planning identifies actions that can move a system from its current state toward a goal, connecting current state, possible actions, expected intermediate states, and the goal state. A good plan accounts for dependencies, constraints, uncertainty, resources, permissions, time, risk, and success criteria — and in an agent, the planner may also choose tools, models, other agents, data sources, human reviewers, and stopping conditions.

Planning also has neighbours it is often confused with. Reasoninganswers “what does this information mean?”; planning answers “what should we do next?” Action selection is the immediate next choice; planning considers a longer horizon. Orchestration coordinates the execution of work the plan decided. A workflow defines the outer structure within which an agent may plan the inner route. A policy defines what is permitted — the model may create the plan, but the harness enforces policy, because a plan is not a security boundary. Scheduling decides when and with which resources; strategy sets priorities that plans translate into action.

Plans themselves vary across dimensions: horizon (one action to a multi-week objective), planning time (before execution, during, after failures, at checkpoints), commitment (fixed to continuously replanned), topology (linear, tree, dependency graph, parallel, hierarchical, event-driven), planner identity (human, code, model, classical planner), execution identity, evaluation method, and replanning triggers. These dimensions are why “agent planning” cannot be reduced to one architecture — and why the patterns below form a spectrum from fixed software to open-ended autonomy, where flexibility, cost, latency, and governance burden all rise together.

1. 01Direct generation. Input → model → output, no plan at all. Right for one-step, verifiable work: summarize, classify, extract, rewrite. A common mistake is adding an agent loop where this is enough.
2. 02Prompt chaining. A predetermined sequence of model calls — extract facts → analyse → recommend — fixed by software. Predictable, modular, debuggable; rigid when cases deviate, and later steps inherit earlier errors.
3. 03Routing. Classify the task and send it to the right process, model, toolset, or human. Enables specialization and model-cost routing; misrouting can corrupt the whole trajectory, so low-confidence cases go to a generalist or human triage.
4. 04Deterministic workflow / state machine. Allowed states and transitions in code — received → validated → analysed → awaiting approval → executed. The model assists inside states but cannot invent unauthorized transitions. For many enterprise tasks, this should be the outer shell around more adaptive planning.

Single-agent adaptive planning

1. 01ReAct. Reason → act → observe → reason again: incremental and reactive, no complete upfront plan. Strong when information is incomplete and each observation shapes the next step; weak when it becomes short-sighted, repeats actions, or loses structure on long tasks. It answers “what should I do next?” — not always “what is the best overall route?”
2. 02Plan-and-solve. Create a plan first, then work through it — a prompting pattern that reduces omitted steps in mainly analytical work, at the risk of following a bad plan too faithfully.
3. 03Plan-and-execute. A planner produces a task list; an executor performs the tasks with tools. Clearer global direction than pure ReAct, visible progress, cost estimation — but plans go stale, so a strong implementation includes replanning.
4. 04Planner–executor with replanning. The plan is not a contract; it is a current hypothesis about the best route. The planner monitors progress and revises when evidence changes (the retailer fee makes 15% unprofitable → simulate lower discounts first). The key design decision is when the planner runs: every action wastes resources, only-on-failure creates drift; milestones and material changes are the usual answer.
5. 05ReWOO (reasoning without observation). Plan all tool tasks and their dependencies before executing any of them (E4 = simulate margin using E1 and E3), cutting the model-call overhead of sequential loops. Efficient when tool needs are predictable; poor initial plans waste the whole batch.
6. 06Dependency graph / compiler-style execution. Represent the plan as a DAG: independent tasks run in parallel, dependent tasks wait for inputs. Research like LLMCompiler shows large latency wins; the costs are graph-generation complexity and recompilation when assumptions break.

Parallel and multi-agent patterns

1. 01Parallelization — sectioning. Split the problem into independent dimensions (financial analysis, supply feasibility, contract review) and combine the outputs. Works only when tasks are genuinely independent; hidden dependencies and inconsistent assumptions are the classic failure.
2. 02Parallelization — voting. Run the same task several times and rank or aggregate. Diversity improves coverage — but the majority can be wrong, agreement may reflect shared model bias, and cost multiplies. Parallelize for independence or genuine diversity, not because more agents are possible.
3. 03Orchestrator–worker. A central agent dynamically decides which subtasks this input needs, delegates to specialist workers, and synthesizes. The central design rule: give each worker a clear objective, scope, context, output schema, budget, and stopping condition — “research this topic” is a weak delegation instruction.
4. 04Manager with agents as tools. The manager calls long-lived specialist agents like tools and keeps the user relationship and final synthesis. One point of control and accountability; one bottleneck that can misdelegate or misinterpret findings.
5. 05Decentralized handoffs. Control transfers between agents — triage → technical → billing → human — like organizational routing. Clear domain ownership, but context loss and handoff loops are real; every handoff needs a structured packet: goal, state, evidence, completed actions, open questions, reason, required next decision.

Quality loops

1. 01Evaluator–optimizer. Separate generation from judgment: generator drafts, evaluator critiques against explicit criteria, generator revises until acceptable. Production teams have found the separation valuable precisely because self-evaluation tends to be lenient — but loops need concrete criteria, maximum cycles, and progress tests.
2. 02Self-refine. One model generates, critiques, and revises its own output. Simple and broadly useful for writing and formatting at low risk; the model may not see its own errors, and critique can rationalize the draft. An optimization loop, not a guarantee of correctness.
3. 03Reflection and Reflexion. Examine an outcome, extract a lesson, store it (Reflexion keeps verbal reflections in episodic memory), and apply it on the next attempt. Learning from trial and error without retraining — but the causal explanation may be wrong, and bad lessons can become persistent memory. Validate reflections before they become procedure.

Search-based planning

1. 01Tree of Thoughts. Propose several candidate paths, evaluate, expand promising branches, backtrack. Right for problems with meaningful intermediate states and evaluable branches — puzzles, design alternatives, structured reasoning — not for every task that is merely difficult. Branching grows expensive fast.
2. 02Graph of Thoughts. Thoughts can branch, merge, and depend on several predecessors. More expressive than a tree, and usually overkill: dependency graphs built in software tend to beat free-form model-generated graphs.
3. 03Language agent tree search. Combines reasoning, actions, environmental feedback, reflection, and tree search over whole trajectories. Powerful in simulations, sandboxes, coding, and games — and unsafe when every branch sends a real email or moves real money.

Grounded, hierarchical, and hybrid patterns

1. 01Classical planner hybrid. The model translates a natural-language goal into a formal planning problem (states, actions, preconditions, effects, constraints); a classical planner finds a feasible or optimal plan; the model explains or executes it. Right for logistics, scheduling, and resource allocation. The model should not replace a reliable optimizer merely because it can produce a plausible schedule.
2. 02Affordance-grounded planning. Score actions by usefulness × feasibility, in the spirit of robotics’ SayCan: “offer a replacement today” is linguistically plausible and operationally impossible when inventory is zero. Do not choose actions on linguistic plausibility alone; check whether the system can actually perform them.
3. 03Hierarchical planning. Strategic objective → workstreams → tasks → tool actions. Direction at the top, execution below — with upward feedback, or lower-level discoveries never reach strategy.
4. 04Event-driven planning. Some agents wait: prepare the proposal, pause for finance approval, resume on the approval event, refresh inventory, continue. Fits real organizational rhythms; the trap is stale state, so critical context must be refreshed after long pauses.
5. 05Human-guided planning. The agent proposes, the human edits priorities, the agent executes bounded work between checkpoints. Right when goals are ambiguous, trade-offs are subjective, or consequences are high. Checkpoints should sit at material decisions, not every trivial tool call.

The strongest enterprise architecture is usually a controlled composition: code for stable rules, routing for classification, planners for decomposition, workers for focused tasks, ReAct for uncertainty, evaluators for quality, humans for judgment, deterministic tools for execution.

The same task changes shape under each pattern. “Evaluate a proposed 15% promotion” becomes a fixed five-step pipeline when every case needs the same checks; a ReAct investigation when the fee discovery changes the route; a visible task list under plan-and-execute; three parallel workstreams when analyses are independent; a dynamically assembled specialist team under orchestrator–worker; a draft-critique-revise loop when completeness matters; and a constrained optimization when inventory, capacity, and deadlines can be formalized.

Three principles for choosing

• Planning should follow uncertainty. Use model-driven planning where uncertainty is high; use deterministic software where the path is known. A standard refund with a clear policy is a workflow; an ambiguous case with conflicting records is an investigative agent.
• Planning should follow consequence. The higher the consequence, the less freedom the model has over final execution. An agent may dynamically plan a financial analysis; it should not dynamically invent the approval process.
• Planning should follow reversibility. Search, simulation, and drafting are reversible; payments, filings, and deletions may not be. Branching exploration belongs in sandboxes, not in systems where every branch has a side effect.

Explore broadly in thought and simulation. Execute narrowly in the real world.

Horizon follows the same logic: short-horizon planning suits fast-changing environments but risks myopia; long-horizon plans give direction but go stale. The practical middle is rolling-horizon planning — high-level long-term direction, the next stage planned in detail, extended after each round of observation. And replanning needs a policy: a plan should change for a reason (failed action, new constraint, contradictory evidence, changed goal, evaluator rejection, no progress) and the change should be recorded — trigger, revision, preserved work — not silently swapped. Constant replanning is itself a failure mode: material change → replan; expected local result → continue; temporary tool error → retry; strategic contradiction → escalate.

Plans also need a representation matched to their job: a natural-language checklist is readable but ambiguous; a structured task list with IDs, dependencies, status, and completion checks is trackable; DAGs suit parallelism, state machines suit control, formal planning languages suit optimization, workflow code suits stable enforcement. A mature agent often produces both a human explanation and a machine-executable plan. On visibility: users benefit from a concise operational plan — goal, workstreams, current task, open questions, approvals — not from raw internal reasoning, which can be verbose, unstable, and unfaithful to the actual decision process.

Planning fails even when every step sounds reasonable. The recurring patterns, with their mitigations:

1. 01Wrong goal optimized. The user wants contribution profit; the plan maximizes revenue. Keep the objective and success metric explicit in state.
2. 02Missing steps. Fees, legal review, capacity, approval omitted. Use required-check templates and context contracts.
3. 03Impossible plan. Actions no tool or human can perform. Plan over the actual capability registry.
4. 04Constraint blindness. Deadlines, budgets, permissions ignored. Structured constraints plus deterministic validation.
5. 05Premature commitment. One strategy chosen before enough information exists. Staged planning and alternative generation.
6. 06Endless planning. Decomposing forever without acting. Planning budgets and required executable next actions.
7. 07Plan drift. The original goal disappears mid-run. Preserve goal and constraints separately from conversation history.
8. 08Stale plan. The environment changed; the agent continues. Validity conditions and refreshed critical data.
9. 09Brittle plan. One failed task collapses everything. Fallbacks, optional branches, recovery policies.
10. 10Excessive replanning. Minor events trigger full replacement. Define material triggers.
11. 11False decomposition. “Independent” workers use incompatible assumptions. Shared inputs and synchronization points.
12. 12Orchestrator bottleneck. Central synthesis drowns in worker output. Structured outputs and hierarchical synthesis.
13. 13Worker duplication. Several workers do the same research. Clear scopes, overlap checks before launch.
14. 14Evaluation loop without progress. “Improve clarity” forever. Concrete criteria, maximum cycles.
15. 15Self-confirming plan. Planner, executor, and evaluator share one mistaken assumption. Independent evidence, separate prompts or models, human review.
16. 16Planning hallucination. Nonexistent tools, invented approvals, imaginary policies. Ground planning in actual capability and state.
17. 17Planning laundering. The plan looks rigorous because it is structured and professional, while its assumptions are unverified. Require every major task to name its evidence, assumptions, and completion conditions.
18. 18Cost explosion. Planners × workers × evaluators × branches. Budgets, worker limits, model routing, early stopping.
19. 19Unsafe execution. The planner proposes a consequential action and the executor just does it. Separate planning → policy validation → approval → execution.
20. 20No completion definition. More analysis is always possible. Required evidence, acceptable confidence, maximum effort, stopping conditions.

A production planning system runs goal and success criteria through constraints and policy, a planner, a plan validator, a scheduler and orchestrator, executors, environment feedback, and an evaluator that decides to continue, revise, escalate, or finish. The centerpiece is the plan object — no longer prose but structure:

task_id:          T3
objective:        Run margin simulation
depends_on:       [T1, T2]
assigned_executor: margin_service
permission_scope: read_only
status:           pending
completion_check: simulation result stored
failure_policy:   retry once, then escalate

Before execution, the harness validates: does every tool exist? Are dependencies acyclic? Are actions permitted, deadlines feasible, side effects sequenced safely, approvals represented? A model-generated plan is proposed configuration, not unquestioned truth. Progress is then monitored against the environment — planned “retrieve contract,” observed “no current contract found” means the task is not complete — and budgets (planning revisions, workers, searches, runtime, approval gates) turn open-ended autonomy into bounded execution.

Planning also touches every discipline in this series. Context engineering: the planner needs goal, state, constraints, and capabilities in summary form, while the executor needs detailed evidence for one task — different roles, different context. Memory: past procedures and failure patterns inform planning, but memory should inform, not dictate — “Retailer A usually accepts 15%” loses to the current contract. Tools: a task should not appear in a plan unless a tool, human, or system can actually perform it, and tool metadata (latency, cost, risk, reversibility) makes planning operationally meaningful. And commitments a plan creates — follow up tomorrow, rerun after new data — must become workflow tasks, scheduled events, and monitored conditions. A plan that is not operationalized is only a proposal.

Evaluating agent planning

Evaluate at six levels: plan quality (goal addressed, critical steps present, dependencies correct, assumptions explicit), execution quality (right tools, right parameters, controlled side effects), adaptation quality (replanned when necessary, not more), efficiency (calls, tokens, workers, repeated work), safety and governance (permissions respected, approvals requested, injection resisted, trajectory auditable), and outcome quality — the reservation exists, the refund happened once, the code passes tests. Useful metrics include goal completion, plan feasibility, critical-step coverage, replanning precision and recall, redundant-work rate, escalation accuracy, budget adherence, and plan stability. And the test suite should include the awkward cases: missing information, unavailable tools, changed constraints, contradictory evidence, impossible goals (the correct outcome is to explain the limitation), approval boundaries, hidden dependencies, prompt injection, loop traps, and irreversible actions.

TiMiNa’s PLANWISE framework walks eight questions that map a task to a pattern:

1. 01Predictability. Highly predictable route → workflow or state machine. Partially → hybrid. Unpredictable → ReAct or adaptive planner.
2. 02Length and dependencies. One step → direct generation. Linear steps → prompt chain. Many dependent tasks → plan-and-execute or graph. Long hierarchy → hierarchical planning.
3. 03Adaptability required. Low → plan once. Medium → milestone replanning. High → ReAct or continuous adaptation.
4. 04Need for exploration. Low → linear plan. Moderate → generate and rank options. High → tree or graph search in a safe environment.
5. 05Work parallelism. None → sequential. Predefined → parallel sectioning. Dynamically discovered → orchestrator–worker.
6. 06Impact and reversibility. Low and reversible → more model autonomy. High or irreversible → deterministic controls and human approval.
7. 07Success criteria. Deterministic result → automated evaluator. Clear qualitative criteria → evaluator–optimizer. Ambiguous strategic judgment → human review.
8. 08Environmental feedback. Strong → ReAct, testing, tree search thrive. Weak → conservative planning and limited autonomy.

Ten principles for planning AI agents

1. 01Start with the simplest workable pattern. Not a multi-agent tree search when a workflow will do.
2. 02Separate goals from plans. The goal stays stable even when the plan changes.
3. 03Plan over real capabilities. No imaginary tools, data, or authority.
4. 04Use code for known rules. Model reasoning should not replace deterministic policy or calculation.
5. 05Replan only after material change. Constant replanning creates instability and cost.
6. 06Explore in safe environments. Branch broadly in simulation, not through irreversible actions.
7. 07Parallelize genuinely independent work. More workers do not automatically produce a better result.
8. 08Separate generation from evaluation when quality matters. Self-evaluation alone is often insufficient.
9. 09Verify progress through the environment. A completed task produces an observable state change or validated artifact.
10. 10Keep humans at consequential decision boundaries. Agent planning informs human judgment without silently replacing accountability.

Is ReAct a planning pattern?

Yes — an incremental one. The model reasons, acts, observes, and chooses the next step, discovering the route through interaction rather than planning it upfront.

How is orchestrator–worker different from parallelization?

In basic parallelization, subtasks are known in advance. In orchestrator–worker, the orchestrator determines the required subtasks dynamically for each input.

What is the difference between Self-Refine and evaluator–optimizer?

Self-Refine uses the same model to generate, critique, and revise. Evaluator–optimizer uses a separate evaluator with independent instructions, models, or criteria — which matters because self-evaluation tends to be lenient.

Should every agent create a plan before acting?

No. Upfront planning can waste time or go stale in uncertain environments. ReAct or a fixed workflow may be better, depending on the task.

When is a fixed workflow better than an agent planner?

When the route is stable, rules are known, reliability matters, and adaptive decision-making adds little.

Do more agents improve planning?

Not automatically. Multiple agents add context separation and parallelism — and coordination cost, conflicting assumptions, and latency.

How often should an agent replan?

After material changes: failed actions, new constraints, contradictory evidence, changed goals, evaluator rejection. Not after routine observations.

Should users see the agent’s plan?

A concise operational plan — goal, progress, open questions, approval points — yes. Raw internal reasoning, no.

What is the biggest planning mistake?

Treating a detailed model-generated list as an executable, reliable plan without validating capabilities, dependencies, constraints, and success conditions.

Planning is what connects intelligence to coordinated work. A model may understand the goal, tools may provide the ability to act, context may provide the information, and memory may preserve experience — but the system still needs to decide what happens first, what depends on what, what runs in parallel, who performs each task, how progress is verified, when the plan must change, and when a human must decide. The field offers many patterns, and none is universally best: each trades predictability, flexibility, cost, latency, exploration, control, and safety differently.

The key design question is not “how autonomous can we make this agent?” but “what planning structure gives this system enough flexibility to handle uncertainty while preserving the control the task requires?” For predictable work, workflows. For uncertain next steps, ReAct. For long tasks, explicit plans with replanning. For independent workstreams, parallelization. For dynamically discovered subtasks, orchestrator–worker. For refinable outputs, evaluator–optimizer. For constrained operational problems, formal planners. For consequential decisions, human authority. The most capable enterprise agent will rarely use one pure pattern — it combines them deliberately: code defines stable boundaries, models navigate uncertainty, tools connect decisions to systems, evaluators check quality, humans govern consequences.

Good planning is not measured by how elaborate the architecture appears. It is measured by whether the system reaches the right outcome through a route that is efficient, adaptable, safe, and understandable.