Robot Planning via LLM Proposals and Symbolic Verification

Abstract

Planning in robotics represents an ongoing research challenge, as it requires the integration of sensing, reasoning, and execution. Although large language models (LLMs) provide a high degree of flexibility in planning, they often introduce hallucinated goals and actions and consequently lack the formal reliability of deterministic methods. In this paper, we address this limitation by proposing a hybrid Sense–Plan–Code–Act (SPCA) framework that combines perception, LLM-based reasoning, and symbolic planning. Within the proposed approach, sensory information is first transformed into a symbolic description of the world in Planning Domain Definition Language (PDDL) using an LLM. A heuristic planner is then used to generate a valid plan, which is subsequently converted to code by a second LLM. The generated code is first validated syntactically through compilation and then semantically in simulation. When errors are detected, local corrections can be applied and the process is repeated as necessary. The proposed method is evaluated in the OpenAI Gym MiniGrid reinforcement learning environment and in a Gazebo simulation on a UR5 robotic arm using a curriculum of tasks with increasing complexity. The system successfully completes approximately 71–75% of tasks across environments with a relatively low number of simulation iterations.

1. Introduction

Planning is a central problem in artificial intelligence. It involves transforming a high-level goal into a sequence of steps that an agent can execute in order to achieve the desired outcome. Reliable planning is especially important when agents interact with unpredictable environments, where mistakes in reasoning or execution may accumulate and cause failure.

Classical planning approaches rely on symbolic world models. They can produce interpretable action sequences and behave predictably when the model matches the environment, but they degrade quickly when assumptions are violated (missing objects, wrong effects, partial observability, unexpected events), which forces manual maintenance of the model.

Reinforcement learning (RL) offers a different approach. Instead of relying on symbolic rules, an RL agent learns policies from interaction with the environment. This makes RL suitable for high-dimensional tasks such as robotics or games. However, RL methods typically require extensive training data and long training times. They are also limited in their ability to generalize: a policy trained in one environment often performs poorly when the task is modified or when new constraints are introduced [1,2].

Large language models (LLMs) have recently been proposed as an alternative tool for planning [3]. Their strength lies in flexible reasoning and their ability to represent tasks in natural language. LLMs can generate action sequences, propose subgoals, or even synthesize domain specifications. Early studies show that they can produce valid plans in simplified settings, but their output is inconsistent [4,5,6,7]. Failures often occur in longer tasks, or in situations where logical constraints must be satisfied exactly. This raises the question of how LLMs can be systematically combined with established planning methods in order to benefit from both flexibility and reliability.

We investigate this question in two settings:

• MiniGrid, a widely used benchmark for goal-directed tasks in a grid-world environment [8]. MiniGrid provides controlled conditions for evaluating planning systems and allows systematic analysis of errors.
• A robotic manipulation scenario, where a robot must execute high-level goals under physical and temporal constraints.

Both environments highlight different aspects of the planning problem: abstract reasoning in simulation, and grounding of plans in real-world actions. The contributions of this work are as follows:

• A framework that integrates LLM-based reasoning into a Sense–Plan–Code–Act (SPCA) loop, combining text generation with structured validation.
• An experimental study of LLM planning performance in MiniGrid tasks, including a taxonomy of common error types.
• A demonstration of how the same framework can be extended to a robotic manipulation setup, showing the portability of the approach.

The remainder of this paper is organized as follows. Section 2 reviews related work in symbolic planning, reinforcement learning, and LLM-based planning. Section 3 presents the proposed framework. Section 4 reports on experiments in MiniGrid and robotics. Section 5 analyzes the implications of the findings. Section 6 concludes the paper and suggests directions for future work.

2. Related Work

Classical planning provides the most established foundation for goal-directed reasoning in AI. In this setting, tasks are described through symbolic states and actions, typically encoded in the Planning Domain Definition Language (PDDL). The domain defines action schemas (preconditions/effects) and predicates, while the problem instance specifies objects, initial state, and goal conditions. Standard planners such as Fast Downward search over these state transitions to generate plans that are both sound and complete [9,10]. In practice, the dominant cost is model acquisition: choosing the right abstraction level, enumerating predicates and action effects, and keeping the specification consistent as tasks evolve. This makes classical planning strong in well-modeled settings but expensive to deploy and maintain when the environment or task distribution changes.

