Papers
Topics
Authors
Recent
Search
2000 character limit reached

Embodied Turing Machines: Stateful Code for Robot Recursive Self-Improvement

Published 8 Oct 2026 in cs.RO and cs.CV | (2610.12369v1)

Abstract: Most robot policies keep a model in the control loop: a VLA maps observations to actions, and an Agent Harness, such as Agent-as-Policy or Harness VLA queries a VLM for decision making at run time. We propose a different view: the embodied world is an Embodied Turing Machine, whose tape is the robot and environment state and rules are the policy. If this state can be represented accurately, the decision making can be written entirely in code. We therefore propose Code-Only-as-Policy (COAP): code measures and tracks the robot, environment, and task state from camera images and proprioception, and makes every decision from it. The same code applies across episodes, and different tasks share one library without a VLM or VLA in the loop. Compared with VLAs and Agent Harnesses, we analyze three advantages of COAP: (i) Explicit State: the state can be stored in code; (ii) Execution: code makes decision making controllable, recovers from failures flexibly, and runs fast and cheaply online; (iii) Extensibility: new tasks reuse, inherit, or extend the shared library, so capabilities can accumulate over tasks. These advantages make COAP a suitable medium for recursive self-improvement (RSI): coding agents develop the library in a closed loop, and each change is explicit and controllable. On RoboDojo's 42 bimanual tasks, the resulting library reaches a success rate of 70.24% without a model at test time. The upper bound of COAP lies in how accurately the state is represented for decision making and how robust the code logic is. We thus propose COAP as a new paradigm for embodied tasks; since it applies across episodes, it can also serve as an efficient data engine for VLAs and Agent Harnesses.

Summary

  • The paper introduces Code-Only-as-Policy (COAP), a robot control paradigm that replaces online model inference with fixed, executable code, achieving a 70.24% success rate on complex manipulative tasks.
  • COAP employs explicit state representation and structured recovery processes, leading to superior performance in memory, precision, and general tasks, often exceeding the top best results by 30% points.
  • The paper demonstrates that COAP can reduce marginal development costs through shared libraries and offline code development, although this incurs substantial upfront engineering effort.

Problem formulation and central thesis

“Embodied Turing Machines: Stateful Code for Robot Recursive Self-Improvement” proposes Code-Only-as-Policy (COAP), a robot-control paradigm in which the runtime policy is an executable program rather than a VLA, VLM agent, or model-generated plan. The paper’s formal abstraction treats the robot and its environment as an embodied Turing machine: the robot and environment constitute a dynamically changing state, while source code supplies the transition rules. At runtime, the code reads RGB observations and proprioception, updates an explicit state representation, and emits motion commands. The program is fixed across episodes; only the measured state changes.

This position differs from prior code-based policies in two respects. First, COAP measures the relevant state using programmable perception code rather than receiving state from a simulator oracle or an external learned perception model. Second, the same task program is reused across episodes, while a shared library is reused across tasks. Thus, the paper makes the strong claim that a sufficiently robust task-specific program can eliminate model inference from the online control loop altogether.

Figure 1

Figure 1: COAP differs from online code generation and oracle- or model-state policies by reusing fixed programs across episodes and measuring state in code.

The proposal is motivated by a distinction among three policy classes. VLAs encode perception, state, and action selection implicitly in model parameters. Agent Harnesses expose some planning or memory through prompts and textual state, but retain a VLM or VLA in the control loop. COAP instead makes both state and transition logic inspectable. This distinction is consequential for debugging: failures can, in principle, be traced to a state variable, measurement procedure, or control rule and corrected through a localized code change.

The paper evaluates the paradigm on RoboDojo’s 42 bimanual manipulation tasks, spanning memory, precision, open instruction following, generalization, and long-horizon manipulation. Its principal result is a 70.24% overall success rate without a model at test time, compared with 31.38% for the strongest listed Agent Harness, 29.64% for the strongest World Action Model, and 27.96% for the strongest VLA. These comparisons are reported against the RoboDojo leaderboard rather than against a newly trained common baseline, so the magnitude of the advantage should be interpreted within that evaluation protocol (2610.12369).

COAP architecture and state representation

COAP maintains three major forms of state. Environment state contains object categories, poses, dimensions, spatial relations, confidence, measurement source, and measurement time. Robot state contains joint configurations, end-effector poses, gripper openings, and reachability information. Task state contains stage, object-to-arm assignments, retry counts, subgoal status, and persistent task memory. The paper also organizes these variables into five practical categories: robot, object, environment, relation, and task state.

At each control step, the policy implements a transition of the form xt+1,at=Fθ(xt,ot)x_{t+1},a_t=F_\theta(x_t,o_t), where xtx_t is the explicit state, oto_t is the current observation, and ata_t is a trajectory segment. Proprioceptive state is refreshed directly; environment state is inferred from RGB images; task state is updated by the task program. Occluded objects retain their last measured pose in an episode-level world state, while high-precision operations trigger wrist-camera remeasurement.

