Kairos: Semantics-Aware Orchestration of Planning Engines across Classical, Numeric, Temporal and Hybrid PDDL
Authors: Francisco Martín Rico, Esther Aguado González, Francisco Miguel Moreno Olivo, Rodrigo Pérez Rodríguez, José Miguel Guerrero Hernández, Francisco J. Rodríguez Lera
Organizations: Intelligent Robotics Lab, Universidad Rey Juan Carlos, Spain · Robotics Group, Universidad de León, Spain
Planning at run time, as in robots that re-plan while they act, needs a planner that reads the PDDL its users write (durative actions, numeric resources, time windows, continuous change), answers quickly, and delivers only validated plans. Specialised planners are strong on individual fragments of PDDL, but they differ in coverage, latency and in what their failures mean. We study whether selecting heterogeneous engines from the semantics of each task can give broad coverage of PDDL, from STRIPS to PDDL+, while remaining competitive with specialised planners and making explicit what each answer guarantees. Kairos profiles each task to decide which of five engines apply (ground heuristic search, compressed and snap-action temporal search, time steps for hybrid dynamics, lifted search) and schedules them under one budget of time and memory. Every candidate plan is checked by a validator independent of the planner's transformations, and "unsolvable" is reported only when a search whose exhaustion is a proof exhausts its space. On 1,756 tasks from nine comparative suites, Kairos solves more tasks at the full limits than the strongest evaluated planner of each suite, with the largest differences on numeric, temporal, PDDL3 and PDDL+ planning, and it also solves the most tasks at 100 ms and 1 s. Resampling over domains, the gain is above zero in six of the nine suites, while on classical planning against LAMA it is within the noise. A further 450 feature-oriented tasks and 26 one-feature probes show that Kairos handles all seventeen features probed, where no other planner evaluated handles more than eight. Ablations identify compressed temporal search and the novelty fallback as major contributors, and a comparison with VAL traces every disagreement to a PDDL+ convention or to a documented VAL defect. Planner and benchmark are open source.
Figures & tables
Feature
LAMA
P.lifted
M-FF
ENHSP
POPF
OPTIC
TFD
LPG-td
NextFLAP
SMTPlan+
Kairos
conditional effects
✓
✗
✓
✓
✗
✗
\LEFTcircle
✗
\LEFTcircle
✗
✓
quantified preconditions
✓
✗
✓
✓
✓
✓
✓
✓
\LEFTcircle
\LEFTcircle
✓
disjunctive preconditions
✓
✓
✓
✓
\LEFTcircle
\LEFTcircle
✓
✓
\LEFTcircle
\LEFTcircle
✓
derived predicates
✓
✗
✗
✗
✗
✗
\LEFTcircle
✓
✗
✗
✓
numeric fluents
✗
✗
✓
✓
✓
✓
✓
✓
✓
✓
✓
non-linear numeric conditions
✗
✗
✗
✓
✗
✗
✓
✓
✓
✓
✓
Table 1. PDDL feature support, measured by execution rather than by declaration (Section 12.3 ). P.lifted: Powerlifted; M-FF: Metric-FF. Each planner ran, for 10 s, on 26 trivial tasks in the style of the IPC domains: one per feature, plus a variant with durative actions of each non-temporal one. ✓ : it solved the feature’s task with a plan that the validator accepts (for preferences, one that satisfies the preference). \LEFTcircle : partial or doubtful: it crashed or returned an invalid plan on the feature’s task, or solved only another task that uses the feature. ✗ : it rejected every task that uses the feature, or gave no answer. Symbols differ in shape as well as colour.
System
Fragments
Components
Budget
Validator
Unsolvable
FD Stone Soup, IBaCoP
classical
configurations
time
no
some
OPTIC, POPF
temporal, numeric
one planner
–
no
no
ENHSP
numeric, PDDL+
configurations
–
built in
some
Unified Planning
per engine
external planners
–
yes
per engine
Kairos
all of Table 1
five engines
time, memory
yes
per engine
Table 2. Design differences with the closest systems. Budget: what the components share; Validator: whether the system validates plans itself; Unsolvable: which answers of unsolvability are proofs (Kairos: Table 3 ).
Figure 1. The pipeline of Kairos. The orchestrator runs phases over the engines that the task profile allows, all under one budget of time and memory; grounding hands over to the lifted engine when it does not fit. The validator reads the parsed PDDL, not the planner’s task.
Fragment
Engines
Unsolvable only when
Optimality
classical, numeric (no time)
M1, lifted
M1 or the lifted engine exhausts the reachable space (Prop. 8.1 )
proven when a restart pruning by cost exhausts (Prop. 8.2 )
temporal, simple by value, fixed durations
M2, M3
the task without times has no path to the goal (Prop. 5.6 ); never from M2 (Example 5.5 )
not pursued: search optimises makespan
temporal with required concurrency or timed literals
M3
the task without times has no path to the goal (Prop. 5.6 ); never from M3 (memoisation is incomplete)
not plan cost
duration inequalities, continuous effects, PDDL+
time steps
never: no plan found
not plan cost
any
any
or grounding proves a goal unreachable even ignoring deletes
Table 3. What unsolvable and optimal mean, per fragment. Every returned plan has passed the validator (Section 9 ), under the semantics and tolerances stated there.
Fragment
A validated plan is
classical, numeric (no time)
valid under the semantics of PDDL, as parsed, in floating point
temporal
valid under the semantics of PDDL 2.1, with ϵ=0.001 and a duration tolerance of 0.001
PDDL+, linear change
valid under ENHSP’s convention for steps at the same instant, with exact integration up to floating point
non-linear dynamics
accepted by a numerical integration (RK4, steps of 0.01 s, bisection on watched conditions); not certified
Table 4. What validation guarantees for each fragment. Validity refers to the PDDL model; it does not imply that the plan can be executed by a physical system.
Suite
Tasks
Content
Classical
220
IPC 1998–2023, 10 per domain
Numeric
420
IPC 2002, 2023, 2026, 10 per domain
Temporal
225
IPC 2002–2014, 5 per domain
Concurrency
55
required concurrency; temporal numeric
PDDL3
125
IPC 2006 preferences and constraints
PDDL+
255
hybrid domains; SMTPlan benchmarks
Table 5. Benchmark suites: 2 232 tasks in three groups. The nine comparative suites (1 756 tasks, from Classical to PlanSys2 at scale) are run by every planner that reads them (Tables 6 and 7 ); the feature bank (450 tasks) checks Kairos’s answers per feature, including the tasks without a plan of Section 12.6 , and is not compared; the 26 probes serve only Table 1 .
Suite (tasks)
Planner
100 ms
1 s
limit
Classical (220)
Kairos
76
111
166
LAMA (anytime)
–
–
160
lama-first
0
75
159
Dual-BFWS
57
88
133
Numeric (420)
Kairos
168
216
299
ENHSP
0
128
208
Table 6. Tasks solved with a valid plan within 100 ms, 1 s and the limit, with uncorrected times; per suite, Kairos and the best other planners. Every planner, with the counts without the start-up of Apptainer, is in Table 12 .
Figure 3. Tasks solved against time to the first plan (log scale), per suite: Kairos and the two best other planners that report their first plan. Grey lines at 100 ms and 1 s.
Suite
Best other
Δ solved
95% interval
domains + / −
sign test p
Classical
LAMA
+6
[-7, +17]
10 / 3
0.092
Numeric
ENHSP
+91
[+40, +143]
24 / 6
0.001
Temporal
LPG-td
+55
[+31, +80]
24 / 6
0.001
Concurrency
POPF
+9
[-1, +22]
3 / 1
0.625
PDDL3
OPTIC
+41
[+15, +67]
15 / 6
0.078
PDDL+
SMTPlan+
+113
[+73, +155]
22 / 0
< 0.001
Table 7. Difference in tasks solved at the limit between Kairos and the best other planner, with a bootstrap interval over domains, the domains where each solves more, and a two-sided sign test over those domains.
Suite
solved
p50 (s)
p90 (s)
p99 (s)
Classical
166
0.145
17.09
28.46
Numeric
299
0.053
9.94
25.52
Temporal
180
0.061
3.76
26.08
Concurrency
33
0.012
0.65
4.77
PDDL3
86
0.026
2.04
22.40
PDDL+
148
0.307
6.58
20.65
Table 8. Time to Kairos’s first plan over the tasks it solves: median and 90th and 99th percentiles.
Suite
Planner
IPC score
tasks with a cost
Classical
Kairos
154.5
166
Classical
LAMA
152.5
160
Classical
lama-first
127.4
159
Classical
Scorpion Maidu
148.1
154
Classical
Scorpion Maidu agile
113.4
142
Classical
Levitron
149.5
156
Table 9. Quality at the limit (IPC score) on the suites where all planners report the problem’s metric.
Suite
Variant
100 ms
1 s
limit
Temporal
full
102
147
180
M2 only
101
146
179
M3 only
49
86
124
Concurrency
full
25
32
33
M2 only
5
5
5
M3 only
25
32
33
Table 10. Ablation: Kairos against variants that run one engine or one search configuration alone ( --engine , --search ), same limits and protocol.
Task (family)
Kairos
lama-first
OPTIC
POPF
ENHSP
object-fluents/delivery
unsolvable
error
error
error
error
object-fluents/delivery-time
unsolvable
error
error
error
error
object-fluents/elevator
unsolvable
error
error
error
error
object-fluents/keys
unsolvable
error
error
error
error
timed-initial-fluents/charger
unsolvable
error
error
error
error
timed-initial-fluents/market
unsolvable
error
error
error
error
Table 11. Answers on the eleven generated tasks of the feature bank that have no plan. “error”: the planner rejected the task (none of them supports object fluents, timed initial fluents or the warehouse’s features).
Appendix figures & tables2 assets
Supplementary material from the paper’s appendix.
Appendix
Suite
Planner
100 ms
1 s
limit
Classical
Kairos
76
111
166
LAMA
–
–
160
lama-first
0
75
159
Scorpion Maidu
–
–
154
Scorpion Maidu agile
0
73
142
Levitron
–
–
156
Appendix
Table 12. Tasks solved within 100 ms, 1 s and the limit, by every planner, with uncorrected times; in parentheses, the counts without the start-up of planutils’s Apptainer images. “of n ”: a run on a subset of the suite.
Since the introduction of the PDDL+ modeling language, it was known that temporal planning with durative actions (as in PDDL 2.1) could be compiled into PDDL+. However, no practical compilation was presented in the literature ever since. We present a practical compilation from temporal planning with durative actions into PDDL+, fully capturing the semantics and only assuming the non-self-overlapping of actions. Our compilation is polynomial, retains the plan length up to a constant factor and is experimentally shown to be of practical relevance for hard temporal numeric problems.
Andrea Micheli, Enrico Scala, Alessandro Valentini
Fondazione Bruno Kessler, Trento, Italy · University of Brescia, Italy
We present GenePlan (GENeralized Evolutionary Planner), a novel framework that leverages large language model (LLM) assisted evolutionary algorithms to generate domain-dependent generalized planners for classical planning tasks described in PDDL. By casting generalized planning as an optimization problem, GenePlan iteratively evolves interpretable Python planners that minimize plan length across diverse problem instances. In empirical evaluation across six existing benchmark domains and two new domains, GenePlan achieved an average SAT score of 0.91, closely matching the performance of the state-of-the-art planners (SAT score 0.93), and significantly outperforming other LLM-based baselines such as chain-of-thought (CoT) prompting (average SAT score 0.64). The generated planners solve new instances rapidly (average 0.49 seconds per task) and at low cost (average $1.82 per domain using GPT-4o).
Andrew Murray, Danial Dervovic, Alberto Pozanco +1
Task planning, the problem of sequencing actions to reach a goal from an initial state, is a core capability requirement for autonomous robotic systems. Whether large language models (LLMs) can serve as viable planners alongside classical symbolic methods remains an open question. We present PyPDDLEngine, an open-source Planning Domain Definition Language (PDDL) simulation engine that exposes planning operations as LLM tool calls through a Model Context Protocol (MCP) interface. Rather than committing to a complete action sequence upfront, the LLM acts as an interactive search policy that selects one action at a time, observes each resulting state, and can reset and retry. We evaluate four approaches on 102 International Planning Competition (IPC) Blocksworld instances under a uniform 180-second budget: Fast Downward lama-first and seq-sat-lama-2011 as classical baselines, direct LLM planning (Claude Haiku 4.5), and agentic LLM planning via PyPDDLEngine. Fast Downward achieves 85.3% success. The direct and agentic LLM approaches achieve 63.7% and 66.7%, respectively, a consistent but modest three-percentage-point advantage for the agentic approach at 5.7× higher token cost per solution. Across most co-solved difficulty blocks, both LLM approaches produce shorter plans than seq-sat-lama-2011 despite its iterative quality improvement, a result consistent with training-data recall rather than generalisable planning. These results suggest that agentic gains depend on the nature of environmental feedback. Coding agents benefit from externally grounded signals such as compiler errors and test failures, whereas PDDL step feedback is self-assessed, leaving the agent to evaluate its own progress without external verification.
Kai Göbel, Pierrick Lorang, Patrik Zips +1
AIT Austrian Institute of Technology GmbH, Vienna, Austria