Planning in the LLM Era

What You'll Learn

• Why single-shot LLM plans fail when tasks require long-horizon reasoning or recovery from mistakes.
• How NL2Search, NL2PDDL, and NL2Policy use language models during planner construction.
• Where SPIRAL's Planner, Simulator, and Critic fit inside a grounded search loop.
• How to combine formal validation, held-out testing, runtime monitoring, and human review.

Why One-Off LLM Plans Break Under Pressure

Planning is not the same as producing a plausible list of actions. A useful planner has to represent the current state, understand which actions are legal, anticipate their effects, and reach a goal without silently changing the objective. A language model can write a convincing sequence while still assuming a resource exists, a permission is available, or an earlier action succeeded when none of those conditions is true.

The paper Planning in the LLM Era: Building for Reliability and Efficiency describes this problem as a weakness of single-shot planning and restricted search hybrids. These systems can struggle to reconsider an early decision, generalise to unseen instances, or search a large state space economically. Adding more prose to the prompt does not turn an uncertain language prediction into a tested transition system.

This is also why “agentic” demos can look better than production workflows. A short task with forgiving tools may tolerate an incorrect intermediate assumption. A workflow involving APIs, approvals, timeouts, inventory, or access control cannot. In that setting, the engineering question is not whether the model can suggest a plan. It is whether the plan can be represented, checked, tested, observed, repaired, and safely abandoned.

What Planner Generation Changes

Planner generation moves some of the language model’s work earlier in the lifecycle. Instead of asking an LLM to solve every instance from scratch, a system can ask it to construct a search component, a formal planning model, or a reusable policy. That generated artifact is then tested against examples and held-out cases before it becomes part of the runtime system.

This does not remove uncertainty. It changes where uncertainty is exposed. A generated PDDL model may have a missing precondition. A generated heuristic may prefer attractive but unproductive states. A generated policy may work on familiar objects and fail when the environment contains a new combination. Construction-time testing makes those failures easier to inspect than an opaque chain of natural-language steps, but it does not make them disappear.

The practical benefit is reuse. A validated planner can solve multiple problem instances without asking a language model to repeat the same reasoning at every step. That can reduce latency and inference cost for suitable domains. It can also make the system easier to profile because the search procedure, state representation, and policy code can be inspected independently.

Three Paths: NL2Search, NL2PDDL, and NL2Policy

The position paper organises current planner-generation research into three broad paths. NL2Search asks the language model to generate search components such as a successor function, a goal test, or a heuristic. A classical search algorithm can then explore the resulting state space without calling the model for every successor. This approach is attractive when the state representation and action semantics are already well defined.

NL2PDDL translates a natural-language description into a formal planning domain and problem. PDDL separates the domain, which describes actions and predicates, from the problem instance, which describes objects, the initial state, and the goal. An existing planner can then work with that formal representation. The hard part is not merely producing syntactically valid text. The generated model must encode the intended operational meaning.

NL2Policy generates a strategy or executable policy that can generalise across a family of problems. Code-based policies can express procedural glue, data transformations, and loops that are awkward to encode in classical PDDL. They can also be tested as programs. The trade-off is that executable flexibility creates a larger surface for ordinary software bugs, unsafe side effects, and hidden assumptions.

PDDL Is a Contract, Not a Guarantee

PDDL is useful because it forces a planning problem into explicit pieces. Actions have preconditions and effects. Objects and predicates are named. The initial state and goal are separated. A planner can search over that representation instead of interpreting a paragraph anew at every step.

That structure is a contract between the model and the planner, not a complete description of the world. If the contract omits a permission, a resource limit, a side effect, or a dependency between services, a formally valid plan can still be operationally wrong. The planner can only reason over the state variables and actions it receives.

The position paper identifies several open limits for language-to-PDDL systems. Partial information can make the initial state uncertain. Object creation can exceed classical assumptions. Conditional plans and loops may need support outside the formal model. API workflows often need procedural glue for pagination, authentication, response transformation, and retries. These are not minor formatting issues. They determine whether the model describes the task that the deployed agent actually faces.

Where VAL Helps and Where It Stops

VAL is an open-source project for tools that work with AI planning plans and planning models. In a typical workflow, a candidate plan is checked against the supplied domain and problem. The validator can identify whether the action sequence is syntactically acceptable and whether it satisfies the formal constraints represented in those files.

That is valuable because it turns a vague answer into an artefact with a testable boundary. A failed validation can point to an illegal action, an unmet precondition, or an inconsistency in the formal model. A passing result tells an engineer that the candidate is compatible with the checked representation.

A passing VAL result does not certify the full agent. It does not prove that the domain model is complete, that the API will respond as expected, that the user has authorised the action, or that the environment has not changed. The position paper notes that deeper semantic problems, including incorrect invariants, missing preconditions, and unintended side effects, are not solved by basic validation alone. The correct statement is narrower and more useful: formal validation can establish consistency with an explicit model, while reliability requires model review and operational testing around it.

SPIRAL Adds Grounded Search and Reflection

SPIRAL, or Symbolic LLM Planning via Grounded and Reflective Search, is a separate empirical framework published in the AAAI-26 proceedings. Its official AAAI record describes three specialised roles inside a Monte Carlo Tree Search loop.

The Planner proposes possible next steps. The Simulator predicts realistic outcomes so the search is grounded in the expected state transition. The Critic provides a denser reward signal through reflection. Together, those roles give the search process more information than a single linear chain of thought. The important architectural idea is not that three prompts automatically create reliability. It is that proposal, outcome estimation, and evaluation are separated so the system can explore alternatives and recover from poor branches.

