Agent planning is how an agent decides on a sequence of steps to reach a goal, either before it starts acting or as it goes. Task decomposition is the part that breaks a goal into smaller units: which tools are needed, what has to be retrieved, in what order, and when to stop and ask a person.
It is worth being precise about what a plan is in an LLM agent, because the word imports expectations from classical AI planning, where a planner searched a formal state space with defined preconditions and effects. In most agent systems today, the plan is text the model produced. It has no guaranteed relationship to what the tools can actually do, and nothing enforces that the agent follows it. That is not a criticism, it is the operating condition, and designs that ignore it break in predictable ways.
Planning matters because the path is often the product. An answer that is correct after nine redundant tool calls, or after reading a record the user was not entitled to, is not a good outcome. Output-only checks score it as a pass.
Key takeaways
- Planning is the decision about step sequence. Task decomposition is the part that turns one goal into units of work.
- Plan-then-execute makes the intended path inspectable before anything runs. Interleaved reasoning and acting adapts better to what tools actually return. Most systems need some of both.
- A plan produced by a model is a suggestion, not a contract. Measure plan adherence separately from plan quality.
- Replanning is a design requirement, not an edge case. Decide in advance what happens when step three fails or returns something unexpected.
- Evaluate plans on necessity, ordering, groundedness in available tools, and policy compliance, because a correct final answer can hide a bad path.
Plan first, or plan as you go
Plan-then-execute. The agent produces a step list up front, then an executor runs it. The advantages are concrete: you can show the plan to a user for approval, estimate cost before spending it, cache or reuse plans for recurring tasks, and see the intended path in a trace as one artifact. The weakness is that the plan was written before any evidence arrived. When step two returns nothing, the remaining steps may be nonsense.
Interleaved reasoning and acting. The agent reasons about one step, takes it, reads the result, and decides again. This is the pattern behind the ReAct style of alternating thought and action, and it handles surprise well because every decision sees the latest observation. The cost is that no one, including the agent, knows the full path in advance, and there is nothing to approve before execution starts.
Hierarchical. A coarse plan at the top, interleaved decisions inside each step. This is where most systems that handle long tasks end up. You get an inspectable shape and local adaptability, at the price of two levels to debug.
The choice is not ideological. If the task has regulatory or cost constraints, plan first so someone can check. If the environment is unpredictable, interleave. If runs take twenty steps, do both.
Replanning
An agent that cannot revise its plan will follow it off a cliff. Replanning needs three things specified.
A trigger. A tool error, an empty result, a contradiction with an earlier observation, a step that exceeded its budget, or an explicit check that the remaining steps still make sense.
A scope. Retry the failed step, replace the remainder of the plan, or start over. Replacing everything on any failure is expensive and loses work. Retrying forever is the loop you will find in your cost report.
A limit. A cap on replanning cycles. Without one, an agent facing an impossible subtask will rewrite the plan until something else stops it.
Evaluating plans
The final answer tells you nothing about whether the path was sound, so score the plan directly. Useful criteria:
- Necessity. Does every step contribute. Redundant retrieval and duplicate lookups are the most common waste.
- Sufficiency. Would executing the plan actually answer the question, or does it stop one step short.
- Ordering. Are dependencies respected. Does it write before it reads.
- Groundedness. Does every step map to a tool that exists, with arguments the tool accepts. Plans that reference imaginary capabilities are common and easy to detect.
- Policy. Does the plan stay within permissions, and does it pause for approval where it should.
- Adherence. Did the agent do what its plan said. This one needs the plan and the trace side by side, and the gap is frequently larger than teams expect.
These are trajectory-level checks, which is why they belong with the failures that traditional software tests miss rather than with output assertions. In practice you run them as evaluators over recorded runs, scoring the plan span against the tool spans that followed it, which is a standard part of tracing and evaluating an agent rather than a separate exercise.
When not to plan
Explicit planning costs a model call, adds latency, and can make simple tasks worse by committing the agent to a shape before it has looked at anything. A two-step lookup does not need a plan. Neither does a task where one tool obviously answers the question. Add planning when the step count is variable, when steps have dependencies, when a wrong order is expensive, or when someone needs to approve the path before it runs.
FAQ
What is a planner agent?
A component, sometimes its own agent, whose job is producing the step list rather than executing it. Separating planning from execution lets you use a stronger model for the plan and cheaper ones for the steps, and it gives you a clean artifact to evaluate and approve. The cost is a handoff, and handoffs lose context.
What is the difference between planning and task decomposition?
Decomposition breaks a goal into units of work. Planning includes decomposition and adds ordering, dependencies, tool assignment, and stopping conditions. In casual use the terms overlap, and most sources use them interchangeably.
Should the plan be structured output or free text?
Structured, if you intend to do anything with it. A JSON list of steps with a tool name and arguments per step can be validated against your tool registry before execution, compared against what actually ran, and scored automatically. Free text plans read well and are difficult to check mechanically.
How do you improve long-horizon planning?
There is no single fix, and anyone offering one is selling something. The changes that tend to help are reducing the horizon by decomposing into sub-tasks with their own termination, keeping a compact record of what has already been tried so the agent stops repeating itself, checking progress against the plan at intervals rather than only at the end, and giving the agent fewer and better-described tools so each step has less room to go wrong.
Why does the agent ignore its own plan?
Because nothing makes it follow the plan. The plan is text in the context window, and it competes with the most recent tool output for the model’s attention, usually losing. If adherence matters, enforce it in code: have the executor take steps from the plan rather than asking the model what to do next.
