From English to Plans: The NL-to-PDDL Frontier

Post 5 showed that when PDDL is given, the combination of LLMs and formal planners achieves remarkable results — 82% accuracy versus 12% for LLMs alone. But it left a critical question unanswered: who writes the PDDL?

For the RoboSort warehouse, we wrote PDDL by hand in Post 2. That took expertise. We defined robot-at, holding, supports, place-on-piece — every predicate, every action, every precondition. A planning expert could do this for a standard warehouse. But what about the user who simply says:

"I have a robot in a warehouse with three shelves. It can carry one item. Some pieces need support underneath. Help it build a tower."

No types. No predicates. No action schemas. Just English. This is Paradigm 2 — the system must create the formal model from scratch, validate it, solve it, and return a verified plan. It's the most ambitious goal in the LLM-planning research landscape, and it's where the field's most exciting work is happening right now.

The NL-to-Plan Pipeline

Converting English to a verified plan requires five stages. Each one is hard. Getting all five right, in sequence, is extraordinarily hard.

Let's trace the pipeline for our RoboSort warehouse:

The English description below corresponds to this exact configuration · the NL-to-PDDL pipeline has to recover all of it from plain text

1. English Description: "A robot in a warehouse with three shelves (A, B, C) and a build zone. Shelf A has two legs, Shelf B has a beam, Shelf C has a roof and a flag. The robot starts at home and can carry one piece. Legs support beam, beam supports roof, roof supports flag. Build the tower."
2. Extract Types, Predicates, Actions: The LLM must infer that there are locations (shelves, build zone, home), pieces (L1, L2, beam, roof, flag), and predicates like robot-at, piece-at, holding, supports, placed. It must also infer the action schemas: move, pick, place-on-platform, place-on-piece — each with correct preconditions and effects.
3. Generate PDDL: The LLM writes syntactically valid PDDL domain and problem files — the same code we wrote by hand in Post 2.
4. Validate & Fix: A PDDL parser checks syntax. A validator checks semantic consistency. If errors are found, the LLM gets feedback and fixes them.
5. Solve & Return: A classical planner (Fast Downward, etc.) solves the validated PDDL and returns the plan.

(:objects 
  robot - robot
  shelf-a shelf-b shelf-c home build-zone - location
  L1 L2 beam roof flag - piece)

(:init 
  (robot-at robot home) (gripper-empty)
  (piece-at L1 shelf-a) (piece-at L2 shelf-a)
  (piece-at beam shelf-b)
  (piece-at roof shelf-c) (piece-at flag shelf-c)
  (supports L1 beam) (supports L2 beam)
  (supports beam roof) (supports roof flag))

(:goal 
  (and (placed L1) (placed L2) (placed beam)
       (placed roof) (placed flag)))

Each stage is a point of failure. The LLM might miss a predicate (stage 2), generate syntactically invalid PDDL (stage 3), or produce semantically correct PDDL that doesn't match the user's intent (stages 2–3). This is why the field converged on multi-agent systems — specialized agents for each stage, coordinated by an orchestrator.

NL2Plan: The Multi-Agent Approach

NL2Plan (Gestrin et al., 2025) is the most systematic framework for this problem. Instead of asking a single LLM to do everything, it decomposes the pipeline into specialized agents, each responsible for one stage.

The key innovation is the decomposition. Instead of one massive prompt ("convert this English to PDDL"), NL2Plan breaks the task into focused queries: "What types of objects exist in this description?" then "Given these types, what predicates describe their relationships?" then "Given these types and predicates, what actions can the robot perform?" Each agent can use few-shot examples and targeted prompts for its specific subtask.

RoboSort Through NL2Plan

Here's how NL2Plan processes our warehouse description, transforming natural language into the same PDDL we wrote by hand in Post 2:

(define (domain robosort-tower)
  (:requirements :strips :typing)
  (:types location piece)
  (:predicates
    (robot-at ?l - location)
    (piece-at ?p - piece ?l - location)
    (holding ?p - piece)
    (gripper-empty)
    (supports ?lower ?upper - piece)
    (on-platform ?p - piece)
    (placed ?p - piece))

  (:action move
    :parameters (?from ?to - location)
    :precondition (robot-at ?from)
    :effect (and (robot-at ?to)
                 (not (robot-at ?from))))

  (:action pick
    :parameters (?p - piece ?l - location)
    :precondition (and (robot-at ?l)
                       (piece-at ?p ?l)
                       (gripper-empty))
    :effect (and (holding ?p)
                 (not (piece-at ?p ?l))
                 (not (gripper-empty))))
  ...
)

