The demos say robotics is almost solved. Walk onto most shop floors and you see classical automation on the high-volume lines, and the rest done by hand. Oliver Hsu at a16z called the distance between the two the physical AI deployment gap, and his six gaps are the best map of it I know.
As I presented at Flanders Make's Physical AI & Mobile Robotics: Beyond the hype day on 15 September, here they are next to what a production line actually needs:
| Gap | Where the demos are | What a line needs |
|---|---|---|
| Distribution shift | 95% in the pilot, 60% on site (a16z's example) | The same result on site as in the pilot |
| Reliability | 95% success means 50 interventions a day | 99.9%, unattended |
| Compute | Large models, heavy compute | Runs locally, within the cell's latency budget |
| Integration | Not connected to the line | Orders in, status and faults out, safety signals in |
| Certification | Weights, nothing to inspect | A machine you can inspect and sign off |
| Maintenance | An AI team keeps it running | The plant's own technicians |
Three gaps close with the right shape
The a16z piece calls the gap "as real at present as it is likely transitory", and expects better infrastructure and tooling to close it. I'd go a step further: half of it closes by choosing what runs on the robot. If that is a program, generated and proven in the design phase, then compute, certification and maintenance look very different. A program runs locally, inside the cell's cycle time. It can be inspected and checked against a certified safety envelope before it runs. And when a step fails, a technician sees which step it was, and that step gets fixed.
The other three take engineering
Distribution shift, reliability and integration don't go away with any shape. They take a simulation of the real cell to prove programs before they move, skills that generalize over variation in parts, poses and light, and real deployment feedback, again and again.
Integration is the least glamorous of the three. On a real line it means an external safety signal that throttles the robot's speed, while the program still has to respect the physics of the task at that lower speed. Or a workpiece that changes because the ERP system says so, and a program that has to follow.
The 99.9% stays the requirement, and nobody gets there in one step. A program that is split into steps at least lets you work towards it: you find the step that fails, focus on that subproblem and optimize it, without touching the rest.
That work is engineering and productization, and it is where most of our time goes.