Off-the-shelf coding agents, given only a task description and simulator access, synthesize frozen Python programs that solve Task and Motion Planning (TAMP) problems by probing the environment, calibrating physics models, and writing generalized policies. The best agent averages 95% success versus 47% for hand-engineered planners on shared environments.
Suppose you have a robot arm that needs to pack objects, sweep debris, or retrieve a blocked item. The classical approach, Task and Motion Planning (TAMP), works but requires a specialist to hand-write symbolic predicates, operators, samplers, and motion skills for every new environment. That engineering cost is why generalized TAMP research spends its time learning reusable pieces (samplers, feasibility predictors, heuristics) that transfer across problem instances.
The baseline the paper picks a fight with is exactly this hand-engineered stack: TAMP planners like PDDLStream that combine symbolic search with samplers for continuous constraints. Prior LLM work has struggled here: when you ask an LLM to make the geometric decisions inside a TAMP system directly, it does poorly even with geometry in the prompt. So the open question is whether a modern coding agent, which can write and run code rather than just answer, can produce a program that generalizes across instances without any of that scaffolding.
The recipe is deliberately minimal. Each environment ships with a task description and a simulator that exposes reset and step. The agent runs inside a sandboxed Docker container with Python, NumPy, and SciPy. No network, no environment source code (in the main setting), no hand-designed TAMP predicates or skills. It has a fixed budget ($20 of model usage) and can do whatever it wants inside that budget: write scratch scripts, call reset with many seeds to hunt for edge cases, render states as images, fit models to observations, revise its program, commit to git between tests.
When the budget runs out, the agent hands back one Python class with reset and get_action methods. That program is frozen. At evaluation time no LLM is in the loop at all: the program alone is run on 100 held-out instances per environment. This is the important design choice. Anything the agent learned about the environment (geometry, dynamics, which objects matter) has to be baked into the code it emits.
The control flow the agent effectively follows looks like this:
# Inside the sandbox, with $20 of model budget
env = SimulatorClient() # reset, step, render only
program = initial_guess(task_description)
while budget_remaining():
seeds = pick_interesting_seeds(env) # e.g. wall-adjacent cases
results = run(program, env, seeds)
if failing(results):
observations = probe(env) # e.g. move arm, fit kinematics
program = revise(program, observations, results)
git_commit(program)
return freeze(program) # no LLM at test time
The agents evaluated are Claude Code running Opus 5 and Codex agent harness running two OpenAI models the paper labels GPT-5.6 Sol and GPT-6 Astra. A + source variant additionally lets the agent read the environment’s source code and reuse helpers like inverse kinematics solvers.
The headline is that all three agent configurations beat the hand-engineered planner on the 16 environments where a planner exists. On those environments, Claude Code with Opus averages 82%, Codex with Sol averages 56%, and Codex with Astra averages 95%, against the planner’s 47%. The agents also beat two weaker LLM baselines: one-shot generation and LLMGenPlan (a non-agentic LLM synthesis method that gets the same $20 budget and even the source code, but can only receive predefined feedback and can’t run its own code). LLMGenPlan reaches only 28%, which the authors read as evidence that the agentic part (running code, testing, revising) is doing real work beyond just having a capable LLM.
A few specifics worth knowing:
•
Scaling with object count. As instances get more objects, the planner slows down and solves fewer of them. The agents’ frozen programs keep higher success at roughly an order of magnitude less compute per instance (agent programs take ~0.5–2.1 s per instance versus ~29 s for planners on 14 shared environments).
•
Programs are cheap at test time. On environments where they hit 100% success, Astra programs run at 1.3 ms per action, Opus programs at 11.7 ms. Giving the agent source code makes the resulting programs slower, because they start calling into the simulator’s own planners at decision time instead of distilling logic into self-contained code.
•
Qualitative behaviors. The logs show agents doing things a static LLM call can’t. In one Shelf environment, Opus builds a kinematic model of the Kinova Gen3 robot arm from its own prior knowledge, uses a grasped cube as a position marker, moves the arm around, and fits six offset parameters, dropping predicted-vs-observed cube position error from 38.9 mm to 1.8 mm. It then uses that fitted model for inverse kinematics. Other agents write custom edge-case generators (repeatedly resetting to find wall-adjacent obstacles) or discover non-prehensile strategies like using the gripper to sweep cubes one by one when the actual sweeper tool is awkward. The authors flag this last category as their strongest evidence against pure memorization, since some of these strategies don’t appear in any published solution.
•
Where it still fails. Dynamic 3D environments involving pouring or sweeping many small objects remain largely unsolved in the main setting. Adding source code closes some but not all of these gaps.
One caution: the biggest reported win (95% vs 47%) is on the subset of 16 environments where a planner exists. Across all 28 environments, Astra averages higher still (~99% on Kinematic2D, 65% on the hardest Dynamic3D), but there’s no planner comparison on the other 12.
•
If you’re building a TAMP-adjacent system, this is a strong argument to try a coding agent as your first baseline before investing in a hand-engineered planning stack. The setup is small: a simulator with reset and step, a task description, a sandbox. The payoff is a frozen program you can ship without an LLM in the loop at inference time, which matters for latency and cost.
•
The frozen-program design is transferable. Even outside robotics, the pattern of “let an agent probe an environment during a synthesis budget, then extract a deterministic program to run in production” is worth stealing anywhere you’d otherwise call an LLM per decision. The paper shows the extracted programs run in milliseconds.
•
Source access is a real lever, but not a substitute for interaction. LLMGenPlan gets the source and still only reaches 28%; Opus + source reaches 84%. If you already have simulator source code, expose it, but don’t skip the agentic loop.
•
Worth testing before committing: whether the same approach holds when states aren’t fully observed and object-centric (the paper assumes both), and whether a smaller model with a longer synthesis budget can substitute for a frontier model. Neither is answered here.
•
Setting is idealized. Fully observed, object-centric states with simulator access. No perception, no partial observability, no real-robot transfer demonstrated. “Solves TAMP” here means solves the simulated benchmark version of TAMP.
•
Training-data contamination can’t be ruled out. The benchmarks (KinDER benchmark and PDDLStream domains) have public code, and the model providers don’t disclose training sets. The authors argue the observed probing behavior and novel strategies are evidence against pure recall, but this is an argument, not a proof.
•
The 95% vs 47% comparison is on a subset. Only 16 of 28 environments have a planner baseline available. On the remaining 12, you’re comparing agents to each other and to LLMGenPlan, not to a hand-engineered TAMP system.
•
Synthesis is not free. $20 per environment per run in model spend, times five runs. Cheap relative to a robotics PhD’s time, expensive relative to running the frozen program.
•
Some categories remain unsolved in the main setting, particularly dynamic 3D tasks needing sweeping or pouring many small objects. Source access helps but doesn’t close every gap.