Reinforcement learning (RL) offers an alternative by optimizing policies through interaction with the environment. In grid-based environments such as MiniGrid and BabyAI, discrete-action baseline RL algorithms such as Proximal Policy Optimization (PPO), Advantage Actor-Critic (A2C) and Deep Q-Networks (DQN) have been applied to sparse-reward and partially observable tasks [1,11,12]. Although these methods achieve robust behaviors within a training distribution, they demand large numbers of samples and transfer poorly across task variations. Extensions such as STAP have aimed to sequence skills to handle longer horizons [13], but scalability remains limited.

Large language models (LLMs) are token predictors trained at scale on text corpora, which makes them effective at generating natural language and code [4,5]; while not designed for planning, their generative ability has been adapted to produce symbolic descriptions, action sequences, or control code. Alignment techniques such as instruction tuning and chain-of-thought prompting improve their reasoning ability [14,15,16,17], but they remain prone to hallucinations and logical errors.

Several works explore how LLMs can augment symbolic planning. LLM-Planner and LLM+P translate natural language into PDDL fragments or full problem files, relying on a symbolic planner for validation [18,19]. World-model PDDL builders extend this loop by iteratively refining domains and problems until a solution is found [20]. More advanced systems, such as Planning in the Dark and AutoTAMP, combine LLM proposals with automated critics or task-and-motion checks to ensure executability [21,22]. In these approaches, the LLM acts as a flexible generator, while external validators guarantee correctness.

Other research explores open-loop LLM planning without formal PDDL grounding. Inner Monologue introduces step-level feedback during execution [23], while Embodied Chain-of-Thought produces reasoning traces tied to perceptual input [24]. SayCan grounds language in a robot’s skill library by scoring each skill with two signals: how relevant it is to the goal and whether it is feasible in the current scene [25]. SayCan operates over a fixed, hand-designed skill library and selects among existing skills rather than synthesizing new symbolic operators or long-horizon plans. Feasibility is captured implicitly via learned value functions, which improves grounding but offers limited global constraint checking and weaker inspectability compared to explicit symbolic planning. Visual–language models (VLMs) pair visual encoders with language models to perceive and reason about scenes in natural language (e.g., open-vocabulary recognition, object–relation descriptions, affordance cues). VoxPoser links language to low-level control by producing 3D value maps over a voxelized scene, which guide a motion planner to generate executable trajectories [26]. In COME-Robot, GPT-4V serves as the VLM inside a closed-loop mobile manipulation system, interpreting RGB observations and proposing corrections during execution [27]. Vision–language–action (VLA) models take a step further by mapping multimodal observations (and language goals) directly to actions, coupling perception with policy generation. PaLM-E demonstrates embodied multimodal language modeling that conditions on images and robot state to emit action-relevant commands for real tasks [28], while OpenVLA provides an open-source VLA that learns end-to-end visuomotor policies from language-conditioned data [29]. VLM and VLA approaches enable flexible perception and control but typically require large-scale demonstration data and offer limited guarantees about constraint satisfaction. Their internal decision processes are difficult to verify, which complicates safety assurance in long-horizon or safety-critical tasks. In addition, running large multimodal models in closed-loop control can be computationally and financially expensive.

In parallel, program and skill synthesis focuses on composing reusable behaviors. Traditional frameworks such as MoveIt Task Constructor and Tesseract define tasks as sequences of stages with explicit feasibility checks [30,31]. PDDLStream integrates symbolic reasoning with continuous samplers to verify kinematic or geometric constraints during planning [32]. More recent LLM-based systems produce executable programs directly. While PDDLStream bridges symbolic and continuous planning, it relies on carefully engineered stream procedures and certificates, and performance is sensitive to sampling efficiency and heuristic guidance. Extending the system to new domains often requires substantial manual effort in defining new streams and validity checks. Code as Policies translates language instructions into code that calls robot controllers [33], ProgPrompt structures prompts to bias models toward constrained outputs [34], Instruct2Act generates Python loops for language-conditioned control [35], and Voyager demonstrates iterative skill acquisition through program generation in open-world tasks [36]. These systems reduce manual authoring effort but remain vulnerable to runtime errors.