The perception stack is deliberately conventional rather than foundation-model-based. It uses NumPy and OpenCV, robot-mesh projection, robot masking, connected-component analysis, table-plane geometry, and template fitting against known object shapes. RGB boundaries are projected into the table plane, candidate object regions are matched against geometric models, and the resulting records supply positions, orientations, sizes, and confidence values. This design supports inspection and modification of the measurement process, but it also makes the approach dependent on known camera calibration, robot geometry, object models, and simulated scene assets.

Figure 2

Figure 2: COAP separates offline code development, shared library reuse, and fixed-program execution without an online agent or VLA.

The paper illustrates the distinction between environmental and task state with a covering-and-uncovering task. The program measures cubes and cups, associates them by spatial order, stores the color beneath each cup, and later retrieves that memory after the cubes have become occluded. The relevant information is therefore not expected to remain visible in recent frames or implicit in a model’s hidden state; it is stored explicitly in program variables.

This explicit representation directly explains the strong performance on memory and precision tasks. COAP reaches 89.9% on Memory and 75.1% on Precision, versus 50.3% and 33.5% for the strongest corresponding alternatives in the reported comparison. The implication is not merely that explicit memory helps: it suggests that persistent symbolic state and metric geometric state are particularly advantageous when the correct next action depends on information that is no longer visible or requires accurate spatial measurement.

Shared libraries and code-level extensibility

COAP uses a layered library whose dependencies run from task programs through object-family abstractions, manipulation primitives, perception, and motion planning. Task programs specify ordering, task-specific conditions, and special cases. Lower-level modules implement grasping, picking, carrying, placing, pushing, pouring, inverse kinematics, collision checking, remeasurement, verification, and recovery.

The central engineering principle is abstraction by manipulation method rather than by individual object. For example, top, side, handle, rim, edge, and cloth-pinching grasps are reusable across object categories. A new task can therefore compose existing functions, inherit an existing task and override one decision, or introduce a default-off parameter into a shared function. Default-off extensions preserve the behavior of callers that do not activate them, providing a practical compatibility mechanism.

Figure 3

Figure 3: COAP’s layered library separates task-specific decisions from reusable object, manipulation, perception, and motion code.

The reported reuse is substantial: 83% of the code executed by a new task comes from the shared library. Four tasks developed from scratch reached an average validation success of 47% within 15 hours, without new demonstrations or policy training. The task-specific timelines show first successful programs between approximately four and six hours for several tasks, although some tasks remained weak or unsuccessful. These results support the claim that library reuse can reduce marginal development cost, but they do not establish that code development is universally faster than model adaptation: the relevant baseline curves for VLA and Agent Harness development are explicitly described as schematic.

The paper also evaluates regression control. Tasks whose code was not changed retained 78.4% success before library evolution and 79.9% afterward, with no statistically significant task-level change under the reported test. The authors therefore argue that default-off parameters, inheritance, and isolated task additions permit cumulative improvement without catastrophic interference. This is a meaningful contrast with continual VLA fine-tuning, but the compatibility guarantee is conditional on the implementation discipline and test fixtures used. It protects tested execution paths, not arbitrary unseen states.

Figure 4

Figure 4: New tasks predominantly execute shared library code and can be added without data collection or model retraining.

Execution control, recovery, and computational cost

COAP’s execution strategy is based on explicit checks, state updates, and structured recovery. Manipulation primitives return evidence about their outcome, such as whether an object was grasped, held during lifting, placed, or verified at the target. When a step fails, the program can remeasure the scene, backtrack to a known task stage, and retry with a different grasp or motion strategy.

Among episodes in which something went wrong, the program noticed and reported the problem in 76% and attempted a new method in 34%. The paper reports that 12% of all such episodes were reattempted successfully, while 42% were detected and terminated with an explanation. These results show that explicit recovery is operationally useful, but they also expose a limitation: detection does not imply successful recovery, and a substantial fraction of failures remained unreported or unrepaired.

Figure 5

Figure 5: Explicit checkpoints and backtracking limit failure propagation, while fixed code substantially reduces online computation.

The online computational profile is one of COAP’s clearest advantages. A control call has a median latency of 0.3 ms on a CPU, with a median of 352 decisions per episode. Perception and planning account for most of the decision time, while many intermediate calls simply advance an already planned action segment. The reported episode compute is 0.8–2.4% of that estimated for a VLA and less than 0.1% of that estimated for an Agent Harness.

These comparisons require qualification. The VLA and Agent Harness costs are estimates derived from reported model sizes and assumed inference schedules, rather than direct measurements under a common hardware configuration. Nevertheless, the architectural distinction is robust: COAP moves model computation offline into code development, whereas VLA and Agent Harness methods pay inference costs during every episode.

