II · Planning & Control FlowMature★★

Plan-and-Execute

also known as Plan-Then-Execute, Outline-Then-Run

Plan all the steps once with a strong model, then execute each step with a cheaper model under the plan.

Context

A team runs an agent on a task that decomposes into several mostly-known steps — book a venue, then a restaurant, then send invitations — and a strong, expensive model is available alongside a cheaper, faster one. The team would like to use the strong model where its judgment matters (deciding the steps and their order) and the cheaper model where it does not (typing each step's tool call). The world is stable enough that a plan written once is still good a few minutes later.

Problem

A ReAct loop (reason-act-observe) runs the strong model on every single step, including trivial ones where the next action is obvious, so it pays full price for routine execution. Hand-coding the workflow gives up the agent's ability to handle small surprises. Without an inspectable plan emitted before any tool fires, reviewers cannot see what the agent intends to do until it has already partially done it, and a wrong assumption near the start cannot be caught until the run produces a bad result.

Forces

  • Planning quality depends on context the planner has at planning time.
  • Execution may discover the plan was wrong; replan-versus-fail is a real choice.
  • Cheaper model may not faithfully execute the plan.

Example

An office-assistant agent is told, 'Book a team offsite in Barcelona for ten people next month, find a restaurant for dinner, and email everyone the schedule.' Up front it writes a five-step plan: search venues, pick one, search restaurants, pick one, send emails. The executor walks the plan in order. Because the venue list does not depend on what restaurants exist, planning once is cheaper than re-thinking every step.

Diagram

Solution

Therefore:

Two-stage loop. Planner: produce an ordered list of steps with explicit dependencies. Executor: run each step (often with tools) and accumulate results. On failure or surprise, replan with the new evidence in context.

What this pattern forbids. The executor cannot deviate from the current plan without raising a replan request.

The smaller patterns that complete this one —

  • generalisesReWOO·— Plan a complete dependency DAG with placeholder variables before any tool runs, then execute and substitute observations into the plan.
  • generalisesPlanner-Executor-Observer★— Add an explicit Observer role between Planner and Executor so progress is checked against the plan instead of trusted blindly.
  • generalisesGoal Decomposition★★— Decompose a goal into sub-goals recursively until each leaf is directly actionable.
  • generalisesOuter-Inner Agent Loop·— Run two nested loops: an outer planner agent decomposes the goal into subtasks; an inner executor runs a ReAct loop on each, and the outer can replan based on the inner's progress.
  • usesControl-Flow Integrity★— Treat the agent's planned step sequence as a trusted control-flow graph that tool outputs, retrieved content, and user-supplied data cannot redirect at runtime.
  • generalisesPlanner-Executor-Verifier (PEV)★— Triadic specialization where a planner produces the plan, an executor runs it, and a separate verifier checks each step's effects against the original goal.

And the patterns that stand alongside it, or against it —

  • alternative-toReAct★★— Interleave a single thought, a single tool call, and a single observation per step so the agent reasons over fresh evidence.
  • complementsStep Budget★★— Cap the number of tool calls or loop iterations the agent is allowed within a single request.
  • complementsStructured Output★★— Constrain the model's output to conform to a JSON Schema (or similar typed shape).
  • alternative-toOrchestrator-Workers★★— An orchestrator dynamically breaks a task into subtasks at runtime and delegates each to a worker LLM, then synthesises results.
  • complementsLeast-to-Most Prompting★— Decompose a hard problem into an ordered list of easier subproblems, then solve them sequentially with each answer feeding the next.
  • complementsReplan on Failure★★— Trigger a fresh planning step when execution evidence contradicts the current plan.
  • complementsPassive Goal Creator★— Analyse the user's articulated prompts and accompanying context to derive a precise, actionable goal before any planning or tool use begins.
  • complementsPre-Flight Spec Authoring★— Before any code is generated, author a multi-pillar spec and have the agent critique it for ambiguity and edge cases, so that the loop executes against a reviewed target rather than a fresh prompt.
  • alternative-toHybrid HTN + Generative Agent★— Hierarchical Task Network decomposition provides the procedural backbone; the generative LLM is invoked only at leaf nodes for the parts of the task that are genuinely open-ended.
  • complementsSingle-Path Plan Generator★★— Generate one linear sequence of intermediate steps from current state to goal — the lightweight planning alternative to tree-of-thoughts and multi-path generation.
  • alternative-toBPMN/DMN Deterministic Shell Around Agent★— BPMN processes and DMN decision tables form the deterministic spine; LLM-driven agents are invoked only at explicit 'unstructured problem' nodes inside the process.
  • alternative-toIncremental Model Querying★★— Generate plan steps by sequentially querying the model at each step rather than producing the whole plan upfront in one call.
  • complementsBDI Agent★★— Agent maintains explicit Beliefs about the world, Desires (goals), and Intentions (committed plans), and reasons by reconciling the three.
  • alternative-toAgentic Behavior Tree·— Borrow the behavior-tree formalism: leaves are LLM calls or tools that return success/failure; a tree of selectors and sequences orchestrates control flow.
  • alternative-toBehavior Tree Back Chaining·— Construct an agent's behavior tree starting from the desired goal condition and recursively adding child nodes whose post-conditions satisfy each parent's pre-conditions.
  • alternative-toPartial Global Planning·— Each agent maintains a partial view of others' plans and incrementally merges local plans into a shared partial global plan, interleaving coordination with execution.
  • alternative-toQuery-Decomposition Agent★★— An agent whose explicit job is to split an incoming user query into smaller independent sub-queries that can be answered sequentially or in parallel, then merge results.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in recipes

Used in frameworks

Show 19 more

References

Provenance