Can Agents Manipulate?
*Equal contribution · Technical report
And do they need a physical agent framework?
Simulation and hardware, cut together. In simulation, five agents per task with dimOS: bin lift, open bottle and Spell DIMOS. On the robot: a bin lift as code, the bottle cap unscrewed with dimOS, and policy-in-the-loop teleoperation. AstraSolFable 5.1Opus 5.5Argon
Figure 1: Run explorer. Click an agent name below the player, or a path, to replay its run. The 3D view (left) shows the recorded end-effector paths of all ten runs (five agents, each with and without dimOS), and the wrist and overview cameras (right) replay the picked run on the same timeline. The table reports 30-trial means for all ten; within each model, the better setup is tinted in that model's colour.
Introduction.
Coding agents built on Large Language Models (LLMs) have been extended to robot control by composing perception and control primitives into executable programs [2]. Closest to our work, SimEX [8] has a coding agent build its own primitives in simulation on top of a low-level robot API before adapting them on hardware. However, such programs are bounded by the primitives available to the agent. Given only a raw robot interface (RGB-D frames, arm state, and end-effector velocity and gripper commands), an agent must operate end-to-end, reconstructing perception and motion planning in its own code (e.g., estimating object poses from images). This reconstruction costs time, tokens and failed attempts.
In this work, we ask whether the interface, rather than the model, determines the efficiency with which a coding agent completes manipulation tasks. To isolate this effect, we hold the agent harness, robot and task fixed and vary only the interface, comparing the dimOS Python API [4] against a raw robot interface. We evaluate five models on three tabletop manipulation tasks in simulation, totaling 900 runs, and demonstrate the same effect on hardware, where a dimOS agent on a 6-DoF Piper arm reaches first success 1.7–4.2× faster than an end-to-end baseline while using 1.5–5.4× fewer tokens. This gap exceeds that in simulation, where the absence of sensor noise allows a capable model to compensate for a raw interface. Fig. 1 replays a representative run of every agent and task.
Setup.
Robots
- Simulation: 7-DoF xArm7 in MuJoCo [1] with a wrist-mounted RGB-D camera.
- Hardware: 6-DoF Piper for the head-to-head comparison; 7-DoF xArm7 for skill transfer and teleoperation (Secs. 06 and 07).
Agent and interfaces
- Agent: pi coding agent, limited to 150 steps per run.
- Models: GPT-6 Astra, Sol, Fable 5.1, Opus 5.5 and Argon.
- Interfaces: dimOS Python API or raw robot interface; only the interface differs between setups (Fig. 2). Without dimOS, the agent may install any library it needs.
- Hardware baseline: GPT-6 Astra operating end-to-end, estimating object poses directly from images.
- ROBOT.md
- RGB image
- depth image
- camera pose
- arm state
- gripper state
edit · write
- TCP velocity
- gripper
- DIMOS.md
- Python API(streams, robot state)
edit · write
- Python API(localize, grasps, moves)
Figure 2: What each agent receives (in) and what it can call (out). The harness, models and robot are shared, and both agents have the same harness tools (inside the agent box): read, bash, edit and write, so each can grep, run Python and write its own code through bash. Without dimOS, the agent reads wrist RGB and depth images, camera pose and arm and gripper state as raw topics, and acts only through end-effector (TCP) velocity and gripper commands, building its own perception and motion. With dimOS, everything goes through the dimOS Python API described in DIMOS.md. It reads the same camera and arm data, and adds dimOS skills such as perception (localize, grasps) and planned arm moves that report when they fail.
Tasks and grading
Three tasks of rising complexity (Table 1), each run 30 times per model and setup, give 900 simulation runs. Each run is scored by a task-specific grader S ∈ [0, 1] and passes at S = 1 (Sec. 04).
Opus · Argon
Table 1: Tasks. The prompt as given to the agent, the time limit and the complexity from Eq. (1); each task's score is defined in Sec. 04.
| Task | Prompt | Limit | Complexity |
|---|---|---|---|
| Bin lift | Pick up the yellow bin and hold it at least 5 cm above the table. | 20 min | 6.5 bits |
| Open bottle | Open the water bottle: unscrew the cap and take it off the bottle, then finish. | 60 min | 11.2 bits |
| Spell DIMOS | Arrange the letter blocks so they spell DIMOS. | 60 min | 37.5 bits |
Task complexity · Fitts's law [5]
- i
- each move of the shortest plan
- Di
- move distance or angle
- Wi
- landing tolerance
C counts only the motion of the shortest plan, not perception or recovery from errors.
With and without dimOS.
We hypothesize that dimOS lowers the cost, time and model turns an agent needs to pass a task, and that this holds as tasks get more complex. As in studies of agent-computer interfaces [11], we compare each agent only with itself, through a dimOS factor X that compares its cost, time and turns per unit of score without and with dimOS (formula under Per-task detail). X > 1 favors dimOS, and a task's factor is the median over its five agents.
X is above 1 on every task: 1.57× on bin lift, 1.64× on open bottle and 1.97× on Spell DIMOS (Fig. 4), and the time dimOS saves per run is largest on the longest tasks, from 1.8 to 4.8 and 7.9 minutes, consistent with the hypothesis. Figs. 5–7 break down each agent's time, tokens and cost, the composition of its run time, and how tokens accumulate over a run.
Hardware
We first run the comparison on hardware, on the 6-DoF Piper, for two tasks (Fig. 3). On bin pick-up, where the dimOS agent can build on the existing dimOS pick-and-place skill, it reaches first success 4.2× faster with 1.5× fewer tokens than the end-to-end baseline. On bottle-cap unscrewing, where dimOS offers less existing skill to build on, the speedup in time narrows to 1.7×, but the reduction in tokens widens to 5.4×.
Bin pick-up 6-DoF Piper · pinch grasp at the bin's edge
Unscrew bottle cap 6-DoF Piper · less existing skill to build on
faster to first success, 11:55 vs. 50:19
fewer tokens to first success, 1.32M vs. 7.15M
Figure 3: First success on hardware, one run per setup on a 6-DoF Piper; the baseline is GPT-6 Astra operating end-to-end. Videos are shown at 60×.
Simulation
How much more a run needs without dimOS
Per-task detail
How the dimOS factor is measured
c, t, u: no-dimOS ÷ dimOS ratios of mean cost, run time and model turns per unit of mean score, over all runs; combined by geometric mean [12]. X > 1 favors dimOS; a task's value is the median over its five agents.
Figure 4: The dimOS factor X per agent and task, on a log scale. Each dot is one agent; the black line marks the median across agents.
Graders.
Each task is scored by a grader S ∈ [0, 1], and a run passes only at S = 1. Partial credit rewards contact and measurable progress, so that a run that unscrews the cap but leaves it on the bottle scores higher than one that never touches it. [·] denotes the indicator function.
Δz: height the bin has gained; [touched]: the bin moved or the gripper is near it.
θ: angle the cap is unscrewed; d: how far the cap is lifted off the neck.
p(u): letter pairs in order along reading direction u; n(u): blocks flat and upright along u; max over u, so any reading direction counts.
Across all runs, almost every run gets through the early stages of its task, and the misses come at the last stage (Fig. 8).
Figure 8: Share of runs that reached each step of the task's grader (Eqs. 2–4), with and without dimOS; the final step of each task is a pass.
Comparing agents.
We rank agents two ways: by efficiency (Fig. 9) and by reliability (Fig. 9b). Sol is the most efficient and Astra the most reliable; with dimOS, every agent becomes more efficient, and none becomes less reliable.
Efficiency: effort per point of score
Figure 9: Agents ranked by efficiency-weighted score; Fig. 9b ranks them by reliability. With dimOS, Sol leads and Argon trails, its runs scoring well but taking the longest; without dimOS every agent falls and the order changes.
How the efficiency score is measured · after SPL [10]
S: the run's score; e: its effort, the geometric mean of cost, time and input tokens; e*: a near-best effort for the task, the 10th percentile of its runs. 1 = perfect score at near-best effort; 90 runs per agent and setup.
Reliability: how often each agent completes the task
Figure 9b: Agents ranked by reliability; ties broken by pass⁵.
How reliability is measured
c: runs that pass (S = 1) out of n; the whisker is a 95% Wilson interval. pass⁵ is the chance that five runs of the same task all pass, after τ-bench's passk, averaged over the three tasks.
Code as policy.
Since the dimOS agent solves each task by writing a Python program, the final program can be stored and reused as a skill, similar to Code as Policies [2]. A bin pick-up skill learned on the 7-DoF xArm transfers to the 6-DoF Piper with 34% fewer tokens than learning it on the Piper from scratch (Fig. 10a–b). Once learned, the skill reruns from new start positions in about 20 s per pick without querying a model (Fig. 10c).
Figure 10: Skill transfer and reuse for bin pick-up. (a) Skill learned on the 7-DoF xArm, first success at 7:12. (b) The same skill carried over to the 6-DoF Piper, first success at 11:10 using 2.70M tokens, against 4.11M when learning on the Piper from scratch (Fig. 3). (c) The learned skill rerun from five new start positions, about 20 s per pick with no model queries, compared with 62 min and 17.98M tokens to learn it. Videos (a) and (b) at 60×, (c) at 10×.
Human in the loop.
For dexterous, contact-rich tasks whose behavior is difficult to specify in code, training an imitation learning (IL) policy from demonstrations may be more appropriate than writing programs. Even here, dimOS skills reduce human effort. In policy-in-the-loop teleoperation, a dimOS skill drives the approach to the pre-grasp and the operator performs only the grasp and lift, collecting ten demonstrations 1.9× faster than end-to-end teleoperation (Fig. 11). Since an IL policy reproduces the pace of its demonstrations, faster demonstrations are expected to yield a faster policy; and since a skill-driven approach is more consistent than a human operator, it avoids the mixed-quality demonstrations known to degrade IL performance [9].
Figure 11: Bag lifting. (a) 61 s per demonstration; (b) 31 s, with a dimOS skill driving about 80% of each; (c) the IL policy trained on (b), in real time; (a–b) at 30×. Pipeline: temporal ensembling [6], LeRobot v3 recording [7].
Results.
- dimOS reduces time and cost. With dimOS, agents score better on every task and need less cost, time and turns per point of score; the dimOS factor stays above 1 on every task, including the most complex (Fig. 4).
- Failures occur at the last step. Agents miss steps that require interpreting the scene, such as a turned letter or a cap left on the bottle; dimOS narrows this gap (71% vs. 58% of Spell DIMOS runs pass; Fig. 8).
- Fewer turns is the main lever. Model latency dominates run time (Fig. 6), and dimOS cuts turns most on the longer tasks (42.5 vs. 60 on open bottle).
- The gap widens on hardware. On the Piper, dimOS reached first success 1.7–4.2× faster with 1.5–5.4× fewer tokens (Fig. 3), an early signal from one run per setup.
- The benefit varies by agent. It peaks where an agent struggles most without dimOS, as Opus 5.5 does on open bottle, and stays near 1 for Argon on Spell DIMOS (1.12×). Argon uses dimOS differently: with it, Argon takes more turns on Spell DIMOS (42 vs. 36.5) at about the same time and cost, so its effort barely drops.
Conclusion.
Holding the harness, robot and task fixed, we find that the interface determines what each manipulation success costs a coding agent. A capable model can compensate for a raw interface on a short task, but at a growing cost in time; dimOS lowers it for every agent on every task, and its advantage widens on hardware. We hope this work motivates evaluating robot interfaces as rigorously as the models that use them.
Limitations and future work
Our tasks are single-arm and tabletop, all agents share one harness, and the hardware results rest on one run per setup. Results are also sensitive to the wording of prompts and documentation, and with 30 trials per configuration we report no significance tests. We plan to address these in three directions.
- A physical harness. We plan to replace pi with a Dimensional harness built for physical tasks, one that helps agents perceive the scene, adapt to it and act on any robot.
- Time to full skill distillation. Rather than first success, we will track time and effort until a task is fully distilled into a reusable skill, where we expect the difference between interfaces to be more pronounced.
- Long-horizon tasks. Beyond tabletop tasks, we will extend the study to long-horizon manipulation, which the authors' prior work [13] identified as a weakness of generalist policies, and investigate how autoresearch combined with this harness can address it.
Cite this work.
If you use this report in your research, please cite it as follows.
. Can Agents Manipulate? Dimensional Research technical report, 2026.
BibTeX@misc{dimensionalcanagentsmanipulate,
author = {Choe, Dan B.W. and Dasyam, Ruthwik and Sangeetha, Sundhar Vinodh},
title = {{Can Agents Manipulate?}},
howpublished = {Online research report, Dimensional Research},
note = {Technical report},
year = {2026}
}
References
- Todorov, E., Erez, T., Tassa, Y. “MuJoCo: A physics engine for model-based control.” IROS 2012.
- Liang, J. et al. “Code as Policies: Language Model Programs for Embodied Control.” ICRA 2023. arxiv.org/abs/2209.07753
- Dimensional Research. “Can Jev Nav?” 2026. research.dimensional.org/system-one-navigation
- dimOS source code. github.com/dimensionalOS/dimos · Documentation. docs.dimensional.org
- Fitts, P. M. “The information capacity of the human motor system in controlling the amplitude of movement.” Journal of Experimental Psychology 47(6), 1954.
- Zhao, T. Z., Kumar, V., Levine, S., Finn, C. “Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware.” RSS 2023. arxiv.org/abs/2304.13705
- Cadene, R. et al. “LeRobot: State-of-the-art Machine Learning for Real-World Robotics in PyTorch.” 2024. github.com/huggingface/lerobot
- Hu, J., Martín-Martín, R., Stone, P., Duan, R., Jiang, Z., Shi, G. “SimEX: Simulation-Integrated Robotics AutoResearch.” 2026. arxiv.org/abs/2609.38982
- Mandlekar, A., Xu, D., Wong, J., Nasiriany, S., Wang, C., Kulkarni, R., Fei-Fei, L., Savarese, S., Zhu, Y., Martín-Martín, R. “What Matters in Learning from Offline Human Demonstrations for Robot Manipulation.” CoRL 2021. arxiv.org/abs/2108.03298
- Anderson, P., Chang, A., Chaplot, D. S., Dosovitskiy, A., Gupta, S., Koltun, V., Kosecka, J., Malik, J., Mottaghi, R., Savva, M., Zamir, A. R. “On Evaluation of Embodied Navigation Agents.” 2018. arxiv.org/abs/1807.06757
- Yang, J., Jimenez, C. E., Wettig, A., Lieret, K., Yao, S., Narasimhan, K., Press, O. “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024. arxiv.org/abs/2405.15793
- Fleming, P. J., Wallace, J. J. “How not to lie with statistics: the correct way to summarize benchmark results.” Communications of the ACM 29(3), 1986. doi.org/10.1145/5666.5673
- Choe, D. B. W., Sangeetha, S. V., Coogan, S., Kousik, S. “Make Your VLA More Robust Without More Data By Interleaving Motion Planning.” 2026. arxiv.org/abs/2606.00985