The Plan-and-Execute Pattern

What You Will Learn

Why planning and execution are separated.
How plans become steps.
When replanning is necessary.

How to read the evidence

The refund-agent numbers repeated from Module 5 are publisher-reported by FutureAGI rather than an independently reproducible benchmark. They compare two shapes in one described scenario but do not establish a general 87% to 95% improvement. LongDS-Bench’s 48.45% and nearly 47-point degradation belong to its multi-turn data-science setting.

Module 5 ended with a real, unresolved thread: a refund agent’s ReAct loop, degenerating into 14-second, 19-tool-call spirals on 11% of requests, fixed by switching architectures entirely. This module is that fix, in full.

Returning to where Module 5 left off

The team’s actual change: a planner emits the full sequence upfront — “check policy, look up order, calculate refund, escalate if over $500” — and an executor runs each step exactly once, never re-deciding what to do next based on a fresh reasoning pass. (FutureAGI, Agent Architecture Patterns in 2026)

The measured result, worth restating precisely: 95% of requests now finish in 2.1 seconds, with the remaining 5% escalating cleanly rather than looping. That’s the entire pattern this module covers, already proven in a real production system before a single diagram appears below.

The architecture

Goal
 ↓
Planner
 ↓
Plan

1. Research
2. Analyze
3. Implement
4. Test

 ↓
Executor
 ↓
Result

The genuine architectural claim is worth stating precisely: “the plan is a single artifact you can audit; execution is deterministic once the plan is fixed; the trace shows planner output as a distinct span before any side effect.” (FutureAGI) That auditability is the real, structural advantage ReAct’s step-by-step reasoning doesn’t offer — a Plan-and-Execute system’s plan is something a human, or a gate, can review before anything in the world actually changes.

Three named variants

It’s worth knowing this isn’t one monolithic pattern — three genuinely distinct, academically-cited shapes ship in real 2026 systems, each making a different choice about how much reasoning happens after the initial plan.

Vanilla Plan-and-Execute — the shape shown above. A plain, ordered list of steps, executed one at a time, with a re-planner consulted between batches. Simplest to implement, and the right fit for tasks like code migration or form-filling where the steps are genuinely knowable in advance.

ReWOO (Reasoning WithOut Observation, Xu et al., 2023) — the plan includes placeholder variables instead of committing to specific values upfront — a step reading “search the web for $RESULT_OF_STEP_2” — and the executor fills them in by actually running the tools, without ever re-engaging the reasoning model at all. Reasoning happens exactly once, at planning time. The cost saving is genuinely dramatic specifically when the plan’s structure is stable even though its specific values aren’t known yet.

LLMCompiler (Kim et al., 2023) — the plan is emitted as a directed acyclic graph with explicit dependencies between steps, not just a flat list. This is the same real academic lineage your Multi-Agent Systems coursework’s parallelization research traced back to — a plan that knows which of its own steps are genuinely independent can execute them concurrently, rather than treating every plan as inherently sequential.

(Encyclopedia of Agentic Coding Patterns, Plan-and-Execute)

Cost of staleness

This is worth grounding in real, dated, measured evidence, because “plans can go stale” is too vague on its own to design against.

A May 2026 benchmark, LongDS-Bench, built on real-world Kaggle notebooks, measured exactly this failure. Agents needed to maintain intermediate results, revise earlier work, and carry dependencies from one step to the next across multi-turn analytical tasks. The best-performing model reached only 48.45% average accuracy, with performance dropping nearly 47 points from early turns to late turns. (Snowflake, AI Agent Planning)

Read this precisely: this isn’t a model failing to plan at all — it’s a model’s plan-following accuracy collapsing specifically as the task stretches across more turns, exactly the shape “staleness” actually takes in practice. An agent can generate genuinely reasonable next steps while quietly losing track of the analytical state needed to complete the larger goal it originally committed to.

Planning failure propagation

This is worth knowing as a precisely named concept, not just an intuition. “If the planner creates a weak plan, the entire workflow suffers… if the planner forgets a key step, the executor never corrects it.” (Chapter 4: Agent Architecture — Patterns That Scale, Medium)

This is directly the same structural risk your Multi-Agent Systems coursework measured precisely for hub-position failures — a mistake at the planning stage doesn’t stay contained to one step, it propagates to everything the executor does afterward, because the executor has no independent basis for questioning a plan it was told to follow.

Concrete replanning example

It’s worth seeing the replanning loop applied to a genuinely realistic scenario rather than left abstract:

