PaperlayerView exact revision on arXiv

Source-linked AI summary

Coding Agents for Generalized Task and Motion Planning Problems

Matteo Merler, Bowen Li, Josh Roy, Yichao Liang, Qianwei Wang, Yixuan Huang, Tom Silver

arXiv:2609.30233v1cs.ROcs.AI

TL;DR

Task and motion planning remains difficult because discrete choices interact with geometric, kinematic, and dynamic constraints, while generalized methods require TAMP-specific engineering. This paper studies coding agents that use task descriptions and simulator interaction to synthesize programs, then freezes those programs for evaluation on unseen instances. The agents outperform hand-engineered planners and existing LLM-based synthesis methods in the reported benchmarks, though the study does not establish performance under perception uncertainty.

  • Problem

    TAMP combines long horizons and sparse rewards with tightly coupled discrete decisions and geometric, kinematic, and dynamic constraints, while generalized methods require substantial TAMP-specific engineering.

    Source: §I · p. 1

  • Method

    Coding agents use task descriptions and simulator access within a fixed synthesis budget to develop programs, which are frozen and evaluated on unseen instances.

    Source: §I · pp. 1–2, C. Synthesis and Evaluation · p. 2

  • Results

    All three agent configurations outperform planners on the 16 environments with a planner (Claude Code 82% success, Astra 95%, Sol 56%, versus planner 47%) and beat one-shot generation and LLMGenPlan in mean success across 28 environments.

    Source: §I · p. 2

  • Takeaways & Limitations

    The authors conclude that coding agents are a strong baseline for generalized TAMP, with interaction logs showing targeted probing and strategies that exploit regularities across instances.

    Source: §I · p. 2

    The setup assumes fully observed, object-centric states and simulator access during synthesis, so it does not establish performance under perception uncertainty.

    Source: §VI · p. 8

Abstract

from arXiv · show

Task and motion planning (TAMP) problems remain difficult even with full observability and object-centric states because discrete decisions are tightly coupled to geometric, kinematic, and dynamic constraints. Generalized TAMP addresses this difficulty by exploiting regularities across problem instances to reduce planning effort on new instances. However, existing methods require substantial TAMP-specific engineering. We investigate whether coding agents can automate this process by synthesizing programs that generalize across instances. Given a task description and simulator access, each agent chooses how to interact with the environment while developing a program within a fixed synthesis budget. The program is then frozen and evaluated on unseen instances. We evaluate Claude Code (Opus 5) and Codex (GPT-5.6 Sol and GPT-6 Astra) on 28 simulated environments from KinDER and PDDLStream, with object counts beyond those evaluated in the original benchmark. Across all program synthesis methods, we evaluate 980 generated programs on 100 held-out instances each, 98,000 evaluation episodes in total. Overall, we find that coding agents are surprisingly effective at generalized TAMP: all three agent configurations outperform hand-engineered planners, one-shot generation, and an LLM-based generalized planning baseline in mean success (56% to 95% versus 47% for the planners, on the 16 environments where a planner is available). As object counts grow, the agents' programs maintain higher success than the planner, using an order of magnitude less computation per instance on average. Logs show agents using interaction to calibrate physical models, test edge cases, and refine strategies. We release all code, including the full prompts given to the agents. These findings suggest that coding agents are a strong baseline for generalized TAMP.

I. INTRODUCTION

The paper asks whether coding agents can discover cross-instance regularities for effective TAMP with less domain-specific engineering, despite tightly coupled constraints and prior LLM weakness on geometry and physical decisions.

I. INTRODUCTION

  • 82% success for Claude Code, 95% for Astra, and 56% for Sol compare with planners’ 47% on the 16 environments with a planner; agents also maintain higher success as object counts grow.Figure 1 compares success and computation time as object counts grow; the agents also outperform one-shot generation and LLMGenPlan in mean success across all 28 environments.Source: Figure 1 · p. 1, §I · p. 2
  • The study evaluates coding agents across 28 environments using a fixed synthesis budget, with each synthesized program tested on 100 held-out instances.The study reports 98,000 evaluation episodes in total; agents receive task descriptions and simulator access, and the program is frozen before evaluation.Source: §I · pp. 1–2
  • Interaction logs show agents probing to infer dynamics and exploiting cross-instance regularities, including unexpected non-prehensile maneuvers and uses of environment layout.The authors note that these strategies had not appeared in prior work on the benchmarks, to their knowledge.Source: §I · p. 2
  • Some dynamic three-dimensional environments remain largely unsolved in the main setting, particularly tasks requiring sweeping or pouring many small objects.Source: §I · p. 2