What the 83.6% DailyLifeAPIs Result Actually Means

The AAAI paper reports that SPIRAL achieved 83.6% overall accuracy on DailyLifeAPIs. It also reports an improvement of more than 16 percentage points over the next-best search framework and better token efficiency in the stated experiments. Those figures are useful evidence that grounded and reflective search can outperform the paper’s comparison systems on its benchmark.

They are not a universal success rate for AI agents. The result belongs to a named dataset, a particular task definition, a particular implementation, and the evaluation procedure described in the paper. It does not tell a buyer how the system will behave on an unfamiliar enterprise API, a changing website, a partially observable physical environment, or a workflow with irreversible actions.

Benchmark reading should therefore ask three questions. What exactly counts as success? Which alternatives were compared? How close is the benchmark’s state representation to the deployment environment? A higher score is meaningful when those conditions are clear. It becomes misleading when a bounded experiment is presented as proof that the architecture will handle every long-horizon task.

Construction-Time Intelligence Versus Runtime Model Calls

The strongest case for planner generation is not that every runtime LLM call is bad. Language models remain useful for interpreting ambiguous instructions, extracting state from text, choosing among tools, and handling tasks that were not represented during construction. The useful distinction is between a model call that constructs reusable machinery and a model call that repeatedly improvises every low-level action.

For a stable, well-specified domain, construction-time generation can produce a search heuristic, a PDDL model, or a policy that is compiled, tested, and reused. That can lower repeated inference cost and make performance easier to measure. For an open-ended environment, the same approach may need a runtime model for perception, translation, recovery, or model repair. “No LLM at runtime” is therefore a domain-specific design choice, not a general rule.

This distinction connects with the site’s Equilibrium Reasoners analysis and Vector Policy Optimization guide. Both topics raise a similar engineering question, where should probabilistic reasoning sit, and which parts of the execution path need a deterministic or separately testable contract?

A Practical Verification Pipeline

A production planning pipeline should treat generation as one stage in a longer control loop. First, define the domain boundary and the state variables that the planner is allowed to change. Second, ask the LLM to generate the chosen representation, whether that is search code, PDDL, or a policy. Third, parse and lint the artefact before a planner or interpreter touches external systems.

Fourth, run formal validation where the representation supports it. Fifth, test on both familiar examples and held-out cases that were not used during construction. Sixth, compare the generated result with an independent baseline or a human-authored fixture. Seventh, execute only through constrained tools with explicit permissions, timeouts, and audit logs. Eighth, monitor state transitions and stop when the observed environment no longer matches the assumptions used by the plan.

This pipeline is more demanding than adding a validator at the end, but it prevents a common category error. A validator checks the candidate against a model. A test suite checks behaviour across examples. Runtime monitoring checks whether the real world still matches the model. Human approval checks whether the action is allowed. Each control answers a different question.

Limits in APIs, Partial Observability, and Dynamic State

Classical planning is easiest when the state is explicit, the actions are deterministic, and the task structure is available before execution. Modern agents often violate all three assumptions. An API response can reveal a new object. A web page can change its layout. A permission can expire. A payment, deletion, or message can create an irreversible side effect.

These cases require a planning and execution loop rather than a static plan alone. The system may need to gather information, update its state estimate, ask for approval, and replan. It may also need procedural glue that is not part of the PDDL domain, such as handling pagination, converting data formats, refreshing authentication, or deciding what to do after a partial failure.

Security adds another boundary. The site’s MCP server security checklist and AI cybersecurity threats guide cover the permissions and untrusted-input problems that a planner cannot solve by itself. A formally valid plan can still be unsafe if the agent has more access than the task requires or if content is allowed to act as an instruction.

How to Evaluate a Planner Beyond One Benchmark

Evaluation should start with the deployment contract, not with the most flattering benchmark number. Define the task distribution, the cost of a failed action, the allowed latency, the tool permissions, and the conditions under which the system must ask for help. Then measure not only task success but also invalid-action rate, recovery rate, tool-call count, token cost, latency, human interventions, and the severity of failures.

Held-out testing matters because a generated planner can memorise the structure of its construction examples. Perturb object names, reorder irrelevant information, add missing data, introduce tool failures, and vary the goal while keeping the underlying task family. A planner that succeeds only when the prompt looks familiar is a template matcher, not a reusable planning system.

Reproducibility also matters. Record the model version, prompt, generated artefact, validator version, benchmark split, random seeds where applicable, and all tool responses. Without that record, a claimed improvement cannot be separated from a changed prompt, a changed evaluator, or a favourable test selection. For readers studying whether AI systems can anticipate complex outcomes, the site’s scientific forecasting analysis offers a related reminder, prediction quality depends on the evaluation design as much as on the headline result.

Conclusion: Generate Systems You Can Test

Planning in the LLM Era is not a choice between language models and classical planning. The more useful design is a division of labour. LLMs can help construct search components, formal models, and policies. Classical planners, validators, test suites, runtime monitors, and human approvals can constrain what happens next.

The evidence supports a narrower conclusion than the old article claimed. Planner generation is a promising way to reuse reasoning and reduce repeated model calls in suitable domains. SPIRAL shows that grounded, reflective search can perform strongly on the DailyLifeAPIs benchmark. VAL provides a practical formal-checking tool. None of these facts proves that a generated planner is correct in every environment.

The engineering standard should be simple to state. Generate an artefact, inspect its assumptions, validate it against an explicit model, test it on held-out cases, run it with limited permissions, observe the real state, and stop when the evidence no longer matches the plan. Reliability comes from the complete control system, not from a confident sentence produced at the start.