Core claim
“Reasoning via planning” names an architectural choice: before an LLM agent acts, it externalizes a proposed path through the task. The plan can be a natural-language checklist, a numbered sequence of subgoals, a set of tool calls with variable bindings, a dependency graph, or a formal representation close to PDDL. Execution then proceeds step by step, sometimes with a separate executor model, sometimes with the same model, and sometimes with replanning after observations contradict assumptions.
The term “PDDL-style” should be read carefully. In classical planning, a plan is usually a sequence or partial order of actions that transforms an initial state into a goal state under a domain model. In most LLM-agent systems, the “domain model” is implicit in the prompt, tool descriptions, examples, and the model’s learned priors. The plan is not automatically sound, complete, or executable. It is a control artifact: a way to make the agent’s future work explicit enough to inspect, schedule, route to tools, parallelize, or repair.
The pattern is useful because LLMs are often better at solving a hard problem after decomposing it into tractable subproblems. It is dangerous because decomposition can create false confidence: a polished plan can be wrong, stale, too vague, or disconnected from the environment. The empirical literature supports a narrow conclusion, not a universal one: explicit planning tends to help on long-horizon, multi-step, tool-using, or coordination-heavy tasks, but it often adds avoidable overhead on short tasks and may duplicate work already internalized by strong Reasoning Models.
From STRIPS and PDDL to LLM-agent plans
Classical AI planning begins with a crisp abstraction: there is an initial state, a goal condition, and a set of operators. A planner searches for a sequence of operators whose application transforms the initial state into a state satisfying the goal. The original STRIPS system framed this as finding operators in a space of world models, using first-order formulas, resolution-style theorem proving, and means–ends analysis to produce an executable operator sequence. Its central separation—planning first, execution later—already resembles the modern plan-then-execute agent loop. Stanford AI Lab
PDDL emerged as a standardized language for defining planning domains and problems, especially for empirical comparison in planning competitions. The original PDDL work was produced for the AIPS-98 planning competition; later versions added temporal constructs, numerical objectives, derived predicates, timed initial literals, constraints, and preferences. Yale Computer Science The broad planning literature then expanded well beyond classical deterministic planning into temporal planning, scheduling, uncertainty, task decomposition, satisfiability, constraint satisfaction, model checking, and planning/acting loops. ScienceDirect
The connection to LLM agents is not that LLM agents literally solve PDDL problems. Most do not. The connection is that both traditions separate “what should be done” from “doing it,” and both encode tasks in terms of goals, intermediate states, actions, effects, and constraints. LLM agents usually replace a formal transition model with a natural-language or JSON-like plan, then rely on tool results, validators, and replanning to compensate for the absence of formal guarantees.
| Classical planning concept | PDDL / STRIPS meaning | LLM-agent analogue | Main difference |
|---|---|---|---|
| Initial state | Explicit predicates describing the world | User request, memory, retrieved context, current tool/environment state | Often incomplete, noisy, or implicit |
| Goal | Logical condition to satisfy | User objective, success criteria, acceptance tests | Frequently underspecified or value-laden |
| Action schema | Operator with parameters, preconditions, effects | Tool/function/API call, browser action, code execution, message to another agent | Effects may be uncertain, stochastic, or undocumented |
| Preconditions | Conditions required before action | Prompt constraints, tool input requirements, dependency checks | Usually not formally enforced unless validated |
| Effects | State changes after action | Observation, file change, API result, generated artifact | May require interpretation by another model |
| Plan | Sequence or partial order of actions | Numbered steps, subgoals, DAG, task graph, ReWOO-style variable plan | Often a heuristic scaffold rather than a proof |
| Planner | Search algorithm over models | LLM planner, sometimes aided by search or examples | Learned priors substitute for explicit transition models |
| Executor | System carrying out actions | Agent harness, worker model, tool router, browser/controller | Execution can fail for reasons absent from the plan |
| Validator | Plan checker or goal test | Unit tests, assertions, verifiers, human approval, environment feedback | Validation is often partial |
This table also shows why “PDDL-style decomposition” is a useful metaphor and a poor guarantee. A PDDL domain can be checked against an action model. An LLM plan may be readable, plausible, and still non-executable. The operational question is therefore not “did the model make a plan?” but “does the system have machinery for grounding, executing, checking, and repairing that plan?”
Hierarchical decomposition and HTN-like agents
Hierarchical Task Networks are the historical bridge between formal planning and many contemporary agent patterns. HTN planning decomposes high-level tasks into lower-level tasks using methods: instead of searching directly over primitive actions, the planner recursively refines abstract tasks until executable actions remain. This is close to how agent developers often prompt an LLM: “break the user goal into subtasks; solve each subtask; synthesize the result.”
The resemblance is especially strong in multi-agent orchestration. A manager model receives a broad task, decomposes it into specialized subtasks, delegates those tasks to worker agents or tools, then synthesizes the outputs. Anthropic’s engineering guidance calls this an “orchestrator-workers” workflow: a central LLM dynamically breaks down tasks, delegates them, and synthesizes results, which is useful when the needed subtasks cannot be predicted in advance. Anthropic OpenAI’s agent guide similarly discusses multi-agent manager and handoff patterns, where agents are composed as tools or coordinated through decentralized routing. OpenAI
The HTN analogy also reveals a failure mode. If the decomposition method is wrong, every refined subtask inherits that error. An LLM can decompose “book the cheapest feasible trip under constraints” into flights, hotels, and attractions while silently omitting visa rules, cancellation constraints, or budget coupling. Hierarchical decomposition is powerful precisely because it compresses search; it is risky because it can hide constraint interactions that only appear when subtasks are recombined.
The basic plan-then-execute architecture
A minimal Plan-and-Execute Agents loop has six phases.
First, the system formulates the task. It extracts the objective, constraints, available tools, success criteria, and any state already known. This phase is often folded into the planner prompt, but in robust systems it is explicit: the planner should know the goal, the allowed actions, and what counts as completion.
Second, the planner emits a plan. The plan may be a list of steps, a dependency graph, a JSON schema, a tool-call program, or a set of natural-language subgoals. The plan should be concrete enough to execute but not so detailed that it overfits assumptions not yet observed.
Third, the harness normalizes the plan. It may validate schema, bind tool arguments, detect missing dependencies, reject forbidden actions, or ask the planner to repair invalid output. Without this step, a “plan” is just text.
Fourth, the executor performs each step. The executor may be the same LLM, a smaller model, a ReAct-style agent, a deterministic function, a code interpreter, a browser controller, or a human-in-the-loop operator.
Fifth, the system observes and verifies. Tool outputs, test results, files, logs, external state, and human feedback are compared against the step’s expected result and the overall goal.
Sixth, the system either continues, replans, or synthesizes the final answer. Replanning can be periodic, triggered by failure, or triggered by uncertainty. A final solver or synthesizer then converts the executed trace into a user-facing answer.
A compact pseudocode sketch:
task = formulate(user_request, context, tools, constraints)plan = planner(task)validated_plan = normalize_and_check(plan, tools, policy)state = initial_state(context)for step in schedule(validated_plan): result = executor(step, state, tools) state = update_state(state, step, result) if not verify(step, result, state): validated_plan = replan(task, state, remaining_steps(validated_plan)) continuereturn synthesize_answer(task, validated_plan, state)
The architecture has four major design choices.
One is the representation of the plan. A sequence is easiest to implement. A tree supports hierarchical decomposition. A graph supports parallel execution and explicit dependencies. A formal language supports validation and, in narrow domains, classical planning.
Another is the commitment model. Some systems commit to the whole plan, execute it, then summarize. Others replan after every observation. ReWOO-style systems decouple planning from observations more aggressively, whereas ReAct-style systems interleave reasoning, acting, and observation at each step.
A third is executor granularity. A step can be “research the competitors,” which requires another agentic loop, or it can be “call search(query=...)”. Coarse steps give the executor more autonomy; fine steps make scheduling and validation easier.
The fourth is the verifier. The difference between a useful plan and planning theater is often verification. If each step has no observable success condition, the plan mostly serves as motivational prose.
Contemporary instantiations
Plan-and-Solve prompting
Plan-and-Solve Prompting is the cleanest prompting-only version of the pattern. The model is prompted first to devise a plan that divides the task into subtasks, then to carry out the subtasks. The PS+ variant adds more detailed instructions intended to reduce calculation errors, missing-step errors, and semantic misunderstanding. In experiments over ten datasets across three reasoning categories, the authors report that Plan-and-Solve and PS+ consistently outperform Zero-shot-CoT under GPT-3, with PS+ reaching or exceeding stronger baselines on several tasks. ACL Anthology
The important point is not that “planning always wins.” The result is narrower: making decomposition explicit can improve zero-shot reasoning when the baseline is a direct or minimally scaffolded prompt. That is different from proving that explicit planning beats a modern reasoning model, a tuned agent harness, or a task-specific solver.
Least-to-most prompting
Least-to-Most Prompting is a related decomposition method. It first decomposes a complex problem into simpler subproblems, then solves them sequentially, feeding earlier answers into later ones. The method was designed to improve compositional generalization, especially when test problems are harder than prompt examples. arXiv
Least-to-most is not quite PDDL-style planning because it does not usually model actions, preconditions, or external state. But it shares the same core intuition: an explicit intermediate structure can reduce the cognitive load of a single forward pass.
ReAct as an interleaved alternative
ReAct Agents are often discussed alongside plan-and-execute systems because they also externalize intermediate reasoning. ReAct interleaves reasoning traces and actions: the model thinks, calls a tool or acts in an environment, observes the result, then reasons again. The ReAct paper and Google Research writeup emphasize that reasoning traces help the model track and update action plans, while actions let it obtain external information and interact with environments such as question answering, fact verification, ALFWorld, and WebShop. arXiv
ReAct is less “plan first” than “plan locally while acting.” It can be more robust when the environment is uncertain because the model does not have to commit to a long plan before observing. But it can be less efficient when every step requires another large-model call and when the overall task would benefit from global scheduling.
ReWOO: decoupling reasoning from observations
ReWOO—“Reasoning WithOut Observation”—is one of the canonical explicit-planning papers for tool-augmented LLMs. It argues that many augmented language model systems interleave LLM reasoning with tool observations, causing repeated prompts and redundant execution. ReWOO instead detaches reasoning from observations: a planner produces a blueprint with tool calls and variable placeholders; workers execute those calls; a solver integrates the evidence. The paper reports evaluation across six public NLP benchmarks and a curated dataset, including a 5× token-efficiency improvement and a 4% accuracy improvement on HotpotQA, plus robustness under tool failure and the ability to offload some work from GPT-3.5-scale models to a 7B LLaMA model. arXiv
ReWOO is especially important because it makes planning operational rather than merely rhetorical. The plan contains references such as “use the result of evidence step 1 in evidence step 2,” so it becomes a lightweight dataflow program. That is closer to a partial-order or dependency-aware plan than to a free-form chain of thought.
LangChain and LangGraph plan-and-execute agents
LangChain’s early “Plan-and-Execute Agents” blog presents the pattern directly: separate high-level planning from shorter-term execution. The planner generates steps; an executor handles each step, often as an action agent; the benefit is better long-term planning, while the major downside is additional calls and therefore higher latency or cost. LangChain
LangGraph’s later plan-and-execute examples show three variants: a basic planner/executor/replanner loop, a ReWOO-like architecture with variable assignment, and LLMCompiler-style planning over a dependency graph. The LangGraph writeup frames these architectures as ways to reduce repeated large-model calls, enable smaller executors, improve task decomposition, and in some cases schedule independent tool calls more efficiently. LangChain
The practical lesson is that “planning” becomes more valuable when it changes the execution graph. A plan that merely precedes the same serial tool loop may add overhead. A plan that enables routing, batching, parallel execution, smaller models, caching, or validation changes the economics.
LLMCompiler and plan graphs
LLMCompiler pushes the pattern from list-like planning toward graph execution. Its planner emits tasks with tools, arguments, and dependencies; a task-fetching unit schedules tasks when dependencies are satisfied; a joiner decides whether to finish or replan. The paper frames the motivation as reducing latency, cost, and error in sequential function-calling loops by enabling parallel execution where dependencies permit it. arXiv
This is one of the clearest modern analogues to partial-order planning. The system is not just asking the model to “think step by step.” It is compiling a task graph.
CrewAI planning
CrewAI exposes planning as an explicit framework feature. When planning is enabled, the framework sends crew information to an AgentPlanner, which produces a step-by-step plan that is added to each task description before execution. CrewAI Documentation This is a pragmatic multi-agent interpretation of HTN-like decomposition: each agent receives not only a task but also contextual instructions derived from a global plan.
The value here depends on whether the plan improves delegation. If agents already have clear roles and tasks, planning may be redundant. If coordination is the hard part, a shared plan can reduce duplicated work and inconsistent assumptions.
AutoGen and conversation-based orchestration
AutoGen is not reducible to a single plan-then-execute pattern, but it provides the substrate for planner/coordinator agents. Its documentation describes agents as software entities that communicate by messages, maintain state, and perform actions with external effects such as code execution or API calls. Microsoft GitHub Microsoft’s AutoGen materials describe the framework as supporting multi-agent systems, GroupChat-style coordination, and event-driven agent runtimes. Microsoft Learn
In AutoGen-like systems, the plan may appear as a coordinator message, a group decision, a task assignment, or a sequence of handoffs. The risk is that planning becomes distributed and implicit; unless the system records a stable plan artifact, coordination can degrade into conversational drift.
Engineering guidance from agent architecture analyses
Recent agent-architecture guidance is notably cautious. Anthropic’s “Building effective agents” argues that successful implementations often use simple, composable patterns rather than complex frameworks, and recommends adding complexity only when it demonstrably improves outcomes. It distinguishes predictable workflows from more autonomous agents, notes that prompt chaining can trade latency for accuracy, and warns that autonomous agents can incur higher cost and compounding errors. Anthropic+2Anthropic+2
OpenAI’s agent guide similarly emphasizes tool loops, multi-agent manager and handoff patterns, and the need to balance model capability, cost, and latency. It notes that developers may meet accuracy targets with strong models first, then optimize cost and latency by substituting smaller models where possible. OpenAI
These analyses support a disciplined view: planning is a pattern, not a virtue. It should be chosen when it improves reliability, observability, parallelism, delegation, or cost—not because every agent needs a grand strategy document.
Pattern taxonomy
| Pattern | Plan artifact | Execution style | Strength | Weakness |
|---|---|---|---|---|
| Direct execution | None or implicit | Model answers or acts immediately | Lowest overhead | Poor visibility on multi-step tasks |
| Chain-of-thought style reasoning | Hidden or textual reasoning trace | Single model pass or few passes | Improves reasoning on some tasks | Not necessarily executable or inspectable |
| Plan-and-Solve | Natural-language plan plus solution | Prompt-only decomposition | Simple, cheap to try | No external grounding unless added |
| ReAct | Local thoughts and actions | Interleaved observe–think–act loop | Adapts to observations | Can be slow and myopic |
| ReWOO | Upfront plan with evidence variables | Planner → workers → solver | Efficient tool scheduling and reuse | Less adaptive if initial plan is wrong |
| Plan-and-execute agent | Step list | Planner → executor → replanner | Clear separation of concerns | More calls, more orchestration |
| LLMCompiler-style agent | Dependency graph / task DAG | Parallel or dependency-aware execution | Lower latency for independent calls | Requires stronger plan validation |
| HTN-like multi-agent system | Task tree / delegation plan | Manager decomposes and delegates | Good for role specialization | Error propagation through hierarchy |
| PDDL/classical hybrid | Formal domain/problem and plan | LLM translates; planner solves; executor acts | Strong validation in narrow domains | Expensive domain modeling; brittle translation |
When planning beats direct execution
Explicit planning tends to help when the task has long horizons. A long-horizon task is not merely “many words.” It is a task where early choices constrain later options, intermediate results must be reused, or success requires satisfying multiple constraints over time. Examples include multi-source research synthesis, software migration, trip planning under constraints, data-analysis pipelines, benchmark-running workflows, and multi-agent coordination.
Planning also helps when the work has hidden dependencies. If step C requires outputs from A and B, a plan can make that dependency explicit. ReWOO’s evidence-variable design is valuable for this reason: the plan records which observations will feed later computations. arXiv LLMCompiler’s dependency graph extends this further by allowing independent branches to run in parallel and dependent branches to wait. arXiv
Planning helps when tool use is expensive. A model that reasons after every tool observation may repeatedly re-ingest the whole task, tool list, and previous trace. A plan can reduce repeated context and allow smaller worker models to execute narrow subtasks. ReWOO’s reported token-efficiency improvement is the clearest empirical example of this cost argument. arXiv
Planning helps when coordination matters. In multi-agent systems, a plan acts as a shared contract: which agent owns which subtask, what outputs are expected, and where dependencies lie. CrewAI’s planning feature operationalizes this by adding an AgentPlanner-generated step-by-step plan to task descriptions. CrewAI Documentation Anthropic’s orchestrator-workers workflow makes the same point at a higher level: central decomposition is useful when subtasks are unpredictable and need to be delegated dynamically. Anthropic
Planning helps when inspection or approval is required. A user, reviewer, or policy layer can approve a plan before irreversible actions occur. This is a safety and governance reason rather than a pure accuracy reason. In agent systems that can send emails, modify files, execute code, place orders, or affect external systems, an explicit plan is often the difference between controllable automation and opaque autonomy.
The empirical support is strongest for decomposition and search-like scaffolding on tasks that stress single-pass reasoning. Plan-and-Solve improves over Zero-shot-CoT across the evaluated datasets in the original paper. ACL Anthology Tree of Thoughts generalizes chain-of-thought by exploring multiple reasoning paths with evaluation and backtracking; on Game of 24, the authors report a large improvement over standard GPT-4 chain-of-thought prompting. arXiv DeepMind’s planning benchmark work likewise finds that in-context learning, supervised fine-tuning, and search procedures can all improve LLM planning performance. arXiv
More recent long-horizon agent work also supports the decomposition thesis. Plan-and-Act separates high-level planning from low-level execution and reports state-of-the-art results on WebArena-Lite and WebVoyager, two web-agent benchmarks where tasks require multi-step interaction rather than isolated text reasoning. OpenReview
When planning adds overhead or harm
Explicit planning is not free. It costs tokens, latency, engineering complexity, and often extra model calls. LangChain’s original plan-and-execute writeup names this directly: the main downside is more calls. LangChain Anthropic’s guidance makes the broader engineering point: many applications are adequately served by a single LLM call with retrieval and examples, and extra agent complexity should be added only when it improves outcomes. Anthropic
Planning can harm simple tasks. For “summarize this paragraph,” “extract these fields,” or “write a short regex,” an explicit plan is often ceremony. It may produce a better-looking process without improving the result. Worse, the plan can anchor the model on an unnecessary decomposition and introduce mistakes that a direct answer would not have made.
Planning can harm when the plan is too abstract. “Research the topic,” “analyze the evidence,” and “write the answer” are not useful action steps unless the executor already knows how to instantiate them. A plan should reduce uncertainty for the executor; if it merely restates the problem in generic phases, it adds context bloat.
Planning can harm when it is too detailed before observation. In uncertain environments, an upfront plan may assume facts that tool calls will later falsify. ReAct-style interleaving is often better when the next action depends heavily on the latest observation. This is why practical systems frequently combine both: plan coarsely, execute adaptively, replan when the environment disagrees.
Planning can harm when the model is already trained to reason internally. Modern reasoning models are explicitly trained to spend more time thinking before answering, refine strategies, and recognize mistakes. OpenAI describes o1 as designed to reason through complex tasks before responding; its later reasoning-model guidance describes o3 and o4-mini as trained to think before answering and to use tools more natively in agentic workflows. OpenAI+2OpenAI Developers+2 When such a model already performs internal decomposition, an external planner can duplicate the work unless it provides something the hidden reasoning process cannot: inspectability, scheduling, tool routing, human approval, or state persistence.
Planning can also create false assurance. The planning literature around LLMs is increasingly clear that generating plausible plans is not the same as planning reliably. PlanBench evaluates LLMs on planning-community domains and reports that key planning capabilities, including plan generation, fall short even for strong models. OpenReview TravelPlanner shows similar fragility in a realistic constraint-heavy domain: GPT-4-Turbo achieved a low final pass rate, and long noisy contexts made feedback and revision difficult. arXiv A 2025 evaluation of reasoning models on PDDL-style tasks found that stronger models handled simpler tasks but still struggled with complex tasks requiring precise resource management, state tracking, and constraint satisfaction compared with classical planners. arXiv
| Failure mode | How it appears | Why planning contributes | Mitigation |
|---|---|---|---|
| Overplanning | Extra plan for a trivial task | Planning overhead exceeds task complexity | Use direct execution below a complexity threshold |
| Hollow decomposition | Steps restate the task generically | Plan has no executable semantics | Require tool, input, output, and success check per step |
| False preconditions | Plan assumes facts not yet observed | Planner fills gaps with priors | Mark assumptions; verify before dependent steps |
| Stale plan | Later observations invalidate earlier steps | Upfront commitment persists too long | Trigger replanning on failed checks or changed state |
| Hidden coupling | Subtasks interact through shared constraints | Decomposition loses global constraints | Maintain global constraint ledger |
| Context bloat | Plan consumes tokens without guiding action | Too much prose, too little control value | Use compact schemas and dependency IDs |
| Executor mismatch | Step is too broad or too narrow | Planner ignores executor capability | Calibrate step size to tools and worker models |
| Unverifiable success | System cannot tell if step worked | No explicit goal test | Attach assertions, tests, or review criteria |
| Plan anchoring | Wrong early decomposition dominates | Later reasoning follows the plan uncritically | Permit replanning and alternative-plan comparison |
Planning as degenerate forward search
The relationship between explicit planning and Monte Carlo Tree Search is best understood through search.
A one-shot plan is a degenerate forward search. The model chooses a single trajectory through the space of possible actions: step 1, step 2, step 3, and so on. There is no explicit branching, no systematic comparison of alternatives, no value backup, and no guarantee that the selected trajectory is optimal. The model’s learned policy implicitly performs the branching and pruning inside a single generation.
Tree-search methods make the alternatives explicit. Tree of Thoughts asks the model to generate and evaluate intermediate “thoughts,” explore multiple reasoning paths, and use lookahead or backtracking. arXiv MCTS-style approaches go further by repeatedly selecting promising nodes, expanding possible actions, evaluating rollouts or partial solutions, and propagating scores backward. In LLM systems, this can be implemented with self-evaluation, external verifiers, reward models, or task-specific tests.
Under this view, plan-and-execute is the cheapest member of a family:
| Method | Branching | Evaluation | Backtracking | Cost | Best use |
|---|---|---|---|---|---|
| Direct answer | None explicit | Usually none | No | Lowest | Simple, familiar tasks |
| One-shot plan | One selected path | Optional | Usually no | Low–medium | Moderate multi-step tasks |
| Replanning loop | One path at a time | Observation-based | Limited | Medium | Uncertain environments |
| Tree of Thoughts | Multiple paths | Model or verifier scoring | Yes | Medium–high | Puzzles, search-heavy reasoning |
| MCTS-style search | Many sampled paths | Scoring plus backup | Yes | High | High-stakes branching tasks |
| Classical planner | Systematic over formal model | Goal test / plan validation | Yes | Domain-model cost | Formal domains with known actions |
This framing clarifies a common confusion. Planning is not the opposite of search; it is often a compressed or amortized form of search. A plan is a policy proposal. Search asks for multiple proposals, evaluates them, and chooses among them.
MCTS-style methods are most attractive when early choices are hard to reverse, the action space is branching, and a verifier can score partial or complete trajectories. They are less attractive when the task is straightforward, when evaluation is expensive or unreliable, or when latency budgets are tight. In production agents, a common compromise is to ask for a single plan, execute it with verification, and invoke broader search only when the verifier detects failure or uncertainty.
Relationship to reasoning models
Reasoning Models change the planning tradeoff because they internalize some of the decomposition workload. A strong reasoning model may already break a problem into subgoals, simulate alternatives, check intermediate results, and decide when to use tools. OpenAI’s official descriptions of o-series models emphasize longer internal reasoning before responding, improved strategy refinement, and stronger native tool use in reasoning workflows. OpenAI+2OpenAI Developers+2
This does not make explicit planning obsolete. It changes what explicit planning is for.
For weaker base models, external planning may improve raw reasoning. For stronger reasoning models, the marginal value shifts toward systems properties: auditability, controllability, scheduling, human approval, reproducibility, cost routing, and integration with tools. The external plan becomes less like “help the model think” and more like “make the system’s intended actions inspectable and executable.”
A useful distinction is between private reasoning and public planning. Private reasoning is the model’s internal deliberation. Public planning is the concise, inspectable action structure the system uses to coordinate execution. An agent does not need to expose hidden chain-of-thought to benefit from planning. It can expose a high-level plan with step IDs, dependencies, tool names, expected outputs, and validation checks.
Reasoning models also sharpen the overhead problem. If a reasoning model can solve a task directly in one call, forcing it through a planner, executor, and synthesizer may reduce quality by fragmenting context. Conversely, if a task requires many API calls, long-running state, or multiple specialized workers, even the strongest model benefits from an external control plane.
The open question: will explicit planning remain useful?
The open question is not whether future models will “be able to plan.” They already can, in many settings. The question is whether explicit planning remains architecturally useful as base reasoning improves.
The case against explicit planning is straightforward. If a model can internally decompose, search, use tools, and verify results, then an external plan may become redundant for many self-contained tasks. It may slow the system, expose brittle intermediate commitments, and require developers to maintain prompts and schemas that no longer add much value. This is already plausible for short coding tasks, local reasoning problems, routine summarization, and well-scoped tool calls.
The case for explicit planning is also strong. Many real tasks are not self-contained reasoning problems. They involve external state, long-running workflows, human stakeholders, irreversible actions, compliance constraints, multiple agents, partial failure, and cost control. In those settings, a hidden internal plan is insufficient. The system needs an external object that can be inspected, approved, scheduled, resumed, compared, logged, and verified.
The likely outcome is bifurcation. Explicit planning will become less useful as a generic prompting trick and more useful as a systems interface. “Think of a plan before answering” may fade for strong reasoning models. “Emit a typed task graph with dependencies, tool calls, expected outputs, and validation checks” will remain useful wherever LLMs operate inside larger software systems.
The evidence is still thin and contested. Agent benchmarks often mix planning ability with browsing, tool reliability, prompt design, retrieval quality, and environment brittleness. Planning evaluations such as PlanBench show that LLMs still struggle on formal planning capabilities. OpenReview Realistic benchmarks such as TravelPlanner show that constraint-heavy long-horizon planning remains difficult even for strong models. arXiv But agent frameworks and recent plan-and-act systems report practical gains from decomposition and separation of planner/executor roles. LangChain
A decisive evaluation would compare at least four systems under equal budgets: direct reasoning-model execution, explicit plan-and-execute with the same model, plan-and-execute with cheaper executors, and search-augmented planning. It should report not only success rate but also cost, latency, number of tool calls, repairability after injected failures, human inspectability, and sensitivity to task length. Without those measurements, claims that explicit planning is either essential or obsolete are premature.
Engineering principles for PDDL-style LLM planning
A robust planning agent should treat the plan as a hypothesis, not as truth. The planner proposes a path; execution and verification test it.
The plan should be typed. A useful schema includes a step ID, purpose, dependencies, inputs, tool or executor, expected output, success check, and fallback condition. The more external impact a step has, the more explicit its preconditions and approval gates should be.
The plan should be compact. Long natural-language plans consume context and invite rationalization. A good plan is closer to an executable outline than an essay.
The plan should distinguish assumptions from observations. Assumptions are things the model believes before acting; observations are things the environment or tools have returned. Mixing them is a major source of agent failure.
The executor should not blindly obey the planner. A worker model or tool wrapper should reject invalid arguments, missing dependencies, unsafe actions, and steps whose preconditions are not satisfied. In classical planning terms, execution should check whether the current state actually supports the next action.
Replanning should be triggered by evidence. Replanning after every step can waste calls and destabilize progress. Never replanning can preserve a bad plan. Good triggers include failed validation, changed external state, missing required output, exceeded budget, or discovery that a key assumption was false.
Plans should be evaluated by outcomes, not aesthetics. A readable plan that does not improve success, cost, latency, safety, or debuggability is not useful. Anthropic’s advice to add complexity only when it demonstrably improves outcomes is the right default for agent planning as well. Anthropic
Formal planning should be used when the domain model is real. If actions, preconditions, effects, resources, and goals can be specified accurately, a classical planner or hybrid LLM-to-PDDL system can provide stronger guarantees than an LLM-generated natural-language plan. If the domain model is mostly imaginary, formal syntax may only make hallucinations look rigorous.
A practical schema
A minimal structured plan for an LLM agent might look like this:
{ "goal": "Produce a cited comparison of approaches to explicit planning in LLM agents.", "constraints": [ "Prefer primary sources", "Do not use uncited factual claims", "Separate evidence from interpretation" ], "steps": [ { "id": "S1", "purpose": "Collect primary sources on classical planning", "dependencies": [], "executor": "research_tool", "inputs": ["STRIPS", "PDDL", "HTN planning"], "expected_output": "Source notes with citations", "success_check": "At least one primary or textbook source for each concept" }, { "id": "S2", "purpose": "Collect primary sources on LLM plan-and-execute methods", "dependencies": [], "executor": "research_tool", "inputs": ["ReWOO", "Plan-and-Solve", "ReAct", "LLMCompiler"], "expected_output": "Source notes with empirical claims", "success_check": "Claims include benchmark context and limitations" }, { "id": "S3", "purpose": "Synthesize architecture and tradeoffs", "dependencies": ["S1", "S2"], "executor": "reasoning_model", "inputs": ["S1.output", "S2.output"], "expected_output": "Structured article draft", "success_check": "Draft distinguishes formal planning from LLM scaffolding" } ]}
This is not PDDL, but it imports PDDL’s discipline: explicit state, explicit actions, explicit dependencies, and explicit success checks. It is also easier to validate than prose.
Design heuristics
Use explicit planning when the task has more than one meaningful phase, when intermediate outputs must be reused, when tools are expensive, when multiple agents need coordination, when a human may approve or edit the plan, when actions are irreversible, or when the plan can be represented as a dependency graph.
Avoid explicit planning when the task is short, when the model can answer directly with high reliability, when plan validation is impossible, when the plan would simply restate the prompt, or when the added latency is larger than the expected quality gain.
Prefer graph plans over linear plans when subtasks can run independently. Prefer hierarchical plans when tasks are naturally nested. Prefer ReAct-style interleaving when the environment is uncertain and the next action depends on fresh observations. Prefer ReWOO-style decoupling when the evidence needs are predictable and repeated LLM calls dominate cost. Prefer classical or hybrid planning when the domain has a real action model and correctness matters.
Most importantly, make the plan earn its place in the architecture. The plan should improve at least one measurable property: success rate, cost, latency, safety, debuggability, auditability, or human controllability.
Bottom line
Reasoning via planning is not a universal upgrade over direct generation. It is a way to externalize control. Its value depends on whether that external control surface can be executed, checked, repaired, and used by the rest of the system.
The classical planning tradition supplies the conceptual grammar: states, goals, actions, preconditions, effects, decomposition, and search. Modern LLM-agent systems supply a softer but more flexible implementation: natural-language or structured plans interpreted by models and tools. The strongest systems will likely combine both: reasoning models for flexible decomposition, explicit plans for coordination and auditability, verifiers for grounding, and search or formal planners when single-trajectory planning is not enough.
Companion entries
Core theory: Classical AI Planning, STRIPS, PDDL, Planning Domain Definition Language, Hierarchical Task Networks, State-Space Search, Partial-Order Planning, Planning and Acting
LLM agent patterns: LLM Agents, Plan-and-Execute Agents, ReAct Agents, ReWOO, LLMCompiler, Tool Use in LLMs, Agent Harnesses, Multi-Agent Orchestration, Agent State Management
Reasoning and search: Chain-of-Thought Prompting, Plan-and-Solve Prompting, Least-to-Most Prompting, Tree of Thoughts, Monte Carlo Tree Search, Reasoning Models, Verifier-Guided Reasoning, Self-Reflection in LLMs
Evaluation and evidence: PlanBench, TravelPlanner, WebArena, WebVoyager, Long-Horizon Agent Evaluation, Tool-Use Reliability, Agent Benchmark Design
Practice: Replanning Loops, Structured Output Schemas, Task Graphs, Human-in-the-Loop Agents, Context Engineering, Constraint Tracking, Tool-Call Verification, Prompt Chaining