The paper frames recursive self-improvement as an iterative software-engineering process. A coding agent observes failed development episodes, identifies a faulty state variable or transition rule, proposes a code diff, executes the resulting program, and merges the change only if it improves validation performance by a prescribed margin. Each candidate is a complete runnable branch, allowing multiple alternatives to be evaluated concurrently.

This process resembles a constrained search over program variants. CPU-level checks reject branches with invalid task transitions, infeasible inverse-kinematics solutions, or collisions. Simulation evaluation then applies a non-regression-oriented acceptance rule. The current implementation uses Claude Opus 5.5 coding agents without human intervention in the development loop, although the task definition, evaluation protocol, safety constraints, and acceptance thresholds are externally specified.

Figure 6

Figure 6: Parallel branching evaluates multiple alternatives to a decision and selects changes using validation performance.

Parallel branching is important because code changes are cheap to instantiate relative to retraining a VLA. The paper reports that decisions with two or more variants produced an accepted change in four of five cases. In the busiest development interval, 12 task evaluations ran concurrently and completed in 17% of the serial execution time. These measurements support the narrower claim that code provides a convenient search medium for offline policy improvement. They do not demonstrate unrestricted self-modification: candidate generation remains dependent on the coding model, and selection is based on finite validation layouts.

The paper identifies six properties that make a medium suitable for this process: diagnosable failures, targeted changes, cross-task reuse, parallel trials, persistence of gains, and cheap improvement rounds. COAP satisfies these properties because state is explicit, modifications are diffs, branches are executable programs, and accepted changes can be integrated into a shared library.

Benchmark results

COAP’s overall success rate is 70.24%, with a benchmark progress score of 75.45. It leads the reported alternatives across all five task dimensions.

RoboDojo dimension COAP success Best listed baseline COAP margin
Memory 89.9% 50.3% +39.6 points
Precision 75.1% 33.5% +41.6 points
Open instruction 64.1% 31.0% +33.1 points
Generalization 65.7% 30.5% +35.2 points
Long horizon 56.4% 43.4% +13.0 points
Overall success 70.24% 31.38% +38.86 points

The largest advantages occur on Memory and Precision, precisely the dimensions most directly aligned with COAP’s explicit state and geometric measurement. The smallest advantage occurs on Long-Horizon tasks, where accumulated contact failures, incomplete recovery logic, and compounding execution errors remain difficult even with explicit state.

Generalization is more mixed than the aggregate score suggests. COAP reaches 77.3% on standard layouts but only 54.1% on randomized layouts containing new object instances, room and table appearances, and distractors. On the 40 tasks with programs, validation and test success are relatively close on standard layouts—76.7% versus 74.9%—but the randomized setting exposes dependence on scene structure and perception assumptions. Thus, the result supports task-level program reuse within a structured environment more strongly than broad open-world generalization.

Failure modes and empirical boundary

The paper divides failures into perception error, contact error, incomplete logic, and poor code design. Perception and contact errors account for 62% of failures, while incomplete logic and poor code design account for 37%. This decomposition leads to the paper’s central boundary condition: COAP’s upper bound is determined by the fidelity of state representation and the robustness of the transition logic.

Perception failures include object misclassification, incorrect segmentation-like region extraction, and faulty final verification. Contact failures are more fundamental: the current state representation does not fully capture grasp contact, deformable-object configuration, or the mechanical conditions governing slip. Code failures include missing retries, insufficiently general conditions, and hard-coded thresholds that fail on new object sizes.

Figure 7

Figure 7: COAP failures arise from both imperfect state measurement and incomplete or poorly generalized code logic.

This analysis qualifies the paper’s strongest conceptual claim. Code is inspectable, but inspectability does not guarantee correct state estimation. A white-box controller can make systematic errors when its state variables omit relevant physical information. The reported oracle-state comparison makes this explicit: the same program succeeds in 83% of episodes with oracle state but only 63% with measured state. The 20-point gap is evidence that perception and state abstraction, rather than high-level task logic alone, are a major performance bottleneck.

Limitations and open questions

The evaluation is entirely in simulation, and the perception system uses public benchmark assets, calibrated camera models, robot meshes, object dimensions, and known scene structure. Transfer to physical robots would require recalibration, object and contact-parameter estimation, and retuning of grasp widths, speeds, and tolerances. Consequently, the 70.24% result should not be interpreted as evidence of equivalent real-world performance.

The approach also incurs substantial offline development cost. Every new task requires coding-agent iterations, execution, debugging, and validation. Although online execution is inexpensive, this cost is shifted rather than eliminated. The paper does not provide a controlled accounting of total engineering effort against VLA data collection, fine-tuning, or Agent Harness prompt development.

Generalization remains incomplete. Two tasks have no successful program, several task success rates are low, and one task reaches only 0.7%. Randomized-layout performance is substantially below standard-layout performance. Moreover, the acceptance rule evaluates finite validation fixtures, and the reported compatibility mechanism protects existing code paths only under the assumptions encoded in tests and default-off interfaces.

