The robotics industry has a framing problem. Ask most people to describe the landscape and they will draw a binary: teleoperation on one side, autonomous robots on the other. Teleoperation is the bridge technology, the thing you use until autonomy is ready. Autonomy is the goal. This framing is wrong in a way that has real commercial consequences for anyone making decisions about robot deployment today. Teleoperation is not the alternative to autonomy. It is the path to it.
What the research actually shows
A recent paper from MIT and Karlsruhe Institute of Technology demonstrates something that should shift how the industry thinks about this. Researchers built a system that used teleoperation data to train a diffusion-based model for contact-rich manipulation. The training set was small: 1.6 hours of teleoperated demonstrations covering two task types, parkour-style obstacle traversal and robot-assisted physical therapy. They then tested the trained model on peg-in-hole insertion, a task it had never seen during training, across three different peg geometries of increasing complexity. The result: 100% success across all three peg types, all 30 trials each. A fixed impedance controller achieved 100% on the simple cylindrical peg, 13% on the square peg, and 0% on the star peg. Even a carefully hand-tuned controller, developed by an experienced engineer after testing 15 different parameter combinations, achieved only 70% on the most complex geometry. The model trained on 1.6 hours of teleoperation data generalised to an unseen task with geometries it had never encountered, with no task-specific training, and outperformed expert-engineered solutions. This is not an argument for a specific architecture. It is an argument for a specific approach: collect high-quality teleoperation data in real conditions, and the generalisation capability that emerges is broader and more robust than most people currently expect.
The graduated autonomy model
The binary framing misses the continuous nature of how autonomy actually develops. At the start of a deployment, a human operator is present for most decisions. As the robot accumulates experience with a specific task in a specific environment, certain sub-tasks become predictable enough to automate. The operator's role shifts from active control to supervision and exception handling. Over time, the proportion of tasks requiring operator input decreases. The operator-to-robot ratio improves. Unit economics improve with it. The deployment becomes progressively more autonomous without any discrete transition point where teleoperation ended and autonomy began. This is graduated autonomy, and it is how real-world robot capability actually develops when the deployment architecture is designed to support it. The key phrase is "designed to support it." A deployment that treats teleoperation as a temporary measure and does not invest in capturing and utilising the data it generates will not move along this curve. The data will be wasted. The robot will remain as capable at the end of year two as it was at the start. A deployment that treats every teleoperated action as a training signal, that captures force-aware demonstrations in production conditions, that feeds those demonstrations into ongoing model development, will move continuously along the autonomy curve.
Why this matters for operators evaluating deployment partners today
If you are a logistics or manufacturing operator considering a robot deployment, the right question is not "how autonomous is this robot right now?" The right question is "what is the trajectory, and how does this deployment contribute to it?" A partner whose robot is at 40% autonomous today but is on a credible path to 80% over two years is more valuable than a partner whose robot claims higher autonomy today but is a static system with no improvement mechanism. The data flywheel is what creates the trajectory. Teleoperation generates demonstrations. Demonstrations train better policies. Better policies reduce the scope of what teleoperation is needed for. That reduction frees operator capacity, which improves unit economics, which makes the deployment more commercially viable, which enables scaling, which generates more data. This is not theoretical. It is the architecture that makes physical AI work at scale in real environments.
Why waiting for full autonomy is the wrong strategy
There is a version of the autonomy debate where the right move is to wait. Hold off on deployment. Let the technology mature. Deploy when it is genuinely autonomous and you do not need operators at all. This is wrong for at least two reasons. First, the timeline. Full autonomous manipulation of the kind required for general industrial deployment is not a near-term outcome. The researchers whose work we cited above, people working at the frontier of this technology, are still publishing results on tasks like peg-in-hole insertion as research contributions. The gap between laboratory demonstrations and production-ready full autonomy for variable, unstructured industrial tasks remains large. Second, and more importantly, full autonomy requires the data that only deployment generates. The robots that will be most capable in three years are the ones that have been collecting production data for three years. The companies that waited will be starting from scratch at exactly the moment their competitors have a three-year head start on the distribution that matters. Autonomy is not a feature you wait to receive. It is a capability you build through deployment. At Telepath, every deployment we run today is contributing to the foundation model capabilities that will make our robots more autonomous tomorrow. The operator hours are not a cost to be eliminated as quickly as possible. They are the mechanism by which the autonomy gets built. That is the model. It is not a compromise position. It is the only architecture that actually works.