Plan
 ↓
Execute Step 1: Research Competitor A
 ↓
Unexpected result: Competitor A was acquired last month
 ↓
Replan: remove Competitor A, add the acquiring company instead
 ↓
Continue with revised remaining steps

The first research step’s finding — a genuinely unexpected fact the planner had no way to know upfront — invalidates part of the original plan without invalidating all of it. A rigid executor, following the original plan blindly, would waste effort analyzing a company that no longer meaningfully exists as a competitor. The replanning loop is what catches this and revises specifically the parts of the plan the new information actually affects. (GenAI Patterns, Plan and Execute)

Heuristic for over-planning

It’s worth taking this warning as seriously as the case for the pattern itself: “Some tasks do not decompose neatly into sequential steps. Forcing a detailed plan on an inherently exploratory task adds overhead without benefit… If you find yourself replanning more often than executing, the task might be better suited to a reactive approach.” (GenAI Patterns)

This is worth connecting directly back to Module 5: the refund-agent case study succeeded specifically because the actual task — verify policy, look up order, calculate refund, escalate above a threshold — genuinely decomposed into a fixed, knowable sequence. A task that doesn’t share that property, where nearly every step reveals something that changes the next one, is exactly the ReAct-favoring case Module 5 already covered, not a Plan-and-Execute candidate at all.

The trade-offs, side by side

It’s worth summarizing the genuine comparison explicitly, since both patterns solve overlapping problems with genuinely different cost profiles.

	ReAct	Plan-and-Execute
Reasoning frequency	Every single step	Once upfront, plus replanning when triggered
Auditability	Harder — reasoning is interleaved with action	Easier — the plan is one inspectable artifact
Cost per task	Scales with iteration count, uncapped by design	Lower when the plan is stable; replanning adds cost back
Best fit	Next step genuinely depends on the last observation	Steps are knowable in advance, even if specific values aren’t
Real measured result	87% clean / 11% looping / 2% timeout (refund agent)	95% clean / 5% clean escalation (same task, re-architected)

Neither pattern is universally better — the refund agent’s own numbers are the clearest possible evidence that the same task, given the wrong architecture, produces measurably worse outcomes than the same task given the right one.

Production replanning mechanics

It’s worth knowing how a genuine replanning loop actually gets implemented, not just described. Current research on resilient plan-then-execute systems describes the concrete mechanism: after the executor runs a step, a re-planner LLM assesses the current situation and decides one of three things — continue with the existing plan, generate a genuinely new plan to overcome an obstacle, or determine the task is already complete. (Architecting Resilient LLM Agents, arXiv)

In practice, this is implemented as a dedicated replan node added after the executor node in a graph-based framework, with conditional edges routing execution either back to the executor — carrying a potentially revised plan — or forward to the end of the workflow. The same source’s own framing is worth taking as this module’s real closing argument: this transforms the agent “from a rigid automaton into a resilient problem-solver.”

The efficiency benefit worth knowing

It’s worth understanding exactly why separating planner from executor saves real cost, beyond the general specialization argument. The planner needs the full task description and current progress state — it does not need the detailed execution traces of every tool call the executor made. The executor needs its current step’s instructions and relevant tool outputs — it does not need to carry the entire plan in its own context. (GenAI Patterns)

Each role genuinely gets a focused context window with only what it needs — directly Module 2’s specialization argument from your Multi-Agent Systems coursework, now shown producing a concrete, measurable token-efficiency benefit rather than just a cleaner architecture on paper.

What this looks like in code

Before reading the syntax, follow the execution flow: identify the incoming state, the component making the decision, the function doing the work, and the condition that returns a result or stops the loop. The code is a small teaching model of the pattern, not hidden framework magic.

def plan_and_execute(goal: str, max_replans: int = 3) -> str:
    plan = planner(goal)
    replan_count = 0

    step_index = 0
    while step_index < len(plan.steps):
        result = executor(plan.steps[step_index])

        if result.unexpected and replan_count < max_replans:
            plan = replanner(goal, plan, completed_up_to=step_index, new_info=result)
            replan_count += 1
            continue  # resume against the revised plan

        step_index += 1

    return synthesize(plan)

max_replans is this module’s direct answer to the over-planning heuristic above — a task that keeps triggering replans until it hits this cap is honest, structural evidence the task was never a good fit for this pattern in the first place, worth surfacing as a signal, not silently absorbing forever.

Applying this to a concrete scenario