II. PROBLEM SETTING

The paper models tasks as finite-horizon, goal-directed MDPs in which instances vary while the state and action spaces, transition model, and reward function remain shared.

A. MDPs and Simulator Access

  • An MDP here comprises state and action spaces, a transition model, sparse goal-achievement rewards, an initial-state distribution, and a horizon.States map each typed object to real-valued features such as pose, geometry, joint configurations, and velocity.Source: A. MDPs and Simulator Access · p. 2
  • Instances vary in object count, configuration, and geometry, while the state and action spaces, transition model, and reward function are shared.An object-retrieval task, for example, can vary in the number and placement of obstacles around the target.Source: A. MDPs and Simulator Access · p. 2
  • Simulator access lets a method sample initial states through reset and execute actions through step, receiving the next state, reward, and termination signal.Source: A. MDPs and Simulator Access · p. 2

B. TAMP Environments

The setting isolates physical reasoning in simplified, fully observed TAMP environments and evaluates synthesized programs on hidden instances after synthesis ends.

B. TAMP Environments

  • TAMP remains challenging because discrete choices are coupled to continuous geometric, kinematic, and dynamic constraints, while horizons are long and rewards sparse.Feasible actions may occupy small regions of the action space, and collision constraints grow with object count.Source: B. TAMP Environments · p. 2

C. Synthesis and Evaluation

  • During synthesis, a method uses the task description and simulator access within a fixed budget to produce a program that maps interaction history to actions.Source: C. Synthesis and Evaluation · p. 2
  • At evaluation, the program is frozen and tested on initial states intentionally hidden during learning, with no synthesis method or LLM available.Source: C. Synthesis and Evaluation · p. 2
  • Success rate measures goal achievement within the horizon and wall-clock limit; computation time measures planning and action decisions per instance.The computation-time measure excludes synthesis and time spent advancing the evaluation environment.Source: C. Synthesis and Evaluation · p. 2
  • Figure 2 presents unexpected successful strategies as left-to-right execution rows, with annotations describing behaviors from both the main and + source settings.Source: Figure 2 · p. 3

III. GENERALIZED TAMP WITH CODING AGENTS

The agents receive a constrained programming environment and simulator access, then choose their own tests and program structure; a separate setting adds environment source code.

A. Coding Agents

  • The main setting uses off-the-shelf Claude Code and Codex agents in a sandbox, with only Python, NumPy, and SciPy and no hand-written TAMP predicates, operators, samplers, or skills.The task description specifies the task, observation and action spaces, goal, variable object counts, and evaluation time.Source: A. Coding Agents · pp. 3–4
  • Simulator access lets agents write and run custom tests, inspect states, and revise their programs through a client while the simulator implementation remains inaccessible.Source: A. Coding Agents · p. 4
  • In the + source setting, agents can inspect environment code and import helpers; source access also permits arbitrary state setting and direct simulator manipulation during synthesis.This setting is a reference for performance with complete environment knowledge.Source: A. Coding Agents · p. 4
  • Agents implement policies as reset and get_action methods, but may choose any abstraction or strategy; repository commits record program revisions for later replay.Source: A. Coding Agents · p. 4

B. Baselines

The study compares AgenticGenPlan with hand-engineered TAMP planners and a non-agentic LLM generalized-planning baseline. The baselines differ in their planning resources and ability to interact during synthesis.

