Why the bottleneck has moved from data to the loop behind it.
Every robotics team ends up building data infrastructure. The only question is when.
I have watched the same story play out enough times that I can tell it without naming anyone. A team gets a policy working in the lab. The demo lands, the pilot is signed, and suddenly the robot is running in someone else's building — generating hours of episodes a day that nobody planned for. Somewhere around the second deployment site, the questions start: which of these episodes should we train on? Why did last week's model update make the drawer task worse? What exactly do we need to collect next?
None of those are model questions. They are infrastructure questions. And the teams asking them usually realize they needed the answers a quarter ago.
The first bottleneck in robot learning was compute. That one is largely solved — you can rent the cluster.
The second was data, and here the field has made real progress. Web-scale video turned out to be a genuine head start: it can seed visual understanding and even certain skills. But reliable manipulation still has to be learned from high-quality demonstrations captured in physical environments, and that data mostly does not exist at scale.
What the last year has made clear is that the bottleneck has moved a third time — from data to the infrastructure behind it. Physical Intelligence's π-0.5 work put a number on why: in their scaling study, a model trained on data from only about 100 distinct environments approached the performance of a baseline trained directly on the test environment. Breadth of environment beats volume of hours. But notice what that finding actually demands: someone has to choose the hundred environments, track which ones are covered, and know which one to capture next. That is not a collection problem. It is an infrastructure problem wearing a collection problem's clothes.
Generalist's GEN-1.5 results sharpen the point to a needle.
Their model hits 59% (±10%) average success one-shot — from 3 to 12 seconds of a single demonstration, no training at all. With about 50 demonstrations — five minutes of data — and just 10 gradient steps, it reaches 83% (±9%). The fine-tuning changes less than 0.15% of the model's weights.
Read those numbers again. The knowledge is essentially already in the model. What separates 59% from 83% is five minutes of chosen data.
For years the industry framing has been "robot learning needs more data," and the instinctive response has been to scale collection. GEN-1.5 says something more uncomfortable and more interesting: as pretrained models get stronger, the marginal value of data concentrates violently into the few minutes that are selected well. Someone — or something — has to decide which five minutes deserve to exist. The teams treating that decision as infrastructure, with curation, quality gates and coverage analysis behind it, will get their 83%. The teams treating it as an afterthought will keep paying for hours and wondering why the model plateaus.
There is a second way well-meaning pipelines quietly destroy value: they optimize for clean data.
Most curation setups are built to delete imperfection. A demonstrator fumbles a grasp, a drawer jams, a mug slips — flag it, drop it, keep the corpus pristine. What survives is a highlight reel of flawless execution.
But a policy trained on highlight reels has never seen the moment that decides real-world reliability: the robot is already slightly off-distribution and has to find its way back. In deployment, that moment is not the edge case. It is the job. A fumbled grasp followed by a deliberate re-grasp carries information ten clean picks do not — what going wrong looks like from the inside, and the corrective action that undoes it.
The infrastructure implication: "data quality" cannot mean "nothing went wrong." A quality gate worth the name has to tell broken data — sensor dropout, sync drift, mislabeled frames — apart from good data about bad moments, and keep the failure→recovery arc as first-class structure: segmented, labeled, searchable. Delete your ugly episodes and you are optimizing the dataset for the demo and against the deployment.
Put those two lessons together and the shape of day-one infrastructure becomes clear. It is not a pipeline that runs left to right and ends at a training cluster. It is a loop:
Data Capture → Data Curation Pipeline (Cleaning, Annotation, Augmentation, QA, Deployment) → Closed-loop Feedback Engine (Failure Mining → Data Strategy Instruction) — and around again.
The part most teams are missing is the second half. When a model fails in evaluation or in the field, the valuable question is not whether it failed but why: was there not enough data, was scenario coverage too narrow, or is annotation bias poisoning the signal? Each cause demands a different fix, and only failure attribution turns a failure case into a collection instruction for the next round.
The field's own measurement tools show how underdeveloped this half is. A recent audit from TTI-Chicago, UChicago and Argonne — bluntly titled "What Are We Actually Benchmarking in Robot Manipulation?" — found that a 90-million-parameter model with no language encoding at all scores near state-of-the-art on LIBERO, and that only 19.8% of LIBERO state-of-the-art claims are provably significant from reported scores. Seventy-nine arXiv papers reported LIBERO results in March 2026 alone. Those are simulation benchmarks — but that is the point: even our cleanest, most controlled evaluations measure less than we think. Real-world evaluation, done with the rigor of a benchmark and closed back into collection, barely exists as a discipline yet. (Encouragingly, it is starting: UMI-Bench 1.0 is a first attempt at reproducible, auditable real-robot evaluation.)
This is not just a research observation. In my read of WRC 2026 in Beijing this month, what separated the mature exhibits from the demos was rarely the robot — it was the data operation behind it. The companies winning real contracts are the ones that can answer, with evidence, what their robot will do in an environment it has never seen — and that answer is manufactured by infrastructure, not by hope.
Nobody should build everything at once, and the teams I respect most don't. But there is a minimum set that is dramatically cheaper on day one than at scale.
It looks like this: every episode carries provenance — where, when, which task spec, which version of the world — so the corpus can be sliced and audited later. A quality gate stands in front of training, not behind it, deciding what enters the corpus and keeping failure-and-recovery arcs rather than deleting them. Every model version faces an evaluation that can catch a regression before a customer does. Failures get attributed to a cause — volume, coverage, or annotation bias — instead of being filed under "needs more data." And there is a standing, evidence-based answer to the question "what do we collect next?"
You do not need all of it on day one. You need to decide on day one which parts you will refuse to live without — because every one of them is an order of magnitude harder to retrofit under three live deployments than to build under zero.
I will show my cards: this is the layer I have bet my company on, because I kept meeting brilliant robotics teams paying the retrofit tax. But you do not need my product to act on the argument — you need the argument, before the second deployment site does the arguing for you.
So here is my question, and I genuinely want the answers: if you could hand your day-one self one piece of data infrastructure — provenance, a quality gate, real-world evals, failure attribution — which one, and why?