The Modern Playbook: LLMs That Help Planners

Post 4 delivered the bad news: LLMs can't plan. Not with chain-of-thought. Not with self-critique. Not with tree search. Frontier models solve about 12–30% of trivial Blocksworld problems — while a classical planner from 2004 hits 100% in under a second.

But that post also introduced a taxonomy of roles, and one role stood out: LLM as helper, not planner. What if, instead of asking the LLM to generate the full plan, you asked it to do what it's actually good at — write code, understand context, translate between representations — and let the formal planner handle the reasoning?

That's exactly what happened between 2023 and 2025. A series of breakthroughs showed that the combination of LLMs and formal planners dramatically outperforms either alone. Not by a small margin — from 12% to 82% on the same benchmarks where LLMs alone failed. This post covers the three approaches that made it work.

The Big Idea: LLM-Modulo

The most influential framework to emerge from the planning community's response to LLM limitations is LLM-Modulo, introduced by Kambhampati et al. (2024). The core insight is disarmingly simple: let the LLM generate, let the planner verify.

Here's why this works. LLMs are excellent at generating plausible plans — plans that look roughly right, with most pieces in approximately the right order. Post 4 showed they get 30% fully correct. But even the 70% that fail are usually close — one or two constraints violated, not total nonsense. The formal verifier catches exactly which constraints fail, and feeds that specific error back to the LLM. The LLM then fixes just that part.

This is fundamentally different from self-critique (Post 4), where the LLM tried to verify its own output. Self-critique failed because the LLM couldn't reliably detect violations. LLM-Modulo succeeds because the verifier is a formal tool — a PDDL validator that checks every precondition with mathematical certainty. The feedback isn't "this looks wrong" — it's "step 5 requires (placed beam) to be true, but beam has not been placed."

LLM-Modulo on RoboSort

Let's watch this loop in action on our warehouse robot. The LLM generates a plan for the 5-piece tower assembly. The PDDL verifier (using the domain from Post 2) checks every step.

Same warehouse as Posts 1–4 · LLM-Modulo iterates plan-generation with the PDDL verifier until all 5 pieces stack bottom-up

LLMs as Heuristic Designers

Remember from Post 3 that the heuristic function is everything in planning. Two planners with the same search algorithm but different heuristics can differ by orders of magnitude. The planning community spent 50 years crafting domain-independent heuristics like h_FF — but what if an LLM could generate domain-specific heuristics that are even better?