Several questions remain open within the paper’s own framework. How should COAP represent deformable-object contact, uncertainty, and unobserved dynamics? Can learned perception modules be integrated without forfeiting state inspectability and controllability? What validation protocol can prevent overfitting when branching over many code variants? And can the proposed library abstraction transfer to real hardware without requiring object- and robot-specific redesign?

Conclusion

The paper presents COAP as a programmatic alternative to model-in-the-loop robot control. Its technical contribution is the integration of explicit state estimation, fixed code policies, shared manipulation libraries, structured recovery, and offline coding-agent improvement. On RoboDojo, this design achieves 70.24% success and substantially exceeds the listed VLA, World Action Model, and Agent Harness baselines, with particularly large gains on memory and precision tasks.

The results support the narrower thesis that explicit, persistent state and executable transition logic are highly effective for structured bimanual manipulation. They also establish the method’s principal constraint: performance depends on whether the code can measure the physically relevant state and encode sufficiently robust recovery logic. The paper’s most consequential open problem is therefore not whether code can replace online model inference in a benchmark, but whether the same state-and-library methodology can retain its advantages under unstructured perception, complex contact, and real-world dynamics.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

1. What is the paper about?

This paper introduces a new way to control robots called Code-Only-as-Policy, or COAP.

Usually, robots use a large artificial intelligence model to decide what to do next. For example, a model might look at a camera image and decide, “Move the left arm toward the blue cup.” COAP uses a different idea: it stores information about the robot and its surroundings in ordinary computer code, then uses written rules to choose every action.

The authors compare this idea to a Turing machine, a simple imaginary computer described by Alan Turing. A Turing machine has:

  • A “tape” that stores information.
  • Rules that read the information and decide what to do next.

In COAP, the robot and its environment act like the tape. The code contains the rules.

2. What questions does the research ask?

The paper mainly asks:

  1. Can a robot work using only code while it is operating? In other words, can the robot complete tasks without asking a large language or vision model for advice at every step?
  2. Is code better at remembering the robot’s situation? For example, can it remember where an object was placed even after the object becomes hidden?
  3. Can code help robots recover from mistakes? If a robot drops something or misses a grasp, can the program notice the problem, go back, and try again?
  4. Can the same code be reused for many different tasks? The authors want one shared “toolbox” of robot skills instead of writing a completely new program every time.
  5. Can coding agents improve the robot’s abilities over time? The researchers study whether an AI that writes and tests code can gradually make the robot better.

3. How did the researchers do it?

The robot’s “memory”

COAP keeps three main kinds of information:

  • Environment state: where objects are, what they look like, and how they are related. For example, it might record that a red block is inside a cup.
  • Robot state: where the robot’s arms, joints, hands, and grippers are.
  • Task state: what stage of the task the robot is completing, how many times it has tried, and important facts it needs to remember.

This information is stored in program variables, much like notes in a computer program.

For example, in a cup-and-block task, the robot might:

  1. Find three blocks and three cups.
  2. Match each cup with a block.
  3. Cover the blocks with the cups.
  4. Remember which color is under each cup.
  5. Uncover the cups in the correct order.

Even if a block is hidden, the robot can use its stored information to remember where it should be.

Seeing the environment

The robot receives:

  • Images from three cameras.
  • Information about the positions of its own joints and hands.
  • A spoken or written task instruction.

The code studies the camera images to estimate where objects are. It uses known information about the objects, such as their shape and size, to match what it sees with possible objects.

A simple analogy is fitting a puzzle piece into a picture. The program tries different positions and rotations until the known 3D shape best matches the shape seen by the camera.

The researchers did not give the robot special hidden information from the simulator during testing. This is important because it makes the experiment more realistic.

Improving the code

The code was improved offline, before the robot performed the final tests. AI coding agents:

  1. Watched failed attempts.
  2. Checked which stored value or rule caused the failure.
  3. Suggested a small code change.
  4. Tested the change.
  5. Kept the change only if it improved performance without damaging other tasks.

This is similar to how a programmer improves a video game: find a bug, change one part of the program, test it, and keep the change only if the game works better.

Testing the method

The researchers tested COAP on RoboDojo, a benchmark containing 42 tasks involving two robot arms. The tasks tested:

  • Memory
  • Precise movements
  • Following open-ended instructions
  • Working in new environments
  • Completing long sequences of actions

They compared COAP with vision-language-action models and other robot systems that use AI models during operation.

4. What did they find?

COAP achieved a high success rate

COAP completed tasks successfully in 70.24% of test episodes.

The best comparison system reported in the paper achieved a success rate of 31.38%. The paper therefore reports that COAP performed much better on this benchmark.

COAP also had the highest score in all five task categories:

