Plan-and-execute

Overview

Plan-and-execute is an agent design in which the model first writes an explicit, step-by-step plan for a task and then carries out the steps, rather than deciding each next move on the fly. A planner, usually a strong model, produces the plan. An executor, which can be a cheaper model, a tool call or plain code, runs each step. After some or all steps, a re-planner looks at the results and either finishes, adjusts the remaining steps or starts a new plan.

The main alternative is the reason-and-act loop described in the ReAct loop, where the model thinks, acts and observes one step at a time. Plan-and-execute trades some of that moment-to-moment flexibility for structure. Because the plan is written down, it can be checked, shown to a person, run in parallel where steps are independent and executed with fewer calls to the expensive model.

An everyday comparison is cooking a big meal. One cook opens the fridge, decides what to do next, does it, then looks again, over and over. Another cook first writes a list: start the rice, chop vegetables while it cooks, preheat the oven, then roast. The second cook can hand chopping to a helper, notice that two tasks can run at once, and adjust the list if the shop is out of an ingredient. Plan-and-execute is the second cook.

What it is

Plan-and-execute is a pattern, not a product. Most agent frameworks can implement it. It has three core roles and a few shared pieces.

Plans come in different shapes. A flat list runs steps one after another. A plan with variables lets later steps refer to earlier results, such as "use the result of step 2". A dependency graph, also called a DAG, records which steps depend on which, so independent steps can run at the same time.

Where it came from

The idea of separating planning from acting is old in artificial intelligence, going back to classical planners. For language models, several 2023 works shaped it:

• Plan-and-Solve prompting (Wang and colleagues, 2023) showed that asking a model to first devise a plan and then carry it out improved results on reasoning problems compared with plain step-by-step prompting.
• BabyAGI, an open-source project by Yohei Nakajima in 2023, popularised a loop of creating, prioritising and executing tasks.
• ReWOO (Xu and colleagues, May 2023), "Reasoning WithOut Observation", had a planner write the whole plan with placeholders for results, workers fill them in, and a solver write the answer, which cut the number of tokens used.
• LLMCompiler (Kim and colleagues, December 2023) had the planner produce a graph of tasks and ran independent tasks in parallel, reporting speed-ups over sequential approaches.

Agent frameworks, notably LangGraph, published reference implementations of these designs in early 2024. Since then, planning has become a standard feature of coding agents and research agents, often combined with re-planning, to-do lists and orchestrator-workers delegation.

How it works

Step 1: Understand the goal

The planner receives the user's goal, the list of available tools and any constraints, such as a budget, a deadline or data access limits.

Step 2: Write the plan

The planner writes concrete steps. Good steps are small, checkable and tied to a tool. For example: "1. Query the sales database for Q3 revenue by region. 2. Query the same for Q2. 3. Compute the change per region. 4. Write a short summary of the three largest changes." In graph-based designs, each step also lists the steps it depends on.

Step 3: Optionally review the plan

Because the plan is explicit, code or a person can inspect it before anything runs. Code can reject steps that use forbidden tools. A person can approve a plan that will spend money or change data; see human-in-the-loop.

Step 4: Execute steps

The executor runs each step. A simple step, such as a database query, may need no model at all. A harder one, such as summarising a document, may use a small model. Independent steps can run in parallel. Each result is stored in state.

Step 5: Re-plan

After a step or a batch of steps, a re-planner compares results with the goal. If a step failed, returned nothing or revealed new information, it can adjust the remaining steps. If the goal is met, it moves to the final answer. A limit on re-plans prevents endless cycles.

Step 6: Produce the answer

A finaliser, often the planner model again, combines results into the response, ideally citing which step produced which fact.

Why it can save cost

In a ReAct loop the large model is called after every tool result. In plan-and-execute it may be called only to plan, to re-plan occasionally and to write the final answer, while cheaper components do the steps. Fewer large-model calls usually mean lower cost and, with parallel steps, lower latency.

Key concepts and terms

A worked example

This scenario is illustrative. A finance analyst asks: "Compare our Q3 revenue with Q2 for each of our five regions, and explain the biggest change."