Reliability has therefore become a central focus. Benchmarks show that language-driven robots may execute unsafe or logically invalid instructions if unchecked [37]. To address this, systems incorporate validators [21], runtime guardrails [38], and memory mechanisms. RAG-Modulo retrieves past relevant experiences for reuse [39], Memory³ improves consistency with a structured memory store [40], and multi-agent debate frameworks (MAD) introduce redundancy by cross-checking outputs [41]. These augmentations improve robustness but still depend on external critics to ensure safety.

Recent benchmarks have been introduced to better capture the limitations of current methods. PlanBench measures symbolic executability and reasoning about change [42], LoTa-Bench targets language-oriented task planners for embodied agents [43], and TravelPlanner evaluates feasibility under real-world constraints [44]. ActPlan-1K focuses on procedural planning in household activities with visual–language models [45], while MFE-ETP provides a broader evaluation of multimodal foundation models on embodied planning tasks [46]. Together, these benchmarks reveal recurring gaps: symbolic methods do not scale to open environments, RL requires excessive data, and LLM-based approaches struggle with constraint satisfaction and reliability.

In summary, symbolic planners guarantee validity but require complete models, RL policies achieve robustness at high cost, and LLMs provide flexibility at the expense of correctness. This motivates further exploration of hybrid frameworks where LLMs act as flexible proposers and external verifiers guarantee soundness.

3. Materials and Methods

3.1. The Framework: Sense → Plan → Code → Act

We address long-horizon tasks using a four-stage approach, Sense → Plan → Code → Act, SPCA. The central idea is that language models propose symbolic structure or code, while deterministic critics decide validity at critical points. Planning outputs are checked by a symbolic planner and validator, and code outputs are checked by a compiler and a simulator. If errors are found, the loop attempts bounded local repairs before returning to earlier stages. Figure 1 illustrates this pipeline, which we evaluate in both MiniGrid and a Robot Operating System 2 (ROS 2) + Gazebo robotic setup.

3.2. Sense

The Sense stage condenses raw input into a compact description that later stages can consume. For MiniGrid, the snapshot contains mission text, agent orientation, inventory, and a local egocentric grid. A global map is built incrementally to support replanning. For ROS 2 + Gazebo, a calibrated RGB-D camera observes the workspace. A vision–language model (SenseLLM) converts the image into a short scene summary describing objects, colors, and coarse spatial relations. Raw sensor streams remain accessible for actions during execution. All snapshots are checkpointed so that later repairs can resume from the same world state. Figure 2 shows an example of this process.

The vision prompt and image-handling details are described in Appendix D.

3.3. Plan

The Plan stage turns previous stage output together with the task description into a PDDL domain and problem. We use PlannerLLM, which drafts the files. The Unified Planning framework parses them and calls Fast Downward as the solver. TAMER validation then checks the resulting plan. If parsing, solving, or validation fails, the system enters a bounded repair loop with at most eight attempts. Each attempt summarizes the error and requests a targeted patch from the LLM. We use OpenAI GPT-o3 (version o3-2025-04-16) for fresh drafts and repair, and the lighter o4-mini (version o4-mini-2025-04-16) when reusing a trusted domain. Figure 3 shows the complete planning workflow.

Exact prompt templates and planning modes are provided in Appendixes Appendix B and Appendix E.

3.4. Code

The Code stage uses CoderLLM to generate or patch only the missing skills referenced in the plan. The produced small patches are guided by the PDDL schemas. Two critics enforce correctness. The first is compilation and reloading, which catch syntax and interface errors. The second is a test in the target environment (the Act stage), which handles semantic errors. If a patch fails, error traces are provided to the model. The system allows up to five repair attempts per skill. Successful patches are stored for reuse in later tasks. We use OpenAI Codex (codex-mini-latest) across all CoderLLM modes. In MiniGrid, skills are Python methods of an Agent class that emit primitive moves. In ROS 2 + Gazebo, skills are Python functions that interact with MoveIt 2 for motion planning and control.

The full code-generation prompts and repair protocol are detailed in Appendixes Appendix C and Appendix F.

3.5. Act

The Act stage executes a validated plan. Each symbolic step calls its bound skill, which then produces primitives or robot actions. Failure signals trigger repair at the code level. Only when repair budgets are exhausted does the system escalate to replanning.

We evaluate the framework in two environments. In MiniGrid/BabyAI, we use a curriculum of tasks with partial observability, including navigation, pickup, and unlocking. The environment itself provides termination signals, reporting success when goals are achieved and failure when retry budgets expire. Figure 4 shows one such task.