B. Baselines

  • The TAMP planners combine symbolic search with continuous-constraint sampling and compute a new plan for each evaluation instance.They use benchmark-provided predicates, operators, samplers, and motion-planning skills; planners are available for 16 of 28 environments.Source: B. Baselines · p. 4
  • LLMGenPlan receives environment source code and the same synthesis budget as the coding agents, but cannot use tools or access the filesystem.A fixed pipeline returns predefined feedback such as exceptions, invalid actions, or unsolved instances.Source: B. Baselines · p. 4
  • The one-shot baseline uses LLMGenPlan’s first generated program, without any refinement loop.LLMGenPlan itself cannot choose what to run or write custom tests.Source: B. Baselines · p. 4

IV. EXPERIMENTS

The experiments assess whether coding agents can synthesize generalized TAMP programs, what strategies they discover, and how agentic synthesis affects performance and efficiency. The benchmark spans multiple task families, with a fixed synthesis and evaluation protocol.

IV. EXPERIMENTS

  • The experiments ask whether agents can write generalized TAMP programs, what strategies they discover, and how agentic interaction, program efficiency, and source-code access affect outcomes.These are framed as five questions about efficacy and efficiency.Source: §IV · p. 4

A. Environment Setup

  • The benchmark includes 25 KinDER environments across four kinematic and dynamic task families, plus the Packing, Blocked, and Rovers PDDLStream domains.Nineteen KinDER environments have object-count variants, including counts beyond those in the original benchmark.Source: A. Environment Setup · p. 4
  • Each method runs five times per environment; coding-agent and LLMGenPlan synthesis runs receive a $20 model-usage budget and programs are tested on 100 instances per environment.Evaluation seeds are randomly generated and verified unused during synthesis; each instance has a 60-second timeout.Source: A. Environment Setup · p. 4

B. Results and Analysis

Across the benchmark, Astra has the strongest reported success across task families, while agent performance varies by environment and strategy. Results also show how interaction, source access, and program design relate to success and computation time.

Results across environments

  • Astra averages 99% success on Kinematic2D, 97% on Dynamic2D, 93% on Kinematic3D, 65% on harder Dynamic3D, and nearly 100% on PDDLStream; Opus averages 96%, 92%, 90%, 45%, and 78%, respectively.Source: B. Results and Analysis · pp. 4–5

Comparing agents and planners

  • Astra exceeds the planner in 15 of 16 planner-covered environments, compared with 12 for Opus and 9 for Sol.In Blocked, Sol reaches 75% success versus 38% for Opus and 74% for the planner.Source: B. Results and Analysis · pp. 5–6

Interaction and strategy refinement

  • Agents use custom tests and interaction to find edge cases, calibrate models, and refine control strategies.In Shelf, calibration reduces cube-position RMSE from 38.9 to 1.8 mm on calibration observations; in BalanceBeam, moving placement targets nearer the beam center raises one Sol run’s success from 6% to 64%.Source: B. Results and Analysis · pp. 5–6, Figure 3 · p. 6

Comparing agents

  • Astra has higher mean success than Opus in 20 of 28 environments, though the best Opus program matches or exceeds Astra in 11 of those.Astra solves every SweepIntoDrawer instance by picking up cubes, while no Opus program succeeds there; in Kinematic3D Packing, Astra programs search positions and rotations and solve all instances, unlike the best Opus program.Source: B. Results and Analysis · p. 6

Refining manipulation strategies

  • In one Sol Blocked run, adding a spare-block fallback raises success from 15% to 56%, and later commits reach 83%.The final programs solve all 80 instances with an alternative block but only three of the 20 without one; Astra combines nearby-block attempts with a distant-block fallback and solves all 100 instances.Source: B. Results and Analysis · p. 6, Figure 4 · p. 7

Program computation efficiency

  • On 14 planner-covered environments with multiple object counts, Opus and Astra programs take 2.1 s and 0.5 s per instance on average, versus 29 s for planners.Across 15 environments with at least one perfect run for each method, mean policy-computation time per action is 11.7 ms for Opus and 1.3 ms for Astra; source access raises Astra’s average to 50.4 ms.Source: B. Results and Analysis · p. 7, Table III · p. 7

