8 — Plan-and-Execute Pattern

Concept overview

The plan-and-execute pattern creates an explicit task plan before carrying out its steps. The planner proposes objectives, dependencies, tool requirements, and acceptance criteria; the executor performs approved steps and records observations. A plan is a hypothesis about how to finish the task, not permission to perform every conceivable action.

Separating these roles makes long tasks inspectable and allows deterministic validation before expensive or consequential work begins. Plans should contain bounded operational steps rather than hidden reasoning transcripts. Replanning is triggered by specific evidence, such as a failed prerequisite or a changed business constraint, and must preserve already completed side effects.

Why it matters in production

Proof of concept

A prototype can render a plan for review and execute it sequentially. Compare success and cost against a simple reactive loop on the same tasks.

Production

Production validates tool availability, permissions, dependencies, budgets, and acceptance criteria before dispatch. Plans and executions receive separate versions so the history remains interpretable after revision.

Enterprise scale

At enterprise scale, reuse safe plan fragments and schedule independent steps concurrently. Bound replanning attempts and reserve enough budget for validation, reconciliation, and final delivery.

Architecture components

Planner

Proposes an ordered or dependency-based set of bounded steps and completion tests.

Plan validator

Rejects unavailable tools, illegal actions, impossible dependencies, and excessive budgets.

Executor

Runs approved steps using scoped credentials and stable operation identifiers.

Observation ledger

Stores actual results, evidence, and side effects separately from planned intentions.

Replanner

Revises unfinished work when a specific observation invalidates an assumption.

The architecture, mapped

flowchart LR
 G["Completion criteria"] --> P["Planner"]
 P --> V["Plan validator"]
 V --> E["Controlled executor"]
 E --> O["Observation ledger"]
 O --> C["Acceptance check"]
 C --> D["Final evidence package"]
 O --> R["Bounded replanner"]
 R --> V
 A["Policy and tool registry"] --> V

Runtime flow

1. 1

   Define completion

   Translate the request into measurable output requirements and explicit excluded actions.

2. 2

   Draft plan

   Propose steps with inputs, prerequisites, expected artifacts, and estimated resource demands.

3. 3

   Validate feasibility

   Check permissions, dependency integrity, tool contracts, and overall time and cost ceilings.

4. 4

   Execute ready steps

   Run only approved steps whose inputs are available and record their actual outcomes.

5. 5

   Reconcile deviation

   Classify unexpected results as retryable, plan-invalidating, or requiring human judgment.

6. 6

   Revise and deliver

   Version any changed plan, preserve completed effects, and verify final acceptance criteria.

Preparing a production-line changeover

Manufacturing · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A factory schedules a product change requiring tooling checks, recipe validation, material availability, and maintenance coordination.

The problem

A reactive assistant repeatedly asks for data already collected and can overlook a prerequisite before proposing the changeover.

Agent requirement

The assistant must produce an executable preparation package while keeping machine-control actions under existing operational authority.

Architecture

A planner creates prerequisite checks, a validator checks available systems and access, and an executor gathers signed-off evidence.

Runtime

• The maintenance planner requests a changeover package; the agent checks tooling and materials in parallel after validating the plan.
• An unavailable fixture invalidates the original schedule, so the replanner revises only the remaining timing and alternative-tooling steps.

Failure scenario

If a work-order creation result is uncertain, execution pauses for reconciliation instead of planning another identical work order.

Operational impact

Evaluate prerequisite coverage, unnecessary tool calls, revision frequency, and analyst corrections rather than assuming longer plans improve reliability.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Treating a plan as an approval

Authorize consequential operations at execution time.

Using vague steps such as investigate everything

Require bounded inputs, outputs, and completion criteria.

Discarding the old plan after revision

Retain plan versions and link each executed step to its source.

When to choose this pattern

Choose it when

• Tasks involve several dependencies and identifiable completion criteria.
• Users benefit from reviewing proposed actions before execution.
• New evidence can invalidate only part of a long workflow.

Avoid it when

• One tool call can reliably complete the request.
• The environment changes faster than a plan can remain useful.
• Step completion cannot be assessed independently.

Architecture checklist

• Define task-level acceptance criteria.
• Validate all referenced tools before execution.
• Version plans separately from observations.
• Reserve a budget for bounded replanning.
• Preserve completed side effects across revisions.
• Test impossible and partially completed plans.

Related concepts

• 2 — Directed Acyclic Graphs (DAGs)
• 9 — ReAct Framework (Reasoning + Acting)
• 13 — Sub-Goal Generation
• 41 — Idempotent Tool Execution
• 46 — Max Iterations Fallback

Primary references

• LangGraph: workflows and agents