The labs publishing the flashiest papers aren't always the ones shipping real manipulation policies. More often than not, the gap between "works in a demo" and "works in production" comes down to something deeply unglamorous: data infrastructure.
Every week, your robotics team collects more demonstrations. Every week, that data needs to be ingested, compressed, quality checked, split into episodes, and made available for training. If that pipeline is manual, brittle, and slow, every week costs you engineering hours that could have gone into policy development, task design, or sim to real transfer work.
Over six months, this adds up to something brutal. The team with solid robotics data infrastructure has run 4x more training experiments, because they are not burning half their sprint debugging data issues. They have iterated on 3x more task definitions, because adding a new task to their pipeline is a config change, not a project that eats two days. They have onboarded new teleoperators faster, because quality scoring catches bad episodes automatically instead of requiring senior engineer review. They compound. You do not.
That is what I mean by "plumbing." The entire data infrastructure stack that sits between your teleoperation sessions and your trained policy. The ingestion layer. The compression. The quality scoring. The episode splitting. The dataloader. All the unglamorous machinery that determines whether your 10,000 demonstrations actually teach your model anything useful, or whether half of them are corrupted, mislabeled, or so bloated that your training run takes three times longer than it should.
The model is not the bottleneck. It hasn't been for a while.
If you have been in the manipulation space for the last two years, you have watched a remarkable convergence. Diffusion policy, ACT, pi0, and now a growing family of VLA architectures have all shown that the core learning algorithms work. Given enough clean demonstrations of a task, these models learn to do that task. The architecture debates matter at the margins, but the rough consensus is in: transformer policies trained on quality demonstration data can produce useful manipulation behaviors.
So what separates teams that ship from teams that struggle? It is almost never the model. It is almost always the data.
Specifically, it is what happens to that data between the moment it rolls off your robot and the moment it enters your training pipeline. That middle layer, that connective tissue, is where most robotics teams are hemorrhaging time, compute, and, ultimately, policy quality. And the frustrating part is that these are solved problems. Not solved in the sense that someone wrote a paper about them. Solved in the sense that functional robotics data infrastructure exists, and teams that invest in it, or adopt something like the Knonik data infrastructure platform, see the difference within weeks.
What "bad plumbing" actually looks like
Let me paint a picture that will be painfully familiar to anyone running a manipulation robotics startup.
You collect 5,000 demonstrations via teleoperation. They come off the robot as rosbag files, or maybe you have moved to HDF5, or you are one of the teams experimenting with Zarr. Either way, you have a pile of raw episodes sitting on a NAS somewhere, and each one contains camera streams, joint states, gripper actions, and maybe force-torque data, all at different frequencies, all slightly misaligned in time.
Your ML engineer writes a script to convert these into a format ready for training. It works for the first 500 episodes. Then someone changes a camera mount and the extrinsics shift. The script does not know. Then a teleoperator has a bad session — 40 episodes of fumbled grasps — and those get mixed in with everything else. The script does not know that either.
By the time you start training, your dataset is a grab bag. Some episodes are gold. Some are garbage. Some are so large that your dataloader chokes on them. You burn a week debugging why your policy randomly drops objects, and it turns out 12% of your demonstrations had a corrupted proprioceptive stream that was silently filling with zeros.
This is not a hypothetical. This is Tuesday at most robotics startups.
Compression is not optional. It is a gating factor.
One of the most underappreciated bottlenecks in robotics data infrastructure is raw storage and throughput. A single teleoperation session with two stereo cameras, a wrist camera, joint states at 100Hz, and force-torque data can easily produce 2 to 5 GB per episode. Scale that to thousands of episodes across multiple tasks and you are sitting on tens of terabytes before you have trained a single policy.
The naive response is "storage is cheap." And sure, the drives are cheap. But the downstream costs are not. Moving that data between machines, loading it into GPU memory during training, backing it up, versioning it, sharing it between team members: all of that gets harder as raw data volume grows. Teams that treat compression as an afterthought end up building custom streaming dataloaders, duct taping NFS mounts, and wondering why their training throughput is 30% of what their GPU cluster should be delivering.
A proper robotics data infrastructure solution, like what Knonik provides, treats compression as a core primitive. Not lossy JPEG compression on camera frames that throws away fine detail your diffusion policy actually needs. Real, learning-signal-preserving compression that understands the structure of multimodal robotics data and reduces volume dramatically without degrading the information your model trains on. This is the kind of thing that sounds like a detail until you realize it is the difference between training on your full dataset overnight and training on a 60% subset over the weekend because your dataloader cannot keep up.
Quality scoring: the filter you didn't know you needed
Not all demonstrations are created equal. Every teleoperator has off days. Every data collection setup has failure modes. And unlike supervised learning on ImageNet, where a mislabeled image is one bad example out of a million, a corrupted robotics episode can actively teach your policy to do the wrong thing. A fumbled grasp. A collision the operator recovered from. A demonstration where the robot moved to the right spot but took an insane trajectory to get there. These are not neutral. They are actively harmful to your policy.
The frontier labs handle this with human review. Someone literally watches a subset of episodes and flags the bad ones. This works when you have 200 demonstrations for a single task. It does not work when you are collecting data across 15 tasks, 3 robot platforms, and 8 teleoperators.
Automated quality scoring is one of those things that sounds optional until you try it. An intelligent quality scoring agent — the kind Knonik builds into its data infrastructure pipeline — can catch corrupted sensor streams, flag kinematically implausible trajectories, score demonstrations by task completion confidence, and rank episodes by how much unique information they contribute to the dataset. The result is not just cleaner data. It is a fundamentally different relationship with your data, where you actually know what you have and what it is worth.
The dataloader problem nobody talks about
Here is something that will resonate with anyone who has trained a manipulation policy on a multimodal dataset: your GPU utilization is probably terrible.
Standard deep learning dataloaders were built for images and text. They assume your data fits neatly into uniform tensors that can be batched trivially. Robotics data is the opposite of that. Variable length episodes. Multiple camera streams at different resolutions. Proprioceptive data at different frequencies than visual data. Action labels that need to be aligned to observation timestamps. All of this means your dataloader spends more time doing I/O and preprocessing than your GPU spends doing actual gradient computation.
Performant robotics dataloaders need to handle multimodal alignment, variable sequence lengths, and efficient prefetching from compressed storage — all without becoming the bottleneck in your training loop. This is a hard engineering problem, and most teams solve it by building something 70% correct and living with the inefficiency. Teams running Knonik data infrastructure do not have this problem because the dataloader is built to understand robotics data natively, not as an afterthought bolted onto a vision training framework.
The market is figuring this out, slowly
If you look at how other ML verticals matured, the pattern is clear. NLP went through this exact cycle. The teams that won were not the ones with the most exotic architectures. They were the ones that built, or adopted, serious data infrastructure early. Annotation tools. Data versioning. Evaluation pipelines. Quality filtering. The tooling was boring. The results were not.
Robotics is roughly where NLP was in 2018. The models are getting good enough. The hardware is getting cheap enough. But the data infrastructure — the plumbing that connects raw experience to trained behavior — is still held together with duct tape at most companies. The teams that fix this first will have an unfair advantage for years.
This is exactly the thesis behind Knonik. Not another model. Not another simulator. A complete robotics data infrastructure solution: ingest, compress, score, process, and load — built specifically for the multimodal, variable frequency, high volume data that manipulation robotics produces. Because the frontier is not going to be won by the team with the best paper. It is going to be won by the team that can turn raw teleoperation into trained policies faster and cleaner than anyone else.
The unglamorous truth of robotics in 2026: your data pipeline is your competitive moat. Everything else is a commodity that is converging fast.
If you are spending more than 20% of your ML engineering time on data wrangling, you do not have a model problem. You have an infrastructure problem. And the longer you wait to fix it, the wider the gap gets between you and the teams that already have.