Pattern Matrix/White Paper/A2

Problem

In a long process, a purely reactive Agent can lose the global sequence. An HR recruiting Agent may send compensation information after rejection, skip a required background check, or query the same record repeatedly when each step is chosen only from the latest observation.

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.

Classification: 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.

Solution and mechanics

Plan-and-Execute depends on separation, approval, and context reset. Aider's architect mode is a compact product example: the architect produces a plan, the editor starts from that artifact, and user confirmation can sit between planning and execution.

Several key designs matter in engineering practice:

• Heterogeneous models: Planning usually requires stronger global reasoning, while execution is more structured and verifiable. Compare model combinations on the same task set for quality, cost, and rework.
• 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 reality conflicts with the plan, change only affected future nodes and preserve committed work. Set review frequency and replan budget from task length, external volatility, and replay results.

ReWOO illustrates a related optimization: plan variable dependencies first, execute intermediate tool calls without returning to the model for every step, then synthesize the result. Its published results are research evidence for that benchmark, not a universal production ratio.

Applicability

• 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.

Known failure modes

• 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: Rewriting stable prefixes at every step prevents cache reuse. Keep system instructions, tool definitions, and plan prefixes stable where semantics allow, while refreshing external state separately.

Verification and metrics

• Long-task success rate / error rate: Compare with a reactive baseline and classify errors as planning, execution, or external-state failures.
• LLM calls per task: Track the distribution by task complexity. Unexpected growth often points to repeated replanning or retries.
• Replan frequency: High frequency may indicate thrashing; no replans may indicate ignored environmental change. Inspect the reasons, not only the count.
• Cache hit rate: Observe reuse of stable prefixes together with stale-state incidents so that cache efficiency does not hide outdated context.

Reference implementation

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.

Illustrative scenario

Liang Bo's team explicitly separates strategic planning from tactical execution. The planning layer writes a DAG into the Workspace, and a deterministic scheduler advances by dependency rather than asking the LLM to rediscover the macro path at every step. In an HR workflow, Planner creates the dependency graph, Executor handles only the current node, and changes to screening criteria or candidate status pass through an Approval Gate. Cost, cycle time, and error outcomes should be published only with the named team's approved measurement.

Related 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 (A4): the approval nodes and compliance checks in the plan are often implemented by A4'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.

Design conclusion

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.