We use a curriculum with the following task groups (categories):

• Goal Navigation: Move to a target location in simple layouts.
• Static Obstacle Navigation: Go to a target while avoiding fixed obstacles.
• Hazard Avoidance: Reach the goal while avoiding dangerous tiles (i.e., lava).
• Pickup Only: Find and pick up a specified object.
• Open Door: Open unlocked doors.
• Memory Ordering: Use memory to perform actions in the right order.
• Unlock Door: Fetch a key and unlock a locked door.
• Unlock Pickup: Unlock doors and then pick up the target object.
• Obstacle Blocking: Move obstacles and open doors to reach the goal.

In ROS 2 + Gazebo, we use a UR5 arm with a Robotiq 2F-85 gripper, a static top-down RGB-D camera, and six colored objects on a table. Tasks include Touch, Pick-up, Pick-and-place, and Stack. Unlike MiniGrid, where the environment itself signals termination, here a Referee node monitors collisions and success conditions defined in YAML. It reports success only if all positive contacts hold and forbidden contacts are absent at the same time. The Referee also checks timeout conditions. The YAML task specification and the collision-based Referee logic are detailed in Appendix A. Figure 5 shows the simulated workspace.

The curriculum consists of the following task groups (categories):

• Touch: Move the gripper to make contact with a specified cube.
• Pick-Up: Grip and lift a target cube so it is no longer touching the table.
• Pick-and-Place: Pick up a cube and place it on a specified plate or next to another cube.
• Stack: Arrange multiple cubes by stacking them in the correct color order.

3.6. Evaluation

We evaluate the SPCA framework in each of the two environments, using a fixed curricula of tasks.

In MiniGrid we test task completion across categories of increasing difficulty and measure how often symbolic plans are reused versus regenerated. We also profile coding reliability under repair loops and track prompt budgets to estimate LLM cost. In ROS 2 + Gazebo we test transfer to a robotic simulator with realistic kinematics and sensing. Here we measure completion of manipulation tasks (touch, pick-up, pick-and-place, stack) while enforcing collision rules defined externally.

For both environments we report the following metrics:

• Completion rate (%): fraction of tasks solved within retry budgets.
• Execution time: wall-clock time per task, measured from sensing to final verdict.
• Planning diagnostics: counts of fresh (first-time domain), reuse (trusted domain reused), replan (new domain after failed rollout), and syntax (planner or validator rejection).
• Coding diagnostics: counts of first (success on first attempt), semantic (runtime or environment-level failure), and syntax (compile or import failure).
• Token budgets: prompt and completion tokens consumed by (SenseLLM), PlannerLLM, and CoderLLM.
• SPCA rounds: number of outer Sense–Plan–Code–Act cycles attempted per task.

In addition to the end-to-end SPCA evaluation, we also test the Plan stage in isolation. Given a description of the problem in natural language, the language model is tasked with generating a complete PDDL domain and problem pair, that is then parsed and solved by a classical planner. Twelve models are tested across eleven well-known problems. The metrics reported are the share of solved problems within a small repair budget and the average number of repair attempts when a valid plan is found.

4. Results

4.1. Planning (PDDL Generation)

The planning stage was evaluated independently to compare language model performance on standardized PDDL problems. Each model receives a textual prompt and must produce valid domain and problem files. Twelve models were tested across eleven domains (Blocksworld, Gripper, Depot, Driverlog, Satellite, Rovers, Tyreworld, Storage, Logistics, Termes, Floortile). Smaller local models under 8B parameters (run with Ollama: llama3.2, phi4-mini-reasoning, qwen3, gemma3, deepseek-r1:8b) fail to produce valid PDDL syntax and therefore solve no tasks. Consequently, all reported results are from seven larger OpenAI models.

Figure 6 reports the number of problems solved at attempt k (Solved@k) across five trials per model. All models improve with additional repair attempts, confirming that the fixed retry loop helps recover near-miss generations. No model solves all problems at k = 1, but stronger models fix most issues in early attempts and then stagnate after about seven retries.

Figure 7 presents the percentage of problems solved within 10 retry attempts, together with the average number of attempts when success occurs. Each model–problem pair was repeated five times. These results are indicative rather than conclusive due to the small sample size. The best-performing models are gpt-5-mini, gpt-5, o4-mini, and o3, all reaching above 90% success within 10 attempts, with only gpt-5-mini solving all problems. gpt-5-mini also needed the fewest attempts on average (1.47), followed by gpt-5, o3, and gpt-4.1 (1.65), and o4-mini (2.42).