Task type COAP success rate
Memory 89.9%
Precision 75.1%
Open instructions 64.1%
Generalization 65.7%
Long-horizon tasks 56.4%

A long-horizon task is a task with many steps, such as picking up several objects, moving them, and arranging them in a particular order.

It was especially good at memory and precision

COAP performed particularly well when the robot needed to:

  • Remember something that was no longer visible.
  • Measure object positions carefully.
  • Move its arms accurately.

This makes sense because the program stores information clearly instead of relying only on recent camera images or hidden information inside a trained model.

It could recover from mistakes

The code could sometimes notice when an action failed. For example, if a grasp did not work, it could:

  1. Check the object’s new position.
  2. Return to an earlier stage.
  3. Try a different grasp angle or method.

The paper reports that the system noticed problems in 76% of episodes where something went wrong. It attempted a different method in 34% of those cases.

It was fast and cheap during operation

The robot did not need to contact a large AI model while completing a task. Instead, it ran ordinary code on a computer.

According to the paper:

  • A control step took about 0.3 milliseconds on a CPU.
  • COAP used much less computing power than the comparison systems.
  • The same program could run across many episodes of the same task.

This could make robot operation less expensive and more predictable.

Much of the code could be reused

The researchers report that about 83% of the code used by a new task came from a shared library.

This library included general skills such as:

  • Grasping objects.
  • Picking objects up.
  • Placing objects down.
  • Moving objects safely.
  • Checking whether an action succeeded.
  • Recovering after failures.

A new task only needed to add the special rules for that task. This is similar to building a new computer game using an existing game engine instead of creating every feature from the beginning.

5. Why is this research important?

The paper suggests that robots may not always need a large AI model making decisions every moment. Carefully written code can offer several benefits:

  • Clearer decisions: Researchers can inspect the code and see why the robot acted in a certain way.
  • Better memory: Important facts can be saved in variables and used later.
  • More control: A programmer can change one rule without retraining an entire model.
  • Better recovery: The robot can return to an earlier step and try another method.
  • Lower cost: Ordinary code is faster and cheaper to run than repeatedly using a large AI model.
  • Reusable skills: Improvements made for one task can help with other tasks.

The method could also help create better training data for other robot systems. For example, COAP might produce successful demonstrations that could later be used to train a vision-language-action model.

However, COAP also has limitations. It needs task-specific programming, so it may not immediately work for completely new situations. Its success depends on two things:

  1. How accurately the code understands the robot and its surroundings.
  2. How reliable the written rules are.

If the cameras measure an object’s position incorrectly, or if the program does not include the right recovery rule, the robot can still fail.

Conclusion

This paper presents COAP as a different approach to robot intelligence. Instead of asking a large AI model what to do at every moment, the robot stores its situation in code and follows clear rules. The researchers report that COAP performed very strongly on 42 robot tasks, especially tasks requiring memory and precision.

The main idea is that robots might become more reliable, understandable, and affordable when their actions are controlled by well-tested programs. Large AI models may still be useful for writing and improving those programs, but the robot itself can operate without needing a model in the loop.

Practical Applications