It’s worth extending the competitor-analysis example from earlier in this module all the way through, since it shows every concept here working together. A market-research task decomposes into: identify competitors, analyze each one’s positioning, synthesize a report. The planner emits this as a Vanilla Plan-and-Execute list — four named competitors, one analysis step each, one synthesis step.

Step one’s execution reveals Competitor A was acquired last month. This is genuinely unexpected information the planner had no way to know when it built the original plan — exactly the trigger this module’s replanning loop exists for. The re-planner doesn’t discard the whole plan; it revises specifically the parts the new information actually touches, removing Competitor A’s now-irrelevant standalone analysis and adding the acquiring company instead, while leaving the other three competitors’ steps untouched.

Now run this same scenario against the over-planning heuristic. If this pattern held for three consecutive research projects and each one triggered two or fewer replans across five steps, that’s a genuine, healthy signal the task fits this pattern well. If a later research task started triggering four or five replans per five-step plan, that would be the honest signal this module described — the task’s actual structure has drifted into something closer to ReAct’s territory, where each step’s finding is likely to redefine the next one, and a rigid upfront plan is fighting the task’s true shape rather than fitting it.

Interview-relevant framing

Q: When would you choose Plan-and-Execute over ReAct for the same underlying task?

Ans: When the task’s actual steps are genuinely knowable in advance, even if their specific values aren’t — Module 5’s refund agent is the clearest real example: check policy, look up order, calculate refund, escalate above a threshold, is a fixed sequence regardless of which specific policy or order comes in. ReAct fits better when the next correct step genuinely can’t be enumerated until you’ve seen the previous result. A real 2026 case study showed switching an agent from ReAct to Plan-and-Execute taking clean resolution from 87% to 95%, specifically because the task’s structure had been the right fit for this pattern all along.

Q: How do you prevent a Plan-and-Execute system from blindly executing a plan that’s gone stale?

Ans: With an explicit replanning loop — a re-planner that runs after each step and can decide to continue, revise, or conclude the task is done, rather than assuming the original plan stays valid throughout execution. A real benchmark measured just how badly this fails without it: agents on real, multi-turn analytical tasks dropped nearly 47 accuracy points from early turns to late turns, precisely because they kept following an increasingly outdated plan instead of genuinely incorporating what they’d already learned.

Q: How would you know a task isn’t actually a good fit for Plan-and-Execute?

Ans: By watching the replan rate. If a task keeps triggering replans more often than it actually executes steps cleanly, that’s a real, honest signal the task doesn’t decompose into a stable sequence in the first place — it’s closer to Module 5’s ReAct territory, where the next step genuinely depends on what was just observed. Forcing a rigid upfront plan onto a task like that adds real overhead — tokens spent producing a plan that needs heavy revision after nearly every step — without the auditability benefit the pattern is actually supposed to provide.

Common Misconception

Incorrect idea: A complete initial plan remains correct until the task finishes.

Why it is incorrect: Tools fail and conditions change, so execution results must be checked and important changes sent back for replanning.

Key takeaways

Plan-and-Execute is the real, documented fix for Module 5’s refund-agent failure — separating planning from execution took clean resolution from 87% to 95%, because the task’s actual steps were genuinely knowable in advance.
Three real, distinct, academically-cited variants exist: Vanilla Plan-and-Execute (a flat ordered list), ReWOO (placeholder variables filled without re-engaging reasoning), and LLMCompiler (a dependency-aware DAG enabling concurrent execution).
A real May 2026 benchmark on genuine Kaggle-based analytical tasks measured the stale-plan problem precisely — the best model’s accuracy dropped nearly 47 points from early to late turns as tasks stretched across more steps.
Planning failure propagation is a genuine, named risk: a weak or incomplete plan corrupts everything the executor does downstream, since the executor has no independent basis to question a plan it was told to follow.
Separating planner from executor produces a real, measurable token-efficiency benefit — each role gets a focused context window containing only what it actually needs, not the full plan or the full execution trace.
A genuine, honest heuristic for misfit: if a task triggers more replanning than clean execution, it likely belongs in ReAct’s territory instead, not this pattern’s.
Real production replanning is implemented as a dedicated replan node with conditional routing back to the executor or forward to completion — transforming a rigid, one-shot plan into a genuinely resilient, adaptive one.

Module 7 covers the pattern for catching mistakes after execution rather than preventing them beforehand — the self-critique loop this course has referenced but not yet taught directly: Reflection.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026