Dimensional Research / Manipulation

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

Loading scene…
Drag · scroll · click a path
Recorded cameras
wrist camera
overview camera
0 / 0 s
Task
the better setup of each model, in its colourscore: higher is better; the rest: lower is better

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.

01

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.

02

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.
Without dimOSraw robot interface
In
  • ROBOT.md
  • RGB image
  • depth image
  • camera pose
  • arm state
  • gripper state
◎Agentpi + modelread · bash
edit · write
Out
  • TCP velocity
  • gripper
With dimOSdimOS Python API
In
  • DIMOS.md
  • Python API(streams, robot state)
◎Agentpi + modelread · bash
edit · write
Out
  • 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).

3tasksbin · bottle · blocks
×
5modelsAstra · Sol · Fable
Opus · Argon
×
2setupsdimOS · no dimOS
×
30trialseach configuration
=
900simulation runsall 30 trials finished

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.

TaskPromptLimitComplexity
Bin liftPick up the yellow bin and hold it at least 5 cm above the table.20 min6.5 bits
Open bottleOpen the water bottle: unscrew the cap and take it off the bottle, then finish.60 min11.2 bits
Spell DIMOSArrange the letter blocks so they spell DIMOS.60 min37.5 bits

Task complexity · Fitts's law [5]

C=Σi log2(Di / Wi+1)(1)
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.

03

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

With dimOSfirst success11:55tokens4.11M60× · builds on dimOS pick-and-place
Without dimOS Astra end-to-endfirst success50:19tokens6.25M60×

Unscrew bottle cap 6-DoF Piper · less existing skill to build on

With dimOSfirst success16:33tokens1.32M60×
Without dimOS Astra end-to-endfirst success27:35tokens7.15M60×
Bin pick-up4.2×

faster to first success, 11:55 vs. 50:19

Unscrew bottle cap5.4×

fewer tokens to first success, 1.32M vs. 7.15M

Bin pick-up

dimOS4.11M · 11:55
Astra6.25M · 50:19

Unscrew bottle cap

dimOS1.32M · 16:33
Astra7.15M · 27:35

Bar length is proportional to total tokens to first success; times are to first success.

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

30 trials × 5 agents per setup · tasks in order of complexity

How much more a run needs without dimOS

Per-task detail

How the dimOS factor is measured

X=∛(c · t · u)

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.

30 trials × 5 agents per setup · the task buttons switch all three charts

Time, tokens and cost

Figure 5: Time, tokens and cost per agent, shown as box plots. The bar marks the median run, whiskers extend to 1.5× the interquartile range, rings mark outliers, and triangles mark runs beyond the axis.
each agent's colour: dark = dimOS, light = no dimOSbar length: median runmiddle half of runs (25th–75th percentile)whiskers: typical range (within 1.5× the middle half)outlier run, beyond the whiskersN out: outlier runs in that row
Figure 6: Run-time breakdown. Mean run time per agent, divided into model response latency and all remaining time (scripts, tools and arm motion). Runs that reached the time limit are excluded.
model thinkingeverything elsetop bar = with dimOS (dark), bottom bar = without (light), each agent in its colour63% model: share of the run spent waiting for the model
Figure 7: Token burn. Cumulative input tokens against elapsed time, one line per run. Runs above the 90th percentile in time or tokens are omitted from this chart only; beyond the time by which 80% of runs have ended, the axis is compressed (shaded).
one dimOS runone no-dimOS runwhere a run endedmedian across runs (a finished run holds its total)with a model picked: median of all modelscompressed tail
Model
04

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.

Sbin=0.2·[touched]+0.8·min(Δz / 5 cm, 1)(2)

Δz: height the bin has gained; [touched]: the bin moved or the gripper is near it.

Sbottle=0.1·[touched]+0.5·min(θ / 200°, 1)+0.4·[d≥2 cm](3)

θ: angle the cap is unscrewed; d: how far the cap is lifted off the neck.

Sblocks=maxu [ 0.7·p(u) / 4+0.3·n(u) / 5 ](4)

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).

Each row is one grader step (n/N); a run that reaches step n has also passed steps 1…n−1.

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.

05

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

upper, darker bar: with dimOSlower, lighter bar: without dimOSshown in each agent's own colour95% CI#n: rank within the setup

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]

E=mean over runs of S · min(1, e* / e)

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

upper, darker bar: with dimOSlower, lighter bar: without dimOS95% CI#n: rank within the setuppass⁵: chance that 5 runs of a task all pass

Figure 9b: Agents ranked by reliability; ties broken by pass⁵.

How reliability is measured

pass rate=c / n   ·   pass⁵=C(c, 5) / C(n, 5)

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.

06

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).

(a) Learned on the 7-DoF xArm
(b) Transferred to the 6-DoF Piper
(c) Rerun without a model

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×.

07

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].

(a) End-to-end teleoperation
(b) Policy-in-the-loop
(c) IL policy rollout

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].

08

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.
09

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.
10

Cite this work.

If you use this report in your research, please cite it as follows.

Dan B.W. Choe, Ruthwik Dasyam and Sundhar Vinodh Sangeetha. 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

  1. Todorov, E., Erez, T., Tassa, Y. “MuJoCo: A physics engine for model-based control.” IROS 2012.
  2. Liang, J. et al. “Code as Policies: Language Model Programs for Embodied Control.” ICRA 2023. arxiv.org/abs/2209.07753
  3. Dimensional Research. “Can Jev Nav?” 2026. research.dimensional.org/system-one-navigation
  4. dimOS source code. github.com/dimensionalOS/dimos · Documentation. docs.dimensional.org
  5. Fitts, P. M. “The information capacity of the human motor system in controlling the amplitude of movement.” Journal of Experimental Psychology 47(6), 1954.
  6. 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
  7. Cadene, R. et al. “LeRobot: State-of-the-art Machine Learning for Real-World Robotics in PyTorch.” 2024. github.com/huggingface/lerobot
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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