Immediate Applications

  • Low-latency control for structured robotic workcells — Industrial robotics and manufacturing
    • Deploy COAP-style policies for repeatable manipulation tasks such as pick-and-place, sorting, covering/uncovering objects, part transfer, and bin loading.
    • A shared library can encode reusable primitives such as grasping, lifting, placing, pouring, collision checking, verification, and recovery. Task-specific programs would specify only the sequence and conditions.
    • The reported median control-step time of approximately 0.3 ms and the absence of online VLM/VLA inference could reduce latency, cloud dependence, and per-episode inference cost.
    • Dependencies: Accurate camera calibration, object geometry, robot kinematics, collision models, reliable object detection, and sufficiently constrained workspaces. The reported 70.24% success rate is from RoboDojo simulation and does not by itself establish production-level reliability.
  • Offline-verified robot controllers for safety-critical or auditable workflows — Manufacturing, logistics, and laboratory automation
    • Use explicit state variables, logged transitions, fixed code, and deterministic execution to create controllers that can be inspected, tested, versioned, and audited.
    • A deployment workflow could require every code change to pass unit tests, inverse-kinematics checks, collision checks, regression tests, and validation episodes before release.
    • This is particularly useful where organizations need to explain why a robot acted, reproduce a failure, or certify that an update did not alter unrelated tasks.
    • Dependencies: The state representation must accurately capture safety-relevant conditions. Code transparency does not guarantee safe behavior if perception, calibration, or the physical model is wrong.
  • Robust recovery and fault handling in long-horizon manipulation — Robotics and warehouse automation
    • Implement explicit retry counts, stage tracking, failure detection, re-measurement, alternate grasp strategies, and backtracking to the last verified state.
    • Example workflows include retrying a failed grasp with a different angle, slowing a carry after detecting an unstable object, or re-measuring an object with a wrist camera before final placement.
    • Such mechanisms can reduce the likelihood that one failed primitive terminates an entire manipulation sequence.
    • Dependencies: The robot must be able to identify failure reliably and return to a safe, known configuration. Recovery is unsuitable for unmodeled hazards unless emergency-stop and supervisory safety systems remain independent.
  • On-premises and edge robotics without continuous model-service access — Retail, logistics, agriculture, and remote operations
    • Run task policies locally on a CPU after offline development, avoiding repeated calls to cloud-hosted language or action models.
    • Potential products include an edge controller appliance, a robot-side runtime, or a versioned “robot skills library” that operates during network outages.
    • This could benefit warehouses, farms, field-service robots, and laboratories with limited connectivity or strict data-localization requirements.
    • Dependencies: The environment must be sufficiently structured, and all required perception and control code must run within the available compute and memory budget. Open-ended instructions and novel objects may still require a model-in-the-loop fallback.
  • Reusable robot-skill libraries and rapid task customization — Robotics software engineering
    • Organize robot software into layers for perception, state estimation, motion, manipulation primitives, object-specific behavior, and task logic.
    • New tasks could be created by composing existing functions, inheriting an existing task flow, or adding default-off parameters that preserve behavior for older tasks.
    • A practical tool could resemble a version-controlled robotics SDK with task templates, typed state records, simulation fixtures, compatibility tests, and regression dashboards.
    • Dependencies: Interfaces and state schemas must remain stable. The paper’s reported 83% shared-code proportion may depend on the RoboDojo task family and may not transfer directly to substantially different robots or environments.
  • Automated regression testing for embodied software — Robotics academia and industry
    • Treat robot policies as software artifacts whose diffs can be tested across fixed layouts, randomized scenes, failure cases, and historical tasks.
    • Useful tooling includes branch-based policy evaluation, parallel simulation, no-regression gates, state-diff visualization, and replayable execution traces.
    • This provides a concrete workflow for evaluating whether a new grasp, perception adjustment, or recovery rule improves a target task without degrading previous capabilities.
    • Dependencies: Simulation must model relevant real-world effects; otherwise, acceptance tests may reward simulator-specific behavior. Physical validation remains necessary for deployment.
  • Synthetic trajectory generation for training foundation models — AI research and robotics data engineering
    • Use a stable code-only controller to generate repeatable successful trajectories, state-action logs, failure traces, and recovery examples.
    • These data could be used to train or fine-tune VLAs, Agent Harnesses, inverse-dynamics models, failure detectors, or action-value estimators.
    • COAP can therefore serve as a data engine even when a model-based policy remains the final production controller.
    • Dependencies: Generated trajectories must be diverse enough to prevent overfitting to scripted behavior, and simulation-to-real transfer must be validated. The controller’s errors can also propagate into the training data.
  • Educational platforms for robotics and embodied AI — Academia and education
    • Use COAP as a teaching framework for state estimation, finite-state control, robot kinematics, visual perception, recovery planning, software testing, and recursive improvement.
    • Students could inspect and modify explicit variables such as object pose, task stage, retry count, and grasp confidence instead of treating the policy as an opaque neural network.
    • A practical laboratory workflow would compare code-only, VLA, and model-in-the-loop controllers under identical tasks and failure conditions.
    • Dependencies: Educational deployments require accessible simulators, documented robot APIs, and carefully designed safety constraints.
  • Deterministic automation for repetitive household or personal tasks — Daily life
    • In controlled domestic settings, a robot could use explicit task state for activities such as sorting known objects, transferring items between containers, or following a predefined storage routine.
    • Persistent state could help the robot remember object locations or task order after temporary occlusion.
    • Dependencies: Real homes contain substantial variation, clutter, moving people, reflective surfaces, and unknown objects. The paper does not demonstrate general-purpose household autonomy, so deployment would require conservative environments and human supervision.