Note that models marked with a star in Figure 6 and Figure 7 do not support structured output and were prompted to return plain-text PDDL instead of JSON.

4.2. MiniGrid

We evaluated SPCA on 76 MiniGrid/BabyAI levels across 8 categories on a curriculum with a total of 102 levels across 9 categories.

Table 1. Runtime and dataset statistics for MiniGrid.

Quantity	Value
Curriculum totals
Total levels	102
Categories	9
Completion rate	74.51%
Simulation runs	325
Evaluated subset
Evaluated levels	76
Evaluated categories	8
Runtime/logs
Planner API calls	142
Coder API calls	225
Active span	252.49 min
Time per level	$3.12\pm 6.45$ min
SPCA rounds per level	$1.38\pm 1.00$
SPCA rounds (total)	112

summarizes scope and runtime. The system completes 74.51% of all 102 levels in 325 runs, with an average of $1.38\pm 1.00$ SPCA rounds per level on the evaluated subset. All further statistics are calculated on the 76 evaluated levels.

Figure 8 depicts cumulative levels solved over time. The curve rises steeply at the start, indicating that the early levels are solved efficiently and reused in later tasks. The curve then flattens for categories like Open Door, Unlock Door, and Unlock Pickup, which require more retries and repairs. The Memory Ordering category stabilizes faster, suggesting stronger reuse of existing code and logic. A short execution video of the final MiniGrid agent is provided in the Supplementary Materials.

Planner behavior is summarized in

Table 2. Planning loop statistics in MiniGrid.

Label	Per–Level Mean ± SD	Calls (Share)
fresh	$0.10\pm 0.30$	8 (5.6%)
reuse	$0.85\pm 0.36$	69 (48.6%)
replan	$0.38\pm 1.00$	31 (21.8%)
syntax	$0.42\pm 0.94$	34 (23.9%)

. Most cases reuse a trusted domain, while syntax errors and fresh drafts occur less often.

Table 3. Coding loop statistics in MiniGrid.

Label	Per–Level Mean ± SD	Calls (Share)
first	$0.15\pm 0.36$	12 (5.3%)
semantic	$2.63\pm 6.12$	213 (94.7%)
syntax	$0.00\pm 0.00$	0 (0.0%)

indicates that most corrections happen during coding, with semantic retries dominating. Syntax errors did not occur, indicating strong coding reliability of current LLMs. The low number of new function generations (12 in total) compared to 76 solved levels highlights efficient reuse of modular skills.

A closer inspection of the execution logs provides additional insight into how often repair and reuse mechanisms are required in practice. When a new skill had to be implemented via fresh code generation, only 50.0% of these cases resulted in direct success without further modification. This indicates that semantic repair is frequently necessary to stabilize newly generated skills, even in the MiniGrid setting.

In contrast, reuse of an existing planning domain is strongly associated with efficient convergence. Among successful levels where a previously learned domain was reused, 87.9% completed in a single SPCA round, indicating that reuse typically avoids the need for additional replanning or repair cycles.

Finally, the overall semantic repair burden is highly concentrated. Across all levels, 213 semantic repair attempts were recorded, of which 79.8% were incurred by only ten levels. These cases correspond primarily to structurally more complex tasks, suggesting that most semantic repair effort is driven by a small number of particularly challenging environments rather than being uniformly distributed across the curriculum.

To better understand what drives the large share of semantic repairs, we inspected the execution-level failure signals in MiniGrid. The most common semantic failure is goal_not_reached, where the plan executes without runtime errors but ends in a non-final state. The second most common failure, occurring mostly in the early curriculum levels, is stuck, where the agent makes no progress after a fixed number of primitive actions.

The prevalence of goal_not_reached failures is largely explained by the structure of the environment: the space of valid states is dominated by non-final states. Even in a minimal 3 × 3 grid with the agent starting in the top-left and the goal in the bottom-right, only one out of nine positions corresponds to the goal (11.1%), so many action sequences can be valid yet still fail to reach the goal under a bounded execution horizon.

