Classical programming is extremely good
It is worth starting here, because the enthusiasm around learned policies tends to obscure it. A taught robot program executing a fixed path is fast, deterministic, verifiable, debuggable by a technician at 3 a.m., and repeatable to a fraction of a millimetre. No learned policy currently matches that on any of those axes. If your task can be specified as a path, specify it as a path.
Where it breaks
Teach-and-repeat fails on three conditions, and they are recognisable in advance.
- The part is not where you said it was. Vision guidance already solves the easy version of this. The hard version is unstructured presentation — parts in a bin, cables in a tray, textiles in a heap.
- The part changes shape during the task. Cables, foam, film, wiring harnesses, seals. The state after step three depends on the physics of steps one and two, and cannot be predicted from a fixed path.
- The variant count exceeds what you can teach. When engineering time to teach a new SKU exceeds the production value of running it, the economics of fixed programming break down even though it would technically work.
If none of these applies, learned policies will underperform a well-written program and cost more to deploy. That is the most common honest answer, and we give it regularly.
What deployment actually requires
Assuming the application is genuinely on the right side of the boundary, the engineering work is substantial and mostly unrelated to model architecture.
- A simulation environment in which the task can be trained, with domain randomisation across lighting, friction, mass and geometry — because a policy that only works at one coefficient of friction will not transfer.
- Demonstration data where imitation learning is used. Typically a few hundred teleoperated demonstrations covering the real range of variation, which requires a teleoperation rig and someone's time.
- A measured sim-to-real gap. Not asserted — measured, on hardware, with a success rate and a confidence interval.
- A bounded operating envelope with confidence monitoring and an explicit deterministic fallback. A policy that fails into an undefined state is not deployable on a production line, and that constraint is non-negotiable.
What to do this year
For most manufacturers the correct posture is to instrument for it rather than deploy it. Record demonstrations of the tasks you eventually want automated. Keep vision data with outcome labels. Build the twin of the cell. These assets are useful immediately for conventional engineering and become training data when the technology is ready for your specific task.
The plants that will adopt physical AI fastest are not the ones buying it earliest. They are the ones that spent the intervening period accumulating data that a policy can be trained on.
Talk to us about this
If this is relevant to a line you are working on, our engineers are happy to look at the specifics. Related capability: Physical AI. You can also browse delivered projects, the technology stack or contact the engineering team.