Plan-and-Execute Agents

Definition: A plan-and-execute agent first writes a complete plan for a task, then carries out the steps one by one, and replans only when a step fails or the facts change. A ReAct agent, by contrast, decides its next step after each action. Planning first can cost fewer model calls on long tasks and makes the work easier to review.

TL;DR: Plan-and-execute splits an agent into a planner, an executor, and a replanner. The planner writes the steps once, the executor runs them, and the replanner decides whether to finish or write a new plan. In an ICML 2024 paper, a parallel version called LLMCompiler reported up to 3.7x lower latency than ReAct. See how it fits the wider agent loop.

Think of a contractor who renovates a kitchen. A good one does not walk in, pick up a hammer, and decide what to do after each nail. They write a list first: remove the old cabinets, check the wiring, fit the new units, tile, paint. Then the crew works down the list. If they open a wall and find rotten wood, they stop and rewrite the rest of the list. That is plan-and-execute. The list is cheap to write, easy to show the owner, and only changes when reality forces it.

Why Plan-and-Execute Matters in 2026

Plan-and-execute matters because agents now run long, multi-step jobs, and the cost of deciding every step from scratch adds up. The ReAct pattern (Yao et al., 2022) calls the main model after every tool result. That is flexible, but on a 20-step task it means 20 or more full reasoning calls, each one reading a longer history.

The LangChain team summed up the trade in Plan-and-Execute Agents (February 13, 2024): with a plan in hand, "the larger agent doesn't need to be consulted after each action." Sub-tasks can run on smaller, cheaper models, and the large model is used for the plan and the final answer.

Two newer lines of work add reasons beyond cost:

• Reviewability. A written plan is something a person can read before anything runs. In Plan-Then-Execute (He, Demartini, and Gadiraju, conditionally accepted to CHI 2025), 248 participants worked with agents that planned and then executed daily tasks such as booking flights and paying by card. The authors found the agents helped when the plan was good and users stayed involved in execution. They also warned that a plan that only seems plausible can mislead users.
• Security. In Architecting Resilient LLM Agents (September 2025), Del Rosario, Krawiecka, and Schroeder de Witt argue that fixing the plan before the agent reads outside data gives "control-flow integrity". Once the plan is set, text the agent reads later, such as a hostile web page, cannot add new steps to it. The authors still recommend least privilege and sandboxed code on top.

How Plan-and-Execute Works

A plan-and-execute agent has three roles. One model can play all three, or each role can use a different model.

1. The planner writes the plan. It reads the goal and returns an ordered list of steps. Each step names what to do and, often, which tool to use.
2. The executor runs the steps. It works through the list, calls tools through function calling, and stores each result. The executor does not decide what the overall task is. It only finishes the step in front of it.
3. The replanner checks the outcome. After the steps run, or after a step fails, the replanner reads the goal, the original plan, and the results. It either writes the final answer or returns a new plan for what is left. The new plan goes back to the executor, and the cycle repeats.

The replanner is the part people forget. Without it, the agent follows a broken plan to the end. With it, the agent keeps the cost benefit of planning and still recovers when the world does not match the plan.

Here is what a plan can look like for a small research task:

GOAL: Compare the refund policies of our three shipping carriers