By contrast, stuck failures are primarily linked to partial observability. With the agent-centric 7 × 7 observation window, the agent cannot see the full map layout and may enter dead ends or cycles without recognizing them early. In these cases, SPCA eventually learns simple recovery behaviors, such as retracing recent steps and performing local exploration to escape loops and continue progress toward the goal.

Figure 9 shows per–category task durations. Long tails appear in Open Door and Memory Ordering, while navigation and hazard avoidance tasks remain shorter. This pattern aligns with the cumulative level success curve, where the same categories required additional retries and repair cycles.

Figure 10 reports token usage per category. Token consumption grows with curriculum depth as the code knowledge base expands, increasing the context size for both PlannerLLM and CoderLLM. The CoderLLM shows higher variance due to longer semantic errors and temporary code fragments appended during repair cycles. All errors are appended to the coder context only within a single SPCA cycle, and the context is reset after either a successful execution or a replan.

Table 4. Token usage and API cost by model (MiniGrid). Costs are computed from recorded token counts and OpenAI list rates ($/1M tokens) for input and output.

Model	Input Tok.	Output Tok.	Input $	Output $	Total $
codex-mini-latest	1,834,115	1,074,050	2.751	6.444	9.195
o3-2025-04-16	557,646	188,480	1.115	1.508	2.623
o4-mini-2025-04-16	392,107	113,731	0.431	0.500	0.932
Total	2,783,868	1,376,261	4.298	8.453	12.750

