Planning is the step that separates an agent that solves one-sentence tasks from one able to complete a long, multi-step job. Instead of deciding the next action on the fly, a planning agent first breaks the goal into ordered subtasks and then runs them. This guide covers why planning matters, how a task is decomposed, which structures planners use, and how to replan when something goes wrong. The same explanation is available in Spanish.

Key takeaways

  • Planning means breaking a goal into ordered subtasks before acting, rather than improvising action by action.
  • The Plan-and-Solve paper (arXiv 2305.04091[1], ACL 2023) showed that asking the model to draft a plan first reduces missing-step errors compared with direct reasoning.
  • In the Game of 24, GPT-4 with chain-of-thought solved 4% of games; with Tree of Thoughts, which explores a tree of plans, that rose to 74%.
  • The planner-executor pattern splits two roles: a planner that lays out the list of steps and an executor that carries them out one by one with tools.
  • Replanning is what makes the agent robust: after each step it reviews what it has learned and adjusts the remaining plan.

Why does an agent need to plan?

An agent that only looks one step ahead works well on short tasks but gets lost on long ones. Without a plan, every decision depends solely on the current state, so the agent forgets the overall goal, repeats work or gets stuck in a dead end. The agentic loop (the reason-act-observe cycle an agent uses to work through tools one step at a time) handles the immediate reaction, but it does not guarantee that the sum of those reactions reaches the goal.

Planning adds a layer above that loop: before touching any tool, the agent writes a road map. That road map serves three purposes. It acts as external memory that keeps the goal in view; it lets the agent estimate how many steps will be needed; and it exposes mistakes before executing them, because a bad plan is caught by reading it, not by spending calls on it. The Plan-and-Solve paper formalized this as a two-part technique: "first, devise a plan to divide the entire task into smaller subtasks, and then carry out the subtasks according to the plan".

Task decomposition into subtasks

Decomposing means splitting a large goal into chunks the agent can solve one at a time. Suppose the goal is "publish a summary of the latest sales report on the blog". A model cannot do it in a single call, but it can plan the sequence:

Goal: publish a summary of the latest sales report on the blog.

Plan:
  1. Read the file sales-report.csv and compute the total per region.
  2. Draft a 200-word summary with those figures.
  3. Publish the summary as a draft in the CMS.

Each line is a concrete subtask, with an action verb and a checkable result. Good decomposition follows two rules: steps are as independent as possible, and each one leaves a result the next can use. Anthropic describes this idea with two of its patterns. In prompt chaining, "a task is decomposed into a sequence of steps"; in the orchestrator-workers pattern, "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results", useful when you don’t know in advance how many subtasks will be needed.

Planners: from task tree to graph

Not every plan is a straight list. Depending on the task, a planner can organize subtasks in three increasingly rich shapes:

  • Sequential list. Steps run one after another. This is what Plan-and-Solve produces and it is enough for linear tasks.
  • Task tree. The agent explores several plan branches at once and keeps the best. The Tree of Thoughts method (arXiv 2305.10601[2]) does exactly this: it generates alternative thoughts, scores them and prunes the bad branches. That tree is what took the Game of 24 from 4% to 74% success, at a cost of about 5,500 tokens per problem.
  • Dependency graph. When some subtasks depend on others, the plan is drawn as a directed graph. The LLMCompiler architecture organizes tasks this way and runs them in parallel as soon as their dependencies are met, which its paper measures as a 3.6x speedup over serial execution.

Choosing the structure is a trade-off: a list is cheap but rigid; a tree explores better but costs more tokens; a graph enables parallelism at the price of more complexity. Frameworks such as LangGraph, which reached its stable 1.0 release in October 2025, ship these structures ready-made, as we show in state graphs with LangGraph.

The planner-executor pattern

The planner-executor pattern (plan-and-execute) splits the work between two roles. A planner turns the user’s goal into a list of steps. An executor, usually an agent with tools, carries out each step separately. The advantage over a pure ReAct loop is that the big model is not consulted after every action: the plan is already drawn, so the agent moves faster and cheaper, and can reserve the powerful model just for planning. In pseudocode, the skeleton fits in a few lines:

def plan_execute_agent(goal, planner, executor):
    plan = planner.make_plan(goal)         # list of subtasks
    facts = []
    while plan:
        step = plan.pop(0)
        result = executor.run(step)         # an agent with tools
        facts.append(result)
        plan = planner.replan(goal, facts, plan)
    return planner.answer(goal, facts)

A variant that saves even more calls is ReWOO (Reasoning WithOut Observations), where the planner uses variables to chain results without calling the model again between steps:

Plan: look up the population of France.
E1 = search["population of France"]
Plan: look up the population of Germany.
E2 = search["population of Germany"]
Plan: add the two figures.
E3 = calculate[#E1 + #E2]

Each #E1 references the result of the previous step, so the model drafts the whole plan at once and an executor resolves it afterward. When one pattern beats the other we cover in depth in plan-and-execute versus ReAct.

Replanning when things go wrong

No plan survives contact with reality intact. A tool returns an error, a file does not exist or a result invalidates an assumption in the plan. That is why the pattern includes a third role, the replanner, which after each step looks at the full history (the original plan plus the results already obtained) and decides whether to continue as planned, rewrite the remaining steps or call the task done.

Replanning is what turns a static list into a living plan. In practice, the replanner takes the accumulated facts and returns an updated plan, exactly the loop in the pseudocode above. This cycle of planning, executing and adjusting is also the basis of systems where several agents share a plan, which we expand in multi-agent system patterns. Without replanning, the agent follows an outdated map; with it, it corrects course just as you would when hitting an unexpected obstacle.

Frequently asked questions

How is planning different from reasoning with ReAct?

In ReAct the agent decides the next action on each turn of the loop, without a road map. Planning adds an earlier step: the model lays out the whole sequence of subtasks before acting. ReAct is more flexible in the face of surprises; planning is more efficient on long, predictable tasks, because it avoids consulting the big model after every action.

When is planning worth it and when not?

Planning pays off when the task has several steps with clear dependencies and a stable goal, because the plan cuts calls and holds the course. It does not pay off on single-step or highly exploratory tasks, where the environment changes so much that any plan is obsolete right away; there a reactive loop with good replanning does better.

What is replanning?

It is the step where the agent, after executing one or more subtasks, reviews what it has learned and adjusts the remaining plan. It can reorder steps, add new ones, drop those that no longer apply, or finish if the goal has been met. It is what lets the agent recover from errors and unexpected results without abandoning the task.

Conclusion

Planning is what lets an AI agent take on long jobs without getting lost: it breaks the goal into subtasks, organizes them into a list, a tree or a graph, and runs them with a planner-executor pattern that knows how to replan when something fails. It is a trade-off between efficiency and flexibility, not a silver bullet. The natural next step is to compare this approach with the reactive loop in plan-and-execute versus ReAct and see how the two combine.

Sources: [1] Plan-and-Solve Prompting (Wang et al., 2023)[1], [2] Tree of Thoughts (Yao et al., 2023)[2], [3] Plan-and-Execute Agents (LangChain blog)[3], [4] Building effective agents (Anthropic, 2024)[4].

Visitas: 0

Sources

  1. arXiv 2305.04091
  2. arXiv 2305.10601
  3. Plan-and-Execute Agents (LangChain blog)
  4. Building effective agents (Anthropic, 2024)

Route: AI Agents Fundamentals