PLAN (written once by the planner)
  1. search_web("carrier A refund policy")          -> #E1
  2. search_web("carrier B refund policy")          -> #E2
  3. search_web("carrier C refund policy")          -> #E3
  4. summarize(#E1, #E2, #E3, "time limit, fees, proof needed")
  5. write_table(#4)

EXECUTION
  steps 1-3 can run in parallel (no step depends on another)
  step 4 waits for #E1..#E3
  step 5 waits for step 4

REPLAN CHECK
  carrier B page returned 404  ->  replanner adds:
  2b. search_web("carrier B claims process 2026")

The #E1 placeholders come from ReWOO, one of the variants below. They let a later step use an earlier result without the planner seeing that result first.

Plan-and-Execute vs ReAct

The two patterns differ in when the agent thinks. ReAct thinks between every action. Plan-and-execute thinks mostly at the start and at checkpoints.

The honest summary: ReAct is more adaptive, and plan-and-execute is cheaper and easier to audit. Many production systems mix them. They plan at the outer level and run a short ReAct loop inside each step. The ReAct pattern page has a wider table that also covers Reflexion and Tree of Thoughts.

A Short History of Plan-and-Execute

The idea of planning before acting is as old as AI planning itself. The language model version took shape in 2023.

LangChain credits its design as "based loosely on" the Plan-and-Solve paper and BabyAGI.

Variants: Plan-and-Solve, ReWOO, and LLMCompiler

The three best-known variants change how much the plan knows and how steps run.

• Plan-and-Solve prompting is the simplest. It is a prompt, not an architecture. Lei Wang and colleagues asked the model to "devise a plan" that divides the task into smaller subtasks and then carry them out. On ten reasoning datasets with GPT-3, it beat zero-shot chain-of-thought prompting on all of them.
• ReWOO (Reasoning WithOut Observation) writes the whole plan before any tool runs. Steps refer to future results through variables such as #E2. A worker fills the variables, and a solver writes the answer. The authors report "5x token efficiency and 4% accuracy improvement on HotpotQA", because the model does not reread the growing history after each call.
• LLMCompiler treats the plan like a compiler treats code. A planner emits a graph of tasks with dependencies, a task-fetching unit starts each task as soon as its inputs are ready, and an executor runs them in parallel. Against ReAct, Kim and colleagues report latency speedups of up to 3.7x, cost savings of up to 6.7x, and accuracy gains of up to about 9%.

When a Plan Goes Stale

A plan is a prediction, and predictions go out of date. Rigidity is the main weakness of the pattern: if an early step fails or a fact changes, every later step can be wrong. Four signals tell the replanner to act:

Replanning too often turns plan-and-execute back into ReAct, with extra overhead. Replanning too rarely produces confident work on a dead plan. A practical rule is to replan at fixed checkpoints and on any failure, not after every step. Clear stop conditions decide when the replanner should give up instead of trying again.

Limits and Open Problems

• The plan is only as good as the planner's knowledge. A planner that does not know a tool exists will not use it. Good tool descriptions and context engineering matter more here than in ReAct.
• Plausible plans can mislead people. The CHI study above found that a plan that looks reasonable can still be wrong. A reviewer must check the plan against the goal, not only its tone.
• Parallel steps need independent inputs. If two steps write to the same record, running them at once can corrupt data. Graph planners such as LLMCompiler must get dependencies right.
• Long plans compound errors. Each step can fail, and failures stack across the chain. Agent failure modes shows how often agents repeat steps or end too early.

How Plan-and-Execute Shows Up in Taskade

Plan-and-execute shows up in Taskade at two levels. When you describe an app, Taskade EVE plans the projects, agents, and automations it needs, then builds them, and it can pause to ask you a question. Inside one job, a Taskade automation is a plan written ahead of time, and Agent steps do the reasoning.

The trigger starts the automation, and each step runs in order. An Agent step does the reasoning for one part, such as a summary or a classification, and passes the result to the next step. Branch, loop, and filter steps let the plan take a different path when a result calls for it.

A weekly supplier price check is the plain use. Today someone opens five supplier sites, copies prices into a sheet, and flags the changes. In Taskade you keep a project that lists each supplier, the product, and last week's price. An automation runs every Monday. An AI agent with web search reads each supplier's public price page, writes the new price into the project, and adds a row to a "changes" table when a price moved more than 5%. A person reviews that table and decides what to reorder. The plan is the automation, and the reasoning sits inside each step. Taskade Genesis builds the first version of that app from one prompt. To start from a working example, clone the Project Flow Tracker kit, an app kit with a project, an AI agent, and automations you can clone. The Free plan covers 3 apps and 1 agent and starts with 0 AI credits.

Describe yours and build it free →

Related Concepts

• The Agent Loop: the perceive, reason, act cycle that every plan runs inside
• ReAct Pattern: the step-by-step alternative to planning first
• Planning and Reasoning: the wider family of planning techniques
• Agent Stop Conditions: when the executor and replanner should end the run
• Why AI Agents Fail: the failure modes a good plan prevents
• Agent Orchestration: splitting a plan across several agents
• Parallelization: running independent steps at the same time
• Long-Horizon Agents: agents that work for hours on one goal
• AI Agent Autonomy Levels: how much of the plan a person approves
• Agentic design patterns: the main patterns side by side
• Ambient Agents: agents that run on events in the background
• AI Agents: the hub for agent concepts in this wiki

Frequently Asked Questions About Plan-and-Execute Agents

What is a plan-and-execute agent?

A plan-and-execute agent writes a full plan for a task before it acts, then runs the steps in order. A replanner checks the results and either finishes or writes a new plan for the remaining work. It is the opposite of an agent that decides each step after the previous one.

How is plan-and-execute different from ReAct?

ReAct reasons after every tool result, so it adapts quickly but calls the main model many times. Plan-and-execute reasons mostly at the start, so it uses fewer large-model calls and gives you a plan to review. ReAct suits short, unpredictable tasks. Plan-and-execute suits long tasks with a known shape.

Is plan-and-execute faster than ReAct?

It can be. Independent steps can run in parallel, and steps can use smaller models. The LLMCompiler paper reported up to 3.7x lower latency and up to 6.7x lower cost than ReAct on its benchmarks. The gain depends on how many steps are independent and how often the agent must replan.

What happens when a step in the plan fails?

The replanner reads the goal, the plan, and the results so far, then writes a new plan for what is left. It can retry the step another way, add steps, or stop and hand the task to a person. Without a replanner, the agent follows the broken plan to the end.

What is the difference between ReWOO and LLMCompiler?

ReWOO writes the whole plan before any tool runs and uses placeholders such as #E1 for future results, which saves tokens. LLMCompiler turns the plan into a graph of dependent tasks and starts each task as soon as its inputs are ready, which runs independent steps in parallel.

Does Taskade use plan-and-execute?

Yes, at the app level. When you describe an app, Taskade EVE plans the projects, agents, and automations it needs, then builds them. Taskade automations also work like a written plan: a trigger starts them, and each step, including an AI agent step, runs in order.

When should I not use plan-and-execute?

Skip it for short tasks and open exploration, where the next step depends on what the last one found. A plan written before the agent knows anything goes stale fast. In those cases a ReAct loop with clear stop conditions is simpler and adapts better.

Further Reading

• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, arXiv 2210.03629, 2022
• Wang et al., Plan-and-Solve Prompting, arXiv 2305.04091, ACL 2023
• Xu et al., ReWOO: Decoupling Reasoning from Observations, arXiv 2305.18323, 2023
• Kim et al., An LLM Compiler for Parallel Function Calling, arXiv 2312.04511, ICML 2024
• Huang et al., Understanding the planning of LLM agents: A survey, arXiv 2402.02716, 2024
• LangChain, Plan-and-Execute Agents, February 13, 2024
• Anthropic, Building effective agents, December 19, 2024
• He, Demartini, and Gadiraju, Plan-Then-Execute: user trust and team performance, arXiv 2502.01390, 2025
• Del Rosario, Krawiecka, and Schroeder de Witt, Secure Plan-then-Execute Implementations, arXiv 2509.08646, 2025
• Nakajima, BabyAGI (original 2023 task-planning agent, now archived)