This is the second major breakthrough. Instead of asking the LLM to plan, ask it to write a Python function that estimates how far a given state is from the goal. Then plug that function into A* or GBFS (Post 3's search algorithms) as the heuristic. The search engine does the planning. The LLM just provides the guidance function.

Given this PDDL domain for a
warehouse robot that assembles
towers from pieces with support
constraints...

Write a Python function:
  def heuristic(state) -> float
that estimates the number of
actions needed to reach the goal.

The function receives the current
state as a set of ground atoms
(e.g., {"placed(L1)", "robot-at(
shelf-b)", "holding(beam)"}).

def heuristic(state):
    goal_pieces = ["L1","L2",
        "beam","roof","flag"]
    placed = sum(1 for p in
        goal_pieces
        if f"placed({p})" in state)
    remaining = len(goal_pieces)
                - placed
    # Each piece needs: move to
    # shelf, pick, move to BZ,
    # place = ~4 actions
    h = remaining * 4
    # Subtract if already holding
    if any("holding" in a
           for a in state):
        h -= 2  # skip pick+move
    return h

Why does this work so well? The LLM understands the domain semantics — it knows that warehouse robots need to travel between shelves, that each piece requires multiple actions, and that holding a piece reduces remaining work. Domain-independent heuristics like h_FF compute estimates purely from the PDDL structure, ignoring this semantic understanding. The LLM-generated heuristic captures domain knowledge that would take a human expert hours to encode.

Critically, the heuristic doesn't need to be correct. It just needs to be roughly right — pointing the search in the right direction. If the LLM's heuristic overestimates or underestimates, the search engine compensates. A bad heuristic makes search slower but doesn't make the plan wrong — the planner still checks every precondition. This is the beauty of the setup: the LLM contributes guidance, and the formal system contributes guarantees.

Thought of Search: LLMs That Think About Searching

The third breakthrough goes further. Instead of generating a heuristic function, what if the LLM generated an entire search policy — a strategy for which states to explore next, which actions to try, and when to backtrack?

This is the idea behind Thought of Search (Katz et al., 2025). The LLM is given the PDDL domain and prompted to generate, step by step, the search process itself: "I'm at state S. Available actions are A1, A2, A3. A1 seems most promising because it places a piece that enables the beam placement. Let me try A1. New state S'. Now available actions are..."

The LLM isn't just generating a plan — it's simulating the search. Each step is verified by the formal model. If the LLM proposes an action that violates a precondition, the system catches it immediately and asks the LLM to reconsider. The result is a guided search that combines the LLM's intuition about which actions to try with the planner's certainty about which actions are valid.

The Three Approaches at a Glance

Let's compare the three Paradigm 1 approaches side by side. Each gives the LLM a different role while keeping the formal planner in the loop for correctness.

The Results: From 12% to 82%

The numbers speak for themselves. On the same PlanBench problems where LLMs alone scored 12–30% (Post 4), LLM-Modulo and related approaches achieved dramatically higher accuracy.

Several things stand out:

1. The gap from 30% to 82% comes entirely from formal verification. The LLM is the same. The prompting is similar. The only difference: instead of trusting the LLM's output, you verify it and feed back errors. This simple architectural change nearly triples accuracy.
2. The remaining 18% gap is real. Some problems are hard enough that the LLM can't fix its plan even with specific feedback. It gets stuck in revision loops, making the same mistake repeatedly. This is where heuristic generation helps — by offloading the search entirely to a formal engine with LLM-designed guidance.
3. Self-critique is strictly worse than formal verification. When the LLM verifies its own plans (~22%), it performs worse than direct generation (~30%). When a formal tool verifies (~82%), performance more than doubles. The verifier matters more than the generator.

Back to the Warehouse: Scaling RoboSort

Throughout Posts 1–4, RoboSort assembled a 5-piece tower. That was enough to demonstrate the core concepts. But real warehouses don't have 5 pieces — they have 50, 500, or 5,000. How do these Paradigm 1 approaches scale?

Let's extend the warehouse. Instead of one tower with 5 pieces, imagine RoboSort must assemble three towers simultaneously — 15 pieces across 6 shelves, with shared aisles and a single build zone. The robot still carries one piece at a time. The support constraints still apply. But now there are aisle congestion constraints and a build order across towers.

The scaling pattern is clear. As problems grow, LLMs alone degrade rapidly — their context window fills up, state tracking becomes impossible, and constraint violations multiply. But the formal tools don't degrade. PDDL validators check constraints in polynomial time regardless of problem size. The combination degrades gracefully because the formal backbone provides structural support that scales.

The Remaining Gap: What Paradigm 1 Can't Do

For all its success, Paradigm 1 has a fundamental limitation: it requires PDDL. Someone — a domain expert, a planning engineer — must write the formal model. For RoboSort, that means specifying every action (move, pick, place), every predicate (robot-at, holding, supports), and every constraint in precise PDDL syntax.

This is the same bottleneck Post 3 identified: classical planners are extraordinarily powerful if given formal input. LLM-Modulo doesn't remove this bottleneck — it assumes the PDDL already exists and uses the LLM to help find plans within it.

For well-defined domains — logistics, manufacturing, standard warehouse operations — this is fine. Experts write the PDDL once, and LLM-Modulo handles new instances. But what about novel domains? What about a user who says:

That's the Paradigm 2 question. And it's the subject of the next post.

What's Ahead

This post showed how Paradigm 1 works: when PDDL is given, LLMs can dramatically amplify planners through generate-verify loops, heuristic code generation, and search simulation. The results are striking — 12% to 82% — and the architecture is simple: let each system do what it's best at.

But the requirement for hand-written PDDL is a bottleneck. Millions of potential planning problems are described only in English — user manuals, requirements documents, verbal instructions. Nobody is going to write PDDL for each one.

What if the LLM could create the PDDL? Not use it, not help search within it, but generate the formal model itself from a natural language description? That's the ambitious promise of Paradigm 2 — and it's where the most exciting (and most difficult) research is happening.