reports total input and output token counts together with the corresponding API cost for the MiniGrid experiments, broken down by model. Costs are computed using OpenAI list pricing as of October 22nd (see https://pricepertoken.com/pricing-page/provider/openai, accessed on 20 December 2025). The cost distribution mirrors the token usage trends in Figure 10, where the coding stage dominates overall token consumption. This is consistent with the higher number of coder calls and longer generated responses observed during semantic repair.

Comparison with Traditional RL

To compare SPCA with reinforcement learning methods, we recreated the baseline from the original BabyAI paper [8] using the same architecture (CNN for image processing, GRU for text instruction processing and LSTM for memory) and obtained similar results.

Table 5. RL success on selected BabyAI levels (validation batch of 512 episodes). Values are averaged across 10 trials. Last two columns are reported in thousands (min–max).

Level	SR@500 eps (%)	eps@70% SR	eps@99% SR
GoToRedBallGrey	26.0	0.8–1.4	9.8–40.0
GoToRedBall	37.2	0.9–1.4	9.8–65.1
GoToLocal	30.3	14.7–28.8	135.8–353.5
PickupLoc	14.8	52.7–163.9	186.3–882.3

reports the success rate after 500 episodes, as well as the number of episodes (in thousands) required to reach 70% and 99% success. At 500 episodes, performance remains low on all levels, and achieving near-perfect results requires anywhere from tens of thousands up to one million episodes.

Figure 11 shows the success curve for PickupLoc, where 882 k episodes are needed to reach 99% success. The curve follows a standard logarithmic shape with diminishing returns over time.

4.3. ROS 2 + Gazebo UR5

In the ROS 2 + Gazebo simulator, we tested 31 scenarios across four task groups. The system completes 70.97% of all levels. On the evaluated subset of 22 levels, the average time per task is $5.13\pm 1.72$ min with $1.38\pm 0.18$ SPCA rounds and 131 total runs.

Table 6. Runtime and dataset statistics for ROS 2 + Gazebo.

Quantity	Value
Experiment totals
Total levels	31
Categories	4
Completion rate	70.97%
Simulation runs	131
Evaluated subset
Evaluated levels	22
Evaluated categories	3
Runtime/logs
Sense API calls	114
Planner API calls	81
Coder API calls	108
Active span	113.0 min
Time per level	$5.13\pm 1.72$ min
SPCA rounds per level	$1.38\pm 0.18$
SPCA rounds (total)	30

summarizes runtime statistics.

Planning statistics appear in

Table 7. Planning loop statistics in ROS 2 + Gazebo.

Label	Per–Level Mean ± SD	Calls (Share)
fresh	$0.14\pm 0.19$	3 (3.7%)
reuse	$1.54\pm 0.55$	34 (41.9%)
replan	$0.46\pm 0.33$	10 (12.3%)
syntax	$1.54\pm 1.47$	34 (41.9%)

. Most tasks reuse existing domains, with replanning triggered by feasibility or collision constraints. The relatively high number of syntax repairs indicates that, despite reuse, the planner still rejects a non–negligible share of candidate domains or problems. Together, the four planner categories account for an average of 3.68 API calls per level. Coding results in

Table 8. Coding loop statistics in ROS 2 + Gazebo.

Label	Per–Level Mean ± SD	Calls (Share)
first	$0.46\pm 0.32$	10 (9.3%)
semantic	$4.46\pm 1.67$	98 (90.7%)
syntax	$0.00\pm 0.00$	0 (0.0%)

again show no syntax errors and mostly semantic repairs. Only 10 new skills were generated for 22 levels, confirming efficient code reuse. All further statistics are calculated on the 22 evaluated levels. An execution video is available in the Supplementary Materials.

Table 9. Token usage in ROS 2 + Gazebo (mean ± sd).

API	Tokens
SenseLLM	$14,448\pm 14$
PlannerLLM	$2930\pm 998$
CoderLLM	$13,478\pm 2778$

reports token usage across SenseLLM, PlannerLLM, and CoderLLM. SenseLLM and CoderLLM account for the majority of tokens, with SenseLLM slightly higher on average because it processes RGB images through the vision–language model, while the accompanying textual prompts with task specific instructions remain short. This also explains the very small standard deviation. CoderLLM is the second-largest contributor and shows higher variance because error traces and temporary code are appended during repair cycles. PlannerLLM has a smaller spread than in MiniGrid, as it processes only function signatures and docstrings instead of full code. Overall token usage still increases with later levels as the code knowledge base grows, even though this trend is not directly visible in the table.

5. Discussion

The standalone PDDL generation experiments indicate that strong LLMs can reliably draft solvable domain/problem pairs when paired with a planner/validator in a short, bounded repair loop, whereas smaller LLMs struggle with syntax. A practical limitation is that PDDL generation currently depends on strong proprietary LLMs: in our tests, all smaller open-source models below 8B failed to produce valid PDDL syntax, which limits accessibility and increases operational cost. One mitigation is to enforce syntax with a PDDL context-free grammar and structured output, reducing unparsable generations. A second mitigation is to fine-tune open models on PDDL to improve formatting and domain/problem consistency, while keeping the planner/validator loop as a semantic check. A third mitigation is to use larger open models that can match proprietary performance, at the cost of higher local compute requirements (GPU) or paid inference services. As seen in Figure 6, the feedback loop almost doubles performance from Solved@1 to Solved@10, confirming that structured error summaries and targeted patches convert many near-misses into solutions. We also observe diminishing returns after roughly seven attempts for the strongest models (e.g., o3, o4-mini), indicating that a budget of k = 10 is sufficient in practice. These trends align with recent systems that pair LLM proposals with formal checks and bounded patching [19,47,48,49].

The MiniGrid experiments show that symbolic planning stabilizes early in the curriculum. Once a domain has been accepted by the planner and validator, subsequent tasks are often solved with small edits rather than fresh models. This leads to a high share of domain reuse and relatively few syntax rejections. Failures happen primarily during execution, where cyclical exploration and action ordering errors trigger semantic retries in the coder loop. The coding stage therefore carries the main repair load, which is consistent with the design of SPCA. Most adjustments are small patches, such as adding guards, handling map boundaries, or retrying toggles. These patches converge into a reusable library of skills, making later tasks more efficient. The token use analysis confirms this trend: planner calls remain modest, while coder calls grow as the skill library expands. This growth increases cost and occasionally destabilizes behavior, which highlights the need for slimmer prompts that pass only relevant skills instead of full code contexts.

Reproducing the BabyAI baseline with the original CNN–GRU–LSTM architecture yields results consistent with the original paper [8]. The model requires close to one million episodes to reach 99% success on PickupLoc, while performance after 500 episodes remains low, around 14%, and near zero on harder levels such as PutNextLocal. Although later studies report moderate gains in sample efficiency [11,12,50,51,52,53], reinforcement learning still demands large amounts of training and transfers poorly even between tasks within the same environment. In contrast, SPCA achieves comparable performance in only a few simulation runs per level by combining symbolic validation that filters logically invalid plans, targeted code repair that fixes execution errors without discarding successful logic, and reuse of previously verified domains and skills. This difference highlights a practical trade-off: gradient-based exploration learns robust behaviors but at high cost, whereas structured validation and repair enable fast, compositional generalization, an advantage that becomes crucial when simulations are expensive.

In the ROS 2 + Gazebo setting, the same pattern emerges under more demanding conditions. Symbolic domains remain stable once established, with replanning triggered mostly by motion planning faults or referee detecting collision constraints rather than by syntax errors. As in MiniGrid, most adjustments here are handled by the coding stage, where small patches to skills fix execution problems without altering the higher-level plan. Semantic retries dominate, but syntax errors are filtered out by the compiler and reload checks. Successful patches often adjust approach heights, retreat distances, or gripper timing, which shows that execution-level repair can handle physical margins without discarding the symbolic plan. Token budgets follow the same division as in MiniGrid: SenseLLM remains constant, PlannerLLM is moderate, and CoderLLM grows with the accumulated skill base. The main failure mode is occlusion, which is expected with a single fixed top-down RGB-D camera. Because the camera is mounted above the workspace, the arm sometimes blocks objects, leading to scene descriptions that omit items required by the plan and thereby introduce inconsistencies during execution. From a systems perspective, this limitation is primarily a sensing issue rather than a planning one. Several straightforward upgrades could reduce occlusion-induced instability, including multi-view sensing through an additional side camera or a wrist-mounted camera on the end-effector to provide complementary viewpoints. Stability can also be improved by making execution more perception-aware, for example by re-sensing after large motions, inserting simple guards that verify object visibility before committing to the next substep, or repositioning the arm or camera when visibility is lost. Maintaining a persistent 3D workspace representation built from successive depth observations would further allow the system to retain object hypotheses across short occlusions, while lightweight instance segmentation can help separate objects from arm geometry and clutter. Together, these measures would reduce the propagation of missing-object descriptions into later stages and improve robustness on real hardware.

Our evaluation is simulation-only (MiniGrid and ROS 2 + Gazebo); while Gazebo captures geometry and basic physics, it does not reproduce many real-world factors such as sensor noise and calibration drift, contact uncertainty, unmodeled dynamics, and appearance changes. As a result, the reported success rates should be interpreted as proof-of-concept evidence for the SPCA loop under controlled conditions rather than sim-to-real validation. Closing this gap would require hardware experiments or higher-fidelity simulation with explicit noise/perturbation models, more robust perception, and safety-constrained execution.

Across both environments, the results highlight the importance of dual critics. By separating symbolic validation from code execution, the system can localize errors and apply small repairs rather than discarding entire plans. This makes the loop more sample-efficient than reinforcement learning, which often requires many episodes to discover reliable strategies, and more reliable than end-to-end LLM agents, which lack external checks. At the same time, limitations remain. The coder loop is heavy, often requiring multiple retries per level, and prompt growth is a practical bottleneck. The reliance on strong reasoning language models for valid PDDL generation also suggests that lighter models are not yet adequate for planning roles. Finally, the environments used here, although diverse, remain simplified testbeds. Generalization to real-world robotics with higher variability in tasks, objects, and sensing conditions remains an open question. Note, that real world poses additional challenges, such as reflection and other camera effects in different lighting conditions, the cost of unbound path planning (the robot arm can break), safety of subjects in the room, non availability of deterministic critic in the real world (how do we know a task is finished successfully or it failed), etc.

These findings suggest that SPCA occupies a useful position between classical planning, reinforcement learning, and purely generative LLM agents. Its explicit separation of high-level intent from low-level execution, combined with deterministic critics, yields interpretable outcomes and bounded loops. The approach shows promise for long-horizon tasks under partial observability and physical constraints, while also exposing clear avenues for improvement in perception, prompt efficiency, and validation coverage.

6. Conclusions

In this paper, we introduced the Sense–Plan–Code–Act (SPCA) framework, which combines language models with deterministic critics for planning and execution. The system was tested in MiniGrid and in a ROS 2 + Gazebo setup with a UR5 robot. In both domains SPCA solved most tasks within retry budgets. Symbolic plans stabilized quickly, and most corrections were handled by small code patches, keeping the loop efficient and interpretable.

The main limitations are the heavy repair load in the coding stage, the growth of prompts as skills accumulate, and occlusion issues in the robotic setup. Addressing these challenges will require slimmer prompts, stronger validation, and more robust sensing. Overall, the results show that SPCA provides a practical balance between flexibility and reliability, offering a feasible path for building agents that link high-level reasoning with executable skills.