Environment source code access

  • Providing environment source code raises mean success from 74% to 84% for Opus and from 86% to 95% for Astra.LLMGenPlan also receives source code but reaches 28%; source access lets programs read goals and reuse implementations such as inverse kinematics and collision checks.Source: B. Results and Analysis · p. 7

A. Generalized Planning and Learning for TAMP

TAMP combines discrete planning with continuous feasibility constraints, while generalized planning seeks solutions reusable across related instances. Prior work learns reusable components; this section asks whether general-purpose coding agents can exploit such regularities without fixed TAMP abstractions.

A. Generalized Planning and Learning for TAMP

  • TAMP couples symbolic planning decisions to procedures that sample and check continuous quantities.PDDLStream provides an interface between symbolic planning and those procedures.Source: A. Generalized Planning and Learning… · p. 7
  • Generalized planning seeks solutions that apply across related problem instances.For TAMP, prior work has pursued reusable samplers, feasibility predictors, search heuristics, and state and action abstractions.Source: A. Generalized Planning and Learning… · pp. 7–8
  • The section asks whether general-purpose coding agents can exploit cross-instance regularities without being confined to specific TAMP abstractions.A recent survey of generalized TAMP is cited as.Source: A. Generalized Planning and Learning… · p. 8

B. Foundation Models for Task and Motion Planning

Foundation-model work has used LLMs to guide TAMP planners and synthesize their components, while agentic systems generate reusable robotic policies. This paper's related work distinguishes its open-ended solutions and TAMP-focused evaluation from those precedents.

B. Foundation Models for Task and Motion Planning

  • LLMs have guided TAMP planning and generated components such as constraint programs, trajectory-optimization programs, and vision-language constraints.Examples include Text2Motion, LLM3, PRoC3S, MOPS, and OWL-TAMP.Source: B. Foundation Models for Task and… · p. 8
  • Unlike systems that commit to particular TAMP abstractions, this work leaves generated solutions free to use search, optimization, sampling, or task-specific procedures.The objective is to solve as many problem instances as possible efficiently.Source: B. Foundation Models for Task and… · p. 8

C. Agentic Synthesis of Robotic Programs

  • Code-based robot policies and reusable programs have used execution feedback, with Code-as-Policies, GenCHiP, InstructFlow, and Silver et al. as precedents.The cited work highlights the role of action interfaces and feedback in code-based policies.Source: C. Agentic Synthesis of Robotic Programs · p. 8
  • Prior agentic systems synthesize reusable robotic policies, but their benchmarks focus on general manipulation rather than TAMP's physical reasoning challenges.Examples include RHO [31], ASPIRE [32], and MEMENTO [33], evaluated on benchmarks such as Robosuite [34] and LIBERO.Source: C. Agentic Synthesis of Robotic Programs · p. 8

D. Systematic Evaluation of Embodied Agents

The evaluation is framed against prior LLM use in PDDLStream and systematic embodied-agent studies. The discussion concludes that coding agents outperform planner and LLM-synthesis baselines on the reported benchmarks, while noting assumptions that limit the scope of the evidence.

D. Systematic Evaluation of Embodied Agents

  • The closest evaluation precedent uses LLMs within PDDLStream to replace planning or continuous sampling, whereas this work freezes simulator-developed programs for LLM-free testing on unseen instances.The prior study compares those configurations with engineered planners [19].Source: D. Systematic Evaluation of Embodied… · p. 8
  • The evaluation builds on KinDER's procedurally generated environments and baseline implementations, alongside studies of coding agents and iterative manipulation.Related work includes CaP-X [36] and Tsui et al. [37].Source: D. Systematic Evaluation of Embodied… · p. 8

VI. DISCUSSION

  • The discussion concludes that coding agents outperform hand-engineered planners and existing LLM-based synthesis methods on the paper's benchmarks.It presents coding agents as a strong baseline for future TAMP research.Source: §VI · p. 8
  • The study assumes fully observed, object-centric states and simulator access during synthesis, so it does not establish performance under perception uncertainty.Benchmark-code exposure during model training cannot be excluded because the training data are undisclosed.Source: §VI · p. 8
Loading 2609.30233v1…