Long-Term Applications

  • General-purpose household manipulation — Consumer robotics
    • A mature COAP system could support reusable skills for loading dishwashers, organizing objects, preparing ingredients, folding items, and retrieving objects from clutter.
    • New household tasks could inherit common perception, grasping, navigation, verification, and recovery modules, while task-specific rules encode object relations and ordering constraints.
    • Dependencies: Major research is needed for robust state estimation under occlusion, deformable objects, changing lighting, unknown object geometry, human interaction, navigation, and graceful handling of ambiguous instructions. The current results are limited primarily to benchmarked bimanual manipulation.
  • Collaborative and assistive robots with inspectable behavior — Healthcare, eldercare, and rehabilitation
    • Explicit state and deterministic rules could support robots that prepare therapy equipment, deliver known objects, organize supplies, or assist with repetitive clinical procedures.
    • Logged state transitions could improve incident investigation and allow clinicians or engineers to inspect what the robot believed about the environment.
    • Dependencies: Medical and assistive settings require certified safety, privacy protection, human-override mechanisms, uncertainty quantification, and extensive real-world trials. A code-only policy should not independently make high-consequence clinical decisions.
  • Adaptive manufacturing cells that improve through controlled code evolution — Industrial automation
    • Coding agents could propose targeted changes to perception, grasp selection, motion parameters, and recovery logic; evaluate them in parallel; and merge only changes that improve performance without regressions.
    • This could produce a continuously improving robot software platform where capabilities accumulate across products and workcells.
    • Dependencies: Recursive self-improvement requires strong sandboxing, signed releases, traceable provenance, formal or empirical safety gates, and representative validation data. Improvement on a benchmark or simulator may not predict performance under production variation.
  • Hybrid code-plus-model architectures — Robotics and embodied AI
    • COAP could provide the deterministic execution and state-management layer, while VLAs or VLMs handle tasks that are difficult to encode explicitly, such as open-ended language interpretation, novel object discovery, or proposing new task programs offline.
    • A likely workflow is: model proposes a code change or task decomposition; simulation and regression tests evaluate it; only the approved code runs online.
    • Dependencies: Clear authority boundaries are required so that a generative model cannot bypass safety checks. The perception and uncertainty interfaces between learned components and code must be standardized.
  • Automatic construction of robot foundation-model datasets — AI infrastructure
    • A shared code library could systematically produce trajectories across object layouts, perturbations, failure modes, and recovery strategies, yielding labeled data for state estimation and policy learning.
    • The logged explicit state could provide supervision for object poses, spatial relations, stage transitions, confidence values, and causal failure categories.
    • Dependencies: Dataset diversity, accurate simulation, domain randomization, and real-world calibration are essential. Synthetic data may encode the assumptions of the hand-written controller and fail to cover human environments.
  • Formal verification and certification of embodied policies — Safety engineering and policy
    • Because the policy is executable code with explicit state transitions, future systems could apply static analysis, runtime monitors, reachability analysis, invariant checking, and formal constraints to selected robot behaviors.
    • Regulators or industrial auditors could require evidence that forbidden actions, unsafe speeds, collision states, or unverified object transfers are unreachable under defined assumptions.
    • Dependencies: Full verification is difficult for image-based perception and continuous physical dynamics. Practical certification would likely cover restricted modules and operating envelopes rather than the complete robot-environment system.
  • Standardized benchmarks and APIs for persistent embodied state — Academia and policy
    • The paper’s state schema suggests benchmarks that evaluate not only task success but also state accuracy, persistence through occlusion, recovery quality, regression behavior, compute cost, and interpretability.
    • An ecosystem could emerge around standard interfaces for robot state, world state, task state, measurement confidence, action outcomes, and replayable traces.
    • Dependencies: Community agreement is needed on schemas, measurement protocols, real-world test suites, and reporting standards. Benchmark-specific state assumptions should not be mistaken for universal robot representations.
  • Distributed fleets with shared, cumulative capabilities — Logistics, agriculture, and service robotics
    • Robots operating across sites could share a versioned library of perception and manipulation improvements, while retaining site-specific task modules and calibration parameters.
    • Fleet operators could test a proposed change in simulation or on a small pilot group before controlled rollout to the full fleet.
    • Dependencies: Hardware heterogeneity, local environment differences, cybersecurity, rollback mechanisms, and fleet-level monitoring are substantial challenges. A change safe for one robot model may be unsafe for another.
  • Everyday personal automation based on explicit memory — Consumer software and assistive technology
    • A future system could maintain persistent, inspectable records such as where an item was placed, which steps of a routine were completed, and which actions failed.
    • This could support home assistants, accessibility tools, and personal robots that need reliable long-horizon memory rather than merely short-context visual recognition.
    • Dependencies: Users must be able to inspect, correct, delete, and control stored state. Privacy, consent, handling of multiple users, and robustness to changing environments remain unresolved.

Glossary

  • Affordance: An action possibility that an object or environment offers to an agent or robot. “SayCan grounds language-model plans in learned affordances”
  • Backtracking: Returning to an earlier computational or task state to recover from failure. “the code gives fine-grained control over the state and actions, recovers from failures flexibly by backtracking and re-attempting”
  • Bimanual: Involving coordinated use of two robotic arms or hands. “RoboDojo's 42 bimanual tasks”
  • Black box: A system whose internal representations or decision processes cannot be directly inspected. “the VLM and VLA remain black boxes”
  • Code-Only-as-Policy (COAP): A robotic-control approach in which explicit code, rather than a model at runtime, represents state and determines actions. “We therefore propose Code-Only-as-Policy (COAP)”
  • Collision filtering: The process of rejecting motion or grasp candidates that would cause geometric collisions. “inverse-kinematics and collision filtering”
  • Connected region: A contiguous set of image pixels identified as belonging to the same visual component. “each connected region whose lower edge rests on the table becomes an object candidate”
  • Control loop: The repeated process by which a system observes its environment, selects an action, and executes it. “no agent is needed in the control loop”
  • Domain randomization: Varying environmental or object properties during evaluation or training to test generalization. “RoboTwin~2.0 generates domain-randomized bimanual tasks”
  • Embodied Turing Machine: The paper’s abstraction of a robot and environment as a Turing machine whose tape is physical state and whose rules are executable policy code. “We therefore model a robot and its environment as an \textbf{Embodied Turing Machine}”
  • End-effector pose: The position and orientation of a robot’s tool or hand. “joint angles, end-effector poses, and the gripper command echo”
  • Execution trace: A record of the sequence of states, actions, and events produced during program execution. “Let Bi(θ,o)B_i(\theta,o) be the execution trace of task ii under code θ\theta and observations oo”
  • Foundation model: A large pretrained model intended to support many downstream tasks. “recent foundation models scale data and training further”
  • Generalization: The ability of a policy to perform successfully on previously unseen conditions, layouts, or objects. “COAP reaches 65.7\% on Generalization”
  • Grasp-candidate generation: The process of proposing possible robot grasps for an object before selecting one. “a single transfer call expands into grasp-candidate generation”
  • Harness VLA: A system in which a language-model-based agent coordinates or directs a vision-language-action model. “The vision-LLM (VLM) either controls the robot directly, as in Agent-as-Policy, or directs a VLA, as in Harness VLA”
  • Inverse kinematics: Computing robot-joint configurations that place the end effector at a desired position and orientation. “inverse-kinematics solutions and collisions at every waypoint”
  • Long-horizon manipulation: Robotic tasks requiring many sequential actions while maintaining progress and state over an extended execution. “Long-Horizon manipulation in one protocol”
  • Model-free: Operating without using a learned model during the relevant execution phase. “Online execution is efficient and cheap since it is model-free.”
  • Oracle state: Ground-truth state supplied by a simulator or privileged information source rather than measured by the deployed system. “no oracle state at test time”
  • Perception layer: Software that extracts structured environmental information from sensor data. “The environment state is measured by perception layer library.”
  • Proprioception: Sensing a robot’s own configuration and motion, such as joint angles and limb poses. “The robot state is available directly through proprioception”
  • Recursive self-improvement (RSI): An iterative process in which a system modifies and evaluates its own implementation to improve performance. “These advantages make COAP a suitable medium for recursive self-improvement (RSI)”
  • Reproducible: Producing the same behavior reliably under the same inputs and conditions. “the robot's behaviour is reproducible”
  • Rollout: An executed trajectory or simulation of a policy over a sequence of states and actions. “coding agents can improve the code offline from these records”
  • Segmentation: Dividing an image into regions corresponding to objects or meaningful structures. “COAP uses no depth, no segmentation, and no model service at test time”
  • Simulator oracle: Privileged ground-truth information generated directly by a simulation environment. “its state still comes from outside the code: RHO likewise obtains it from SAM and Molmo”
  • Spatial relation: A geometric relationship between entities, such as containment, alignment, or relative position. “the spatial relations between objects, such as one object resting on another”
  • State representation: The structured encoding of the robot, environment, and task information used for decision-making. “The upper bound of COAP lies in how accurately the state is represented for decision making”
  • State-of-the-art: The best performance currently reported for a task or benchmark. “38.9\% above the state-of-the-art method”
  • Turing machine: An abstract computational model consisting of a tape and rules that read, write, and manipulate symbols. “A Turing machine comprises a tape that stores symbols and a set of fixed rules that read from and write to the tape”
  • Vision-language-action model (VLA): A model that maps visual observations and language instructions to robot actions. “A VLA takes observations, such as camera images, as input and learns the mapping to action”
  • Vision-LLM (VLM): A model that jointly processes visual and linguistic information, often for reasoning or instruction following. “The vision-LLM (VLM) either controls the robot directly”
  • Visuomotor policy: A policy that maps visual observations to motor commands. “RT-2, OpenVLA, π0\pi_0, and π0.5\pi_{0.5} learn language-conditioned visuomotor policies end to end”
  • Waypoint: An intermediate target position or configuration along a robot trajectory. “inverse-kinematics solutions and collisions at every waypoint”
  • White box: A system whose internal state, rules, and decision process can be inspected or modified. “In contrast, code is a white box that implements the Embodied Turing Machine directly”
  • World Action Model (WAM): A model category designed to predict or produce actions in an embodied environment. “World Action Models (WAMs) include \mbox{Awomo-0.5}”
  • WorldState: A persistent representation of measured objects and their states throughout an episode. “Records persist in an episode-level WorldState”

Open Problems

We found no open problems mentioned in this paper.

Tweets

Sign up for free to view the 7 tweets with 175 likes about this paper.