# Demo vs deployment: October

Ruben Verhack, 2026-10-19. https://vesper.dev/blog/demo-vs-deployment-october-2026/

Every few weeks a robotics result makes it look like the problem is solved. I read a lot of them, and most are good work. Reading a paper as a researcher and reading it for a factory are two different things, though.

For a factory I ask three questions. What was the system given before it started? What does the headline number actually measure? And would it run on a production line, unattended, shift after shift, with someone able to sign off on it?

Here are five from the past months, with my verdict on each.

## AlphaNIST: the headline runs ahead of the evidence

NVIDIA and the University of Washington train [one policy on all 20 tasks of the NIST assembly board](https://alpha-nist.github.io/), with a simple success or failure reward and no demonstrations, and report 98.2% success. One policy for a whole board, and even ten assemblies in a row without being told the order, is impressive work, and some of the strategies it finds on its own, like using the board to flip a part, are fun to watch.

The AlphaGo Zero framing is where it runs ahead. Training starts from a large bank of positions: loose parts, but also parts already in the gripper, nearly mated or partly assembled, with practice concentrated where the policy succeeds about half the time. That is a smart curriculum, and in a factory you would do the same, the assembled pose is in the CAD. But it isn't learning from scratch the way AlphaGo Zero learned Go, and the 98.2% is a training number averaged over those head starts. Success from loose parts alone isn't reported, everything runs in simulation with perfect point clouds, and the same 20 parts are used for training and testing.

For a factory it is a strong simulation result on known parts. The next step that matters is the real board.

## Skild S1: bonkers cool, and the wrong shape for a factory

[S1](https://www.skild.ai/blogs/s1) watches one video of a person doing a task and then attempts it, with frozen weights and no training: potting a plant, pour-over coffee, assembling a kit, eleven minutes from recording to the robot trying. That is absolutely bonkers cool.

The fine print is in their own post. The headline 66% is a success rate per step, measured with a human recovering failures so that every step gets graded. When the scene varies, the score on known tasks drops from 96% to 75%. And their own chart shows that training on 2,000 demonstrations gets the same tasks to 86%. One video is enough to specify the task, reliability still has to be bought with data.

For homes and very unstructured work this may well be the shape. For a production line it is overkill, and that's fine. The space is huge.

## HomeBody: a frontier model picking the skills, live

Stanford's TML lab wired [GPT-6 Astra directly to a Unitree G1 humanoid](https://tml.stanford.edu/homebody/). The robot first explores an unseen kitchen and builds a digital twin from its own camera. Then Astra looks through the robot's eyes, picks one of five skills and a target through a tool call, and the skill does the motion. No environment-specific training.

Cool to watch, and it is slow. Astra runs remotely and, in their own words, its reasoning latency introduces pauses between skills. The videos are sped up, up to 14 times for picking from a drawer, and there are no success rates yet. Put a frontier model in the loop at runtime and you pay for its thinking on every cycle. In a factory you want that thinking done once, in the design phase.

## RAX: exploring on the robot, as part of the design

A [coding agent explores on the real robot](https://robot-agent-exploration.com/), writes what works into a program and keeps a library of verified skills. A backend refuses anything outside the robot's limits. No demonstrations, no policy training.

That is the shape I believe in, and the exploration is part of the design phase, exactly where intelligence belongs. Doing it on the real robot is a creative choice: there is no gap to bridge between simulation and reality. What it gives up is the scale of simulation. In the paper an operator resets and advises, and the final automatic block-tower rebuild took 663 seconds for seven pieces after a six-hour session. It doesn't scale badly, it just doesn't scale the way simulation does.

Closer to home, Ghent University's AIRO lab ran [a local, open-weight coding agent on a UR3e](https://rtalwar2.github.io/agentic-coding-for-robot-manipulation/) with nothing more than a safety-limited motion service and two written skills per game. It finished 30 of 45 toy-game tasks without operator help, writing its own perception code along the way, and the paper is refreshingly precise about where the rest went wrong. Same shape, on a single local GPU.

## RoboSimStudio: the scalable way to build twins

Berkeley's AUTOLab and NVIDIA let a coding agent turn [a phone video of a robot task into a physics simulation](https://robosimstudio.github.io/) in about an hour, deformables included. Open source.

Estimating physics from video is the scalable way to build twins, and it is how we build ours, together with the CAD that is already known. The next step: one video gives one estimate, many videos give the spread, and for soft parts the spread is the information you need. Validates the direction, and compatible with how we work.

## The thinking belongs in the design phase

The methods are converging: agents that compose skills and write programs, simulations built from video. That validates the direction. The difference is where the thinking happens, live on the robot or once, in the design phase. None of them shows a station running unattended, shift after shift, with a number a plant can sign off on. That part is hard engineering, productization and feedback from real deployments, over and over, and it is where we spend our time.