Robot AI's bottleneck is the boring data work

Language models got to learn from an internet full of text. Robots do not get that kind of free lunch. A robot needs trajectories, camera views, joint states, gripper state, calibration, timing, annotations, failed attempts, and enough variation that it can handle the mess of real objects.

That is the opening XDOF is chasing. TechCrunch reports that the startup has raised $70 million from Thrive Capital, Spark Capital, a16z, Lux, and WndrCo, and says it already has 20 customers including several frontier AI labs, though the company did not name them. The business is selling the part people underestimate: data pipelines, teleoperation systems, cleaning tools, annotations, and evaluation capacity that robot teams need before a model can learn useful physical behavior.

The public proof point is ABC-130K, released with UC Berkeley researchers. XDOF says it contains over 130,000 episodes across 195 bimanual manipulation tasks. The Hugging Face dataset card is more specific: 130,919 episodes, 3,598.2 hours, 43,090 annotated episodes, and 22.1 TB of files collected on two-arm YAM stations. That is not the same thing as a household robot that can fold your laundry tomorrow. It is closer to a flight recorder for robot learning, which is less exciting and much more useful.

NVIDIA is working the same layer from the tooling side. Its GTC Taipei announcement says physical AI tools and skills are now openly available through GitHub and skills.sh for use with any coding agent. The release spans Omniverse, Cosmos, Isaac, Metropolis, Alpamayo, Jetson, and other parts of NVIDIA's stack.

The important word is not open source. It is repeatable. NVIDIA describes skills that tell an agent which tools to call, what output to produce, and how a developer should validate the result. That matters because robot work has too many handoffs: generate synthetic data, build or import a scene, run simulation, train, evaluate, tune for edge hardware, then deploy somewhere that has bad lighting and humans walking through the path.

This does not prove general-purpose robots are solved. It proves the industry is starting to treat robot development as a set of runbooks that software agents can help execute and inspect. That is a narrower claim, and a better one.

The most concrete deployment story this week is Collaborative Robotics' Proxie Gen 2, announced at Automate 2026. The Robot Report says the new version adds greater payload capacity, self-swapping batteries, autonomous task identification, and an optional two-arm manipulation setup. Cobot says deployments begin this year and start at $5,000 per month.

The detail I care about is autotasking. Instead of requiring every job to come from a warehouse management system, hospital system, or human dispatcher, Proxie builds a model of the site and tries to infer when material is ready to move. At one Maersk-operated customer site, CEO Brad Porter told The Robot Report that workers wrote destination information on small whiteboards attached to carts, and Proxie used multimodal AI to read the whiteboards and create the movement tasks. He also said roughly 95% of cart movements in a measurement period were initiated without human assignment or warehouse-system integration.

Treat those as company-reported deployment claims, not independent proof. Still, the whiteboard example is a useful clue. A lot of real work runs on scraps of local context: signs, carts, labels, habits, the way one shift leaves things for the next. If robots need a six-month integration project before they can move a cart, they will stay trapped in pilot mode. If they can read the room without becoming mysterious, the buyer conversation changes.

The next good robotics demo should come with an operations sheet. How much site-specific data did the robot need before deployment? How many tasks did it infer correctly? How often did a person intervene? What counted as an intervention? Did it leave a cart, hallway, bench, or patient area in a better state than before? What happens when the sign is smudged, the cart is blocked, or the object moves between camera frames?

Those questions sound dull because they are close to the work. That is the point. A hospital does not need a robot that wins a clip contest and then creates one more thing for nurses to babysit. A warehouse does not need AI that moves the easy carts and leaves the edge cases to whoever is already behind. The product has to return time after the launch week, when the visitors are gone and the night shift still needs the supplies moved.

This is where the data layer, agent tools, and deployment story meet. Data trains the behavior. Skills make development less artisanal. Field metrics tell you whether the robot is saving people time or quietly moving the burden somewhere else.

Ren Ortiz likes the whiteboard detail because it makes the robot meet the workplace where it already is. His caution is physical: the robot should show a before frame, selected task, stop condition, and after frame before anyone trusts the next move.

Priya Rao wants the comparison table. Assigned tasks versus self-identified tasks, interventions per shift, blocked-path recoveries, damage or near-miss reports, reroutes, reset time, and how often a human had to clean up after a technically successful run.

Mina Torres is thinking about the person sharing the hallway. If a robot is moving through a hospital or warehouse, it should explain itself in normal words: where it is going, why it stopped, and who to call. The fancy model can stay hidden. The next safe step should not.