The Planner: From Goal to Action Sequence

A language model given a vague goal — 'analyze our Q3 sales data and prepare a deck for Monday's board meeting' — will often either produce a plausible-sounding but shallow response or get stuck in a loop of unhelpful generalities. What converts that goal into concrete, executable steps is the planner. The planner is the component responsible for decomposing a high-level objective into an ordered sequence of sub-tasks, each of which is specific enough that the LLM core and tool layer can actually act on it.

What Planning Requires

Good planning requires three capabilities. First, goal analysis: understanding what the high-level goal actually entails — what information is needed, what constraints apply, what the output must look like. Second, decomposition: breaking the goal into a sequence of sub-tasks where each sub-task has a clear precondition (what must be true before it can run) and a clear postcondition (what it produces or changes). Third, ordering: arranging sub-tasks so that the outputs of earlier steps are available as inputs to later steps. The board-meeting-deck example decomposes into roughly: access the sales database, run aggregate queries by region and product, identify outliers, draft slide titles, write bullet content for each slide, format as a presentation file. Each step depends on the previous one.

Two planning strategies dominate current practice. In hierarchical planning, the agent first produces a high-level plan (a short list of major stages), then breaks each stage into smaller steps as it executes. This mirrors how a competent human project manager works: outline the project, then zoom into each section. The advantage is that early planning does not commit the agent to implementation details it cannot know yet. In flat or one-shot planning, the agent attempts to enumerate all steps upfront before executing any. This is simpler to implement but brittle: if an early step yields unexpected results, the rest of the plan may be invalid and the agent must re-plan from scratch. A third approach, increasingly common in frontier systems, is reactive planning — the agent takes one step, observes the result, then decides the next step. This is maximally adaptive but requires the orchestration loop to handle open-ended iteration gracefully and guard against infinite loops.

Planning Failures and How to Diagnose Them

Planning is a common source of agent failure, and the failure modes are recognizable. Underspecification occurs when the plan's sub-tasks are still too vague to execute — 'gather relevant information' is not a step the tool layer can act on. Ordering errors occur when a step is attempted before its dependencies are satisfied — writing slide content before the aggregate queries have been run. Scope creep occurs when the agent pursues sub-tasks that are tangentially related to the goal but were not requested. Stale plans occur when the agent continues executing a plan whose premises have been invalidated by an earlier step's unexpected output. Recognizing which failure mode is active tells you exactly where in the plan to intervene.