The Orchestrator Bottleneck

NL2Plan achieves impressive results on standard domains. But it has an Achilles' heel: the orchestrator. The orchestrator is the conductor of the multi-agent pipeline — it decides when to call each agent, how to route feedback, when a PDDL file is "good enough" to pass to the solver, and when to give up and restart.

Here's the problem: the orchestrator is also an LLM. And the orchestration task is itself a planning problem — one that requires sequencing agents, tracking state (which agents have run, what errors remain), and backtracking when a strategy fails. Sound familiar?

In practice, this manifests as three failure modes:

1. Premature advancement: The orchestrator declares the PDDL "done" when it still has subtle errors — a missing predicate, an action with an incomplete effect list. The planner then fails or produces an incorrect plan.
2. Infinite revision loops: The validator reports an error, the fixer introduces a new error while fixing the first, the validator catches the new error, and the cycle repeats. The orchestrator doesn't recognize the loop.
3. Missing abstractions: The user's description implies a concept the LLM doesn't extract. For RoboSort, the phrase "pieces need support underneath" implies a supports predicate, a placed predicate, and a precondition on the place action. If the extractor misses any of these, the resulting PDDL allows invalid tower constructions — and the orchestrator may not catch it because the PDDL is syntactically valid.

Orchestrator Failure on RoboSort

Let's see what happens when NL2Plan processes a subtly ambiguous RoboSort description:

Agentic PDDL: A Different Approach

In parallel with NL2Plan, La Malfa et al. (2025) introduced Agentic PDDL, which takes a different approach to the orchestration problem. Instead of a fixed pipeline, it uses a conversational loop: an LLM generates PDDL, a formal tool validates it, and the LLM iteratively refines — but with a critical addition: the user stays in the loop.

When the system encounters ambiguity — "do the legs need to both be placed before the beam, or can one leg suffice?" — it asks the user. This solves the missing-abstraction problem by making implicit constraints explicit through dialogue.

For RoboSort, this might look like:

Seeing the Full Pipeline: English to Plan

Let's watch the complete NL-to-Plan pipeline process our RoboSort warehouse description — from English input to verified plan output. Each stage shows what happens under the hood.

The Landscape: Where Paradigm 2 Stands

Paradigm 2 results are mixed but improving rapidly. Here's the current picture:

The pattern tells a familiar story. When the domain is well-known — Blocksworld, logistics, standard problems from planning competitions — the LLM effectively has the PDDL in its training data and can reproduce it. When the domain is novel, accuracy drops sharply. This is the same pattern-matching vs. reasoning distinction from Post 4's Mystery Blocksworld, now appearing at the model generation level.

Three open challenges define the frontier:

1. Implicit constraints. The RoboSort support constraint ("legs support beam") is stated explicitly. But many real-world constraints are implicit: "the robot can't carry two items" implies a gripper-empty predicate and a precondition on pick. Extracting these from natural language requires world knowledge, not just text parsing.
2. Compositional generalization. Can a system that has seen Blocksworld and logistics separately solve a problem that combines block-stacking and logistics? Current systems struggle because PDDL generation is treated as pattern matching, not compositional reasoning.
3. The orchestrator gap. The conductor of the multi-agent pipeline is the least reliable component. It must plan the PDDL generation process, handle failures, and decide when to ask the user for clarification vs. when to guess. This meta-planning problem remains largely unsolved.

Paradigm 1 + Paradigm 2: The Full Picture

Let's step back and see how all six posts connect. The series has traced a clear arc from foundations to frontier:

The RoboSort warehouse has been our constant through all six posts. We watched it crash under a naive LLM plan (Post 1). We formalized it in PDDL (Post 2). We watched A* find the optimal path through its warehouse floor (Post 3). We watched GPT-4 fail and Mystery Blocksworld expose why (Post 4). We watched LLM-Modulo fix the plan in two iterations (Post 5). And now we've seen NL2Plan generate the PDDL from English (Post 6).

One question remains: can we build systems that learn to orchestrate better — that adapt their coordination strategies, handle novel domains more reliably, and close the gap between familiar and unfamiliar? That's the subject of the final post.

What's Ahead

This post showed the promise and limits of Paradigm 2. NL2Plan and Agentic PDDL demonstrate that English-to-plan is possible — achieving 100% on standard domains. But the orchestrator bottleneck means novel domains and ambiguous descriptions remain unreliable.

The final post asks the most forward-looking question in the series: can we build agentic AI systems for planning — systems that learn from their own failures, adapt their orchestration strategies, and handle novel domains without human intervention? The research frontier is moving fast, and the answers are starting to take shape.