1. The planner, a large model, writes six steps: query Q3 revenue by region, query Q2 revenue by region, compute differences, find the largest change, search the regional reports folder for notes on that region, and write a summary.
2. Steps 1 and 2 have no dependencies, so they run in parallel as SQL queries with no model involved.
3. Step 3 is plain code. It finds that the North region fell from 4.2 million to 3.5 million euros, a drop of 0.7 million, the largest change.
4. Step 5 searches the reports folder and returns nothing, because the North report is filed under a different name.
5. The re-planner sees the empty result and adds a step: search by region code "N-01". This returns a note about a delayed contract.
6. The finaliser writes three sentences with the numbers and the reason.

In total the large model is called three times: plan, re-plan and final answer. A step-by-step loop for the same task would typically call it after every one of the seven tool results.

Strengths and limitations

Strengths:

• Fewer calls to the most expensive model.
• Independent steps can run in parallel, cutting latency.
• The plan is visible, so it can be validated, approved and logged.
• Forces the model to think through the whole task up front.
• Steps can be matched to the cheapest capable executor.

Limitations:

• Plans can be wrong from the start if the planner misunderstands the task.
• Less adaptive than step-by-step loops when each result changes what to do next.
• Re-planning adds complexity and can loop if not limited.
• Exploratory tasks, where the path is unknown, often suit ReAct better.
• Errors in one step can flow silently into later steps unless results are checked.

How it compares with alternatives

Practical guidance and best practices

1. Ask the planner for small, concrete steps, each tied to one tool or action.
2. Ask for explicit dependencies so independent steps can run in parallel.
3. Validate the plan in code before running it, rejecting unknown or forbidden tools.
4. Put plans that spend money or change data in front of a person for approval.
5. Use the cheapest executor that works for each step, including plain code.
6. Check each step's result and treat empty or failed results as triggers for re-planning.
7. Cap the number of re-plans and total steps; see cost and latency budgets.
8. Log plans, results and re-plans, and evaluate them against real tasks with evals.

Common mistakes

• Letting the planner write vague steps such as "research the topic".
• Running the whole plan without checking results, so one empty search ruins the answer.
• Re-planning after every step, which removes the cost benefit.
• Using plan-and-execute for open-ended exploration where the next step depends on every result.
• Having no limit on re-planning, which can create loops.
• Giving the executor more tools than its step needs.

Frequently asked questions

What is a plan-and-execute agent?

It is an agent that writes an explicit multi-step plan first, then runs each step with tools or smaller models, and re-plans when results require it.

How is it different from ReAct?

ReAct decides one action at a time after each observation. Plan-and-execute decides most actions up front, which saves large-model calls and enables parallel steps, but adapts less smoothly to surprises.

Does plan-and-execute save money?

Often. The expensive model is used mainly for planning and the final answer, while cheaper models, tools or code run the steps. The saving shrinks if you re-plan very often.

What are ReWOO and LLMCompiler?

They are 2023 research designs in this family. ReWOO writes the whole plan with placeholders for results, then fills them in. LLMCompiler writes a dependency graph of tasks and runs independent ones in parallel.

When should I not use it?

When the task is exploratory and each result changes what should happen next, or when the steps are always the same, in which case a fixed workflow in code is simpler.

Can a person approve the plan?

Yes, and that is one of the pattern's strengths. Showing the plan before execution is a natural approval point for high-impact work.

Glossary

• Plan: a written list or graph of steps.
• Planner: the model that writes the plan.
• Executor: the component that runs a step.
• Re-planner: the component that revises the plan.
• Dependency: a step that must finish before another starts.
• DAG: a graph of steps without cycles.
• Solver: the step that composes the final answer.
• Step budget: a cap on steps or re-plans.

Summary

Plan-and-execute agents write a plan first, run the steps with the cheapest capable executor, and re-plan when results call for it. The pattern grew from 2023 work such as Plan-and-Solve prompting, BabyAGI, ReWOO and LLMCompiler. It reduces calls to expensive models, enables parallel steps and makes plans reviewable, at the cost of some flexibility. Use it for multi-step tasks with a predictable shape, keep steps concrete, check results and cap re-planning.

Related

It belongs to Patterns in my stack, under Agentic AI. Others in the same group: