Embodied Turing Machines: Stateful Code for Robot Recursive Self-Improvement
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.
Paper Prompts
Sign up for free to create and run prompts on this paper.
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:
- 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?
- 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?
- 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?
- 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.
- 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:
- Find three blocks and three cups.
- Match each cup with a block.
- Cover the blocks with the cups.
- Remember which color is under each cup.
- 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:
- Watched failed attempts.
- Checked which stored value or rule caused the failure.
- Suggested a small code change.
- Tested the change.
- 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:
- Check the object’s new position.
- Return to an earlier stage.
- 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:
- How accurately the code understands the robot and its surroundings.
- 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 msand 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 be the execution trace of task under code and observations ”
- 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, , and 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”






