Planning › What Planning Means for LLM Agents

Michael BrenndoerferJanuary 1, 20266 min read
Language AI HandbookAll chapters
Part 48 of 67Tool Use and Agents
Chapter 370Planning › What Planning Means for LLM Agents
Reading section 2 of 12 · What Planning Means for LLM Agents · 6 minSection 2 of 12 · 6 min

Book contents

Section 2 of 12 · 6 min read

Planning › What Planning Means for LLM AgentsOne section · Sections in this chapter2 / 12 ↓
Reading tools Definitions & inline links

Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.

Article links

Make inline references clickable

Planning in classical AI refers to the problem of finding a sequence of actions that turns an initial state into a goal state. In formal planning systems like STRIPS (Stanford Research Institute Problem Solver), actions have explicit preconditions and effects, and a planner searches through a state space to find a valid path from start to goal. This formalism works beautifully when the world is fully observable and the action space is small, but it becomes computationally intractable for real-world tasks where state spaces are enormous and actions are hard to enumerate. A robotics task with a few dozen states and ten actions is tractable. Planning how to complete a software engineering task involving hundreds of files and unbounded possible code changes is not.

LLM-based planning takes a different approach. Instead of explicit state-space search, the language model itself acts as the planner, using its broad knowledge to generate plausible action sequences in natural language. The planner does not search exhaustively through possibilities; it generates a reasonable plan based on its training distribution and then adapts as execution reveals new information. This is closer to how humans plan than how classical AI planners work. You do not enumerate all possible routes from your apartment to a meeting before leaving. You recall roughly how to get there, start walking, and adjust when you encounter a closed street or unexpected construction.

Plan

A plan is an ordered set of steps that, if executed correctly, achieves a specified goal. In the LLM agent context, each step typically maps to a tool call, a sub-query to another model, or a reasoning action. Plans can be fully determined upfront (static plans) or constructed incrementally as the agent learns more about the task (dynamic plans).

The key difference between a planning agent and a simple ReAct agent is the scope of deliberation. A ReAct agent thinks one step ahead: it reasons about what to do next, acts, observes the result, and repeats. A planning agent thinks many steps ahead: it considers the full structure of the task before committing to any action, identifies which steps can be parallelized and which must be sequential, and maintains a representation of the overall goal throughout execution. The ReAct loop is reactive; the planning loop is anticipatory.

This distinction matters for several reasons. First, some tasks have global constraints that only become visible when you look at the whole problem at once. Booking a trip that satisfies flight and hotel constraints within a calendar schedule is harder to handle step-by-step than with a plan that considers all three dimensions from the start. A reactive agent might book a flight, then discover no hotel is available at the destination on those dates, and have to restart entirely. A planning agent checks availability across all dimensions before committing to any booking, avoiding the wasted effort. Second, planning reduces redundant work by ordering steps to avoid re-doing computations. If the plan recognizes that three different research questions all require information from the same source document, it retrieves that document once and passes it to all three questions, rather than fetching it three times. Third, a plan provides a scaffold for recovery: when step four fails, the planner knows what steps three and five are and can reason about how to get back on track, whereas a reactive agent has no pre-existing structure to repair.

The Spectrum of Deliberation

It is useful to think of planning capability as a spectrum rather than a binary. At one end is pure reaction: the agent decides what to do based only on the immediate observation, with no representation of future steps. At the other end is full symbolic planning: the agent constructs a complete, verified action sequence before taking any action at all. LLM-based agents occupy a large middle region of this spectrum, and different architectures sit at different positions.

Most production systems combine some upfront deliberation with ongoing adaptation. A good planning agent commits enough upfront to gain the benefits of structured reasoning, while remaining flexible enough to adapt when the world does not cooperate. Finding this balance is one of the central design challenges in building planning agents. Commit too much upfront and the agent becomes brittle when the environment deviates from assumptions; commit too little and planning provides no benefit over pure reaction.

Understanding this spectrum also helps explain why planning capability is hard to benchmark reliably. A task that requires only a few predictable steps looks like a win for lightweight reactive agents. A task with ten steps, complex dependencies, and multiple potential failure modes strongly favors deliberate planning. The right architecture always depends on the task structure, and benchmark results from one domain do not necessarily transfer to another.

Why Planning Fails Without Structure

To appreciate what planning provides, it helps to examine the specific failure modes that arise when agents act without it. Consider a research agent tasked with writing a comparative analysis of two competing scientific theories. Without planning, the agent begins immediately: it searches for the first theory, gets some results, searches for the second theory, gets some results, and then attempts to write a comparison. But the comparison requires understanding what dimensions to compare across, which requires knowing both theories well before deciding what to show. A planning agent would recognize this upfront and structure the task differently: first identify the key comparison dimensions, then gather evidence for each dimension across both theories, then write the comparison section by section.

The structural flaw in reactive execution is that commitment and information arrive in the wrong order. The agent commits to an approach (searching for theory A first) before it has the information needed to know whether that approach is sensible (what dimensions matter for the comparison). Planning defers commitment until enough information has been specified to make good decisions. This is the same reason architects draw blueprints before construction workers begin building, and why programmers design APIs before implementing them.