Pattern Matrix/White Paper/A2

A2 · Plan-and-Execute

What problem it solves

In long tasks, a step-by-step reactive (ReAct) agent is almost certain to fail. An HR recruiting agent exposed all 17 tools to the model and let it decide each step freely. The result: it sent a rejected candidate's compensation to the hiring manager, skipped the background check and issued the offer directly, and queried the same compensation record 50 times over. The root cause is that the agent has no complete plan—the context window cannot hold the full picture of a 12-step recruiting process, so the model can only decide the next step based on "what just happened in the previous step," with no global view.

Plan-and-Execute splits the action side into two phases: plan first, then execute. The planning phase lays the task out in one pass as an ordered sequence of steps, marking dependencies, resources, and the nodes that require human review; the execution phase advances against the plan. Its value is in taking the macro-level ordering out of the model's in-the-moment judgment and pinning it into an auditable plan.

Why the coordinate is "Action × Orchestrate"

• Vertical axis · Action: the agent does not execute a single step; it turns a goal into a sequence of outward actions. The two-phase "think first, then act" belongs to the action side, not the single-point thinking of the reasoning side.
• Horizontal axis · Orchestrate: the center of Plan-and-Execute is an orchestrator—it holds the complete plan, schedules each step along the dependency graph, maintains global state and checkpoints, and does local replanning when things drift. This differs from the pure chaining of prompt chaining (A3): A3 is a linear hand-off where the previous segment's output feeds the next, whereas A2 is a central node coordinating multiple steps, where independent steps can expand in parallel, key nodes drop checkpoints, and errors can roll back and replan. This layer of coordination and recovery is exactly what distinguishes Orchestrate from Chain.

Core mechanism

The core of Plan-and-Execute is not complexity but three things: separation, an approval gate, and context reset. The core of Aider's architect mode covers all three in just 9 lines of code—the architect produces the plan, the editor clears its context and then executes the plan, and by default the user confirms in between.

Several key designs matter in engineering practice:

• Heterogeneous models: the plan phase needs deep reasoning, so use a strong model; the execute phase is structured and verifiable, so a mid-tier model is enough and is 5 to 15 times cheaper. In Aider's SWE-bench testing, a strong model for planning plus a mid-tier model for execution was 3 to 5 points more accurate than using the strong model alone, at 40% lower cost.
• The plan is a user-owned artifact: Claude Code writes the plan to a file rather than keeping it in the prompt. A file is an audit log by nature—it can be reviewed by multiple people, versioned, and diffed; the user reads from the file and the agent reads from it too.
• Local replanning: when the plan halfway through conflicts with reality, change only the affected parts and leave committed steps untouched. Anthropic's engineering rule of thumb is to check every 5 steps whether the plan still holds, with each replan budgeted at no more than 10% of the total.

Research data confirms the economics of this paradigm. ReWOO compresses the plan-execute LLM calls down to 2 (one for planning plus one for synthesis), with all intermediate tool calls executed in parallel without going through the model; compared with the ReAct paradigm, it is 5 times more token-efficient and 4 points more accurate.

Where it fits in production

• Where a clear goal, enumerable steps, and side-effect sensitivity stack together: HR recruiting, credit approval, operations changes.
• Compliance scenarios with hard process constraints: for example, "the background check must come before the offer." Such constraints can be encoded into a plan validator that rejects a violating plan during the planning phase.
• Long tasks that need crash recovery: write a checkpoint at each step, resume from the checkpoint after a crash, and design plan-execute as a recoverable transaction.

Where it tends to break

• Plan ossification: once the plan is written, the executor runs straight through; some step midway returns an unexpected result (a candidate withdraws, a schema changes, an external API changes its protocol), the planner does not intervene in time, and all subsequent steps are wasted computation. The remedy is to do an alignment check every N steps between the current subtask and the original goal.
• Plan thrashing: replanning fires too often, every failure triggers a rewrite, and the agent is forever planning and never executing. The remedy is a hard cap on replans plus a replan budget ceiling.
• Stale context accumulating quietly: long-task state held as free-form notes easily becomes "still parseable on the surface but semantically broken." The remedy is to strictly type state with a JSON schema so partial corruption surfaces early.
• Cache friendliness ignored: if each plan-execute step invalidates the cache, cost can spike about 10 times. Manus does a structural update rather than append-only when rewriting todo.md, precisely to keep the prefix stable and hit the cache.

Key metrics

• Long-task success rate / error rate (healthy zone error rate <1%): the HR recruiting case dropped from 8.3% to 0.4%. This is the direct signal of whether the plan is working.
• LLM calls per task (lower is better, and it should be stable): the case dropped from an average of 47 per candidate to 13. Calls spiraling out of control usually means replanning is thrashing.
• Replan frequency (healthy zone is about once every 5 steps): too high is thrashing; staying at zero long-term is an early sign of ossification.
• Cache hit rate (healthy zone is the higher the better): called by the Manus team the single most important metric for a production agent, as it directly determines per-token cost.

Minimal implementation skeleton

plan = planner(goal, context)            # strong model, once
            if user does not approve → return
            while plan is not complete:
                ready = steps in plan whose dependencies are satisfied   # topological order
                execute ready in parallel:
                    success → mark completed, write checkpoint
                    failure → replan (bounded by MAX_REPLANS)
                every N steps → adaptive replan check whether the plan still holds
            return plan + full execution trace
            

Engineering points: inject Planner, Executor, and Approval as dependencies, letting the business decide the concrete models and prompts; register a saga inverse for destructive steps; write the plan to a file and version it.

Enterprise example

Liang Bo's team explicitly separated the "strategic-layer plan" from the "tactical-layer execution." Under the Plan-Exec pattern, once the planning layer writes the plan into the Workspace's DAG, the scheduler advances by dependency relations and no longer relies on the LLM to re-select the path step by step. This directly solves ReAct's structural problem—ReAct calls the LLM again to decide at every step, so the macro execution order cannot be engineered and pinned down, and a long task can drift at any moment. Once the order is fixed into the DAG, the model only fills in parameters and interprets results within a single step, while the macro flow is handed to the deterministic scheduler; only then are the reliability and cost of long tasks both controllable. Applied to the HR recruiting case: after rewriting it into the three segments of Planner plus Executor plus Approval Gate, the monthly bill dropped from 180,000 to 60,000, and the hiring cycle was compressed from 23 days to 16.

Relationships to other patterns

• Prompt chaining (A3): a dual pair, one heavy and one light. A2 is a complete plan plus DAG parallelism plus replanning; A3 is linear chaining with no replanning. The most common form in production is A2 on the outside and A3 on the inside—each planned subtask runs a prompt chain internally.
• Tool dispatch (A1): each execution step in A2 internally does one round of A1 tool selection. The idea of using heterogeneous models for Planner and Executor shares its origin with A1's Programmatic Tool Calling.
• Guard sandwich (A5): the approval nodes and compliance checks in the plan are often implemented by A5's pre-check at deployment time. Both hand control back to the user.
• Iterative hypothesis testing (R4): R4 is the reasoning side's "adjust as you go," while A2 is the action side's "fix first, then adjust." A2's local replanning borrows R4's feedback-adjustment idea.

What this pattern teaches

Plan-and-Execute is not "make a todo list." It replicates decades of human project-management engineering (WBS, PERT, Saga, DAG scheduling) onto the LLM as is—it is more durable than a single ReAct agent because it stands on the shoulders of mature engineering, and because it hands control back to the user.

This page is part of the ADPS pattern white papers. Back to the pattern matrix, or see the runnable code catalog.