Niko West of Rerun.io presented no new model. His argument may be more useful to a founder: the best way to discover what a robot must learn is to provide a narrow valuable service before it is autonomous.
Choose one customer problem. Solve it first with teleoperation and off-the-shelf hardware. Use live operations to discover the product, evaluation and data you actually need.
West calls these businesses robotics application companies or “neo-integrators.” They own a complete physical workflow—perhaps in a warehouse, data center, construction site, factory or food operation—while building as little custom hardware and foundation-model research as possible.
Why teleoperation is a product strategy
Teleoperation is often described as an embarrassing bridge to autonomy. In this playbook it is the first deployable version. It answers the commercial question before the hardest research question: will someone pay for the outcome, even while a human remains in the loop?
The physical world is too varied to specify in a lab. A paper-plane robot might learn that the customer needs 1,000 good planes per day, onboarding a new design matters more than raw speed, a paper tray halves failures, bad outputs are cheap if automatically sorted, or packing boxes is ten times more valuable than folding. These facts determine the hardware, metrics, data taxonomy and next product. A benchmark cannot reveal them.
The three-stage loop
- Sell and deploy. Use off-the-shelf hardware and teleoperation to deliver one outcome.
- Build the learning basics. Fine-tune an open policy on a few hours of demonstrations, create a replica customer environment and define repeatable evaluation.
- Iterate and scale. Alternate collection, training, evaluation and deployment while improving operations, support and hardware reliability.
The ordering is important. Collecting a giant dataset before training is dangerous because the first model will reveal collection bugs and missing variation. Large robotics teams frequently respond to a failing policy by changing instructions to operators. Training is therefore part of data-quality control, not a downstream consumer.
Evaluation is the application's private advantage
A generic model provider optimizes generic benchmarks. The application company learns the customer's loss function. For paper planes, success may include sharp edges, design fidelity, weight distribution, throughput and time to support a new design. That rubric becomes a durable asset because it encodes business reality.
West recommends manually scoring outcomes until the rubric stabilizes, then automating it with models or external operations. Track rollout metadata and failure classifications from the beginning. A policy's average success rate is less actionable than knowing which failures come from perception, grasping, material variation, operator behavior or broken hardware.
Why ordinary data infrastructure fights robotics
Physical AI data is multimodal, multi-rate and episodic. Camera frames, depth, poses, force, audio and actions arrive on different clocks. Records contain 3D geometry and deeply nested structures. Queries frequently ask for a synchronized slice around an event rather than a row in a business table.
Forcing this into a conventional table-first stack produces converters and one-off indexes at every stage. The data layer must preserve time, modalities, episode boundaries and spatial meaning from collection through visualization, debugging and training. This is the product context for Rerun's open-source SDK and hosted data catalog, but the architectural point stands independently.
Autonomy is a scaling factor, not the entry ticket
When human operation already creates margin or validates demand, autonomy can be introduced task by task. Plot the application's own learning curves instead of guessing upfront how much data “robotics” needs. Split work into composable subtasks. Automate high-frequency, well-measured segments first and keep humans for rare or ambiguous states.
This makes the business robust to slower-than-expected model progress. It also generates exactly the recovery and edge-case data the model needs. If a task cannot be performed reliably through the chosen teleoperation interface, imitation learning from that interface is unlikely to rescue it.
The moat is wider than the model
Physical deployment is “death by a thousand cuts”: assembly, unboxing, calibration, spares, customer onboarding, operator training, support and hardware replacement. Those burdens are also defenses. A frontier-model vendor is unlikely to reproduce every site's workflow and service operation.
The opportunity exists now because capable arms and open base policies have reduced the capital needed to test a narrow application. It is still not SaaS economics: inventory, field service and safety remain real. The analogy is about vertical ownership and recurring workflow value, not gross margins magically becoming software-like.
The caveats
- Teleoperation economics fail when latency, safety, privacy or operator-to-robot ratio cannot support the service.
- Demonstrations inherit operator habits and may undersample recovery.
- Not every teleoperable behavior is learnable with the available observations and policy class.
- A remote human is part of the safety system; reducing intervention requires rigorous exit criteria, not a marketing autonomy percentage.
The takeaway
The teleoperation-first thesis is an uncertainty-management strategy. It replaces speculative requirements with paid observation, turns operations into a data engine and lets autonomy scale a service whose value is already known. The next robotics winners may look less like labs waiting for a general robot and more like vertical operators that automate one measured failure mode at a time.
Sources: Niko West's talk, transcript, and Rerun.