In 2026 the benchmark everyone in embodied AI actually watches isn't a leaderboard score. It's whether a robot can walk into a kitchen it has never seen, clear the table, load the dishwasher, and wipe the counters — without a script, without a human quietly steering from another room. That's close to the exact task Physical Intelligence built its π0.5 model to attempt: a mobile manipulator cleaning kitchens and bedrooms in new homes absent from its training data, executing multi-stage routines that run ten to fifteen minutes1.
Ten to fifteen minutes sounds unimpressive until you compare it to what actually goes viral. Most robot clips that circulate on Twitter are ten to fifteen seconds — a single skill, one pour, one fold, one pick — because a single skill is what today's models reliably do. A long-horizon chore is a different problem: dozens of correct decisions in sequence, clutter that's never arranged the same way twice, a dropped plate that has to be recovered from rather than fatal to the run. One wrong action in minute nine can erase eight minutes of otherwise flawless behavior. That gap — between a skill and a chore — is where most embodied AI roadmaps quietly stall.
The industry's reflexive explanation is that the gap will close with a bigger, better model. That's not wrong, but it's an incomplete frame. Treat it as a modeling problem and you'll keep shipping impressive single-skill demos. Treat it as a systems engineering problem — one where the model is a single stage in a much longer loop — and you start asking the questions that actually determine whether a robot can hold a chore together for ten minutes in someone else's kitchen.
01The chore that breaks the demo
Every long-horizon failure we've seen traces back to a stage that got starved, not a model that got outsmarted: a data pipeline that never saw enough cluttered kitchens, a post-training run with no real recovery examples, a safety layer that vetoes the one action that would have saved the run, an onboard chip too slow to replan before the plate hits the floor. The model is real. It's also the easiest of the six stages to point a camera at, which is exactly why it gets credited — or blamed — for problems that live somewhere else in the loop.
02The loop, not the model
Strip the marketing language out of every serious embodied AI effort and the same six-stage loop shows up underneath, whether the team calls it that or not.
Data collection is closer to a logistics operation than a research project. Physical Intelligence's base model was trained across seven robot platforms and sixty-eight tasks before it ever generalized to a new home1. 1X runs it as a live service: human teleoperators complete real household tasks through NEO robots today, and every one of those sessions is recorded, labeled demonstration data for tomorrow's autonomy2. Figure treats its own hardware line the same way — every humanoid that rolls off the BotQ manufacturing floor is, by design, also a data-collection node3.
Pretraining is where cross-embodiment, cross-task data gets turned into a general policy — π0.5's architecture explicitly folds in data from other robots, high-level subtask labels, verbal instructions, and web data specifically to generalize past what any one home or one robot saw during training1. Post-training is the cheap-looking part that only stays cheap because the expensive part already happened: Google DeepMind's on-device Gemini Robotics model can reportedly be fine-tuned for a new task with as few as fifty to one hundred demonstrations — but only because a much larger base model already carries the general competence that small fine-tune is specializing4.
Deployment is a real-time constraint problem as much as an intelligence problem: whatever runs onboard has to plan, act, and replan inside a robot's actual power and compute envelope, which is why an on-device model line exists as its own product rather than a compressed afterthought4. Feedback is what turns a deployed fleet back into training signal — failures, near-misses, and teleoperator interventions logged and routed back to stage one. Skip that stage and you have a static model that never improves after ship day, no matter how good stage two was.
03Where it actually breaks
The loop doesn't fail because one stage is missing a breakthrough. It fails because the six stages depend on each other, and a limitation in one silently caps what the others can achieve.
| Stage | What it actually is | What starves it |
|---|---|---|
| Data | An operations problem — fleets of teleoperators or deployed robots generating labeled demonstrations | Too few real environments; data that's clean because it was staged, not lived-in |
| Pretraining | A compute and architecture problem — folding heterogeneous embodiments and tasks into one general policy | Data that's abundant but narrow — many hours of one task, not many tasks |
| Post-training | An RL and fine-tuning problem — specializing a general policy to a task or environment | A weak base model, so every deployment needs full retraining instead of a light touch |
| Deployment | A hardware and latency problem — planning and acting inside real power/compute limits | A model too heavy to run onboard in real time, however good it is offline |
| Feedback | A telemetry and ops problem — capturing failures and routing them back to training | No mechanism to close the loop, so the model never learns from its own deployment |
| Safety | A reasoning problem that sits across every other stage, vetoing actions before they execute | Safety bolted on after the fact instead of architected as its own layer |
Hardware decides what data can even be collected in the first place — you cannot label proprioceptive feedback a sensor never captured, which is the practical reason Figure chose to manufacture its own robots at scale rather than wait for enough third-party units to exist3. Safety decides what an RL policy is even allowed to try: you cannot let a home robot explore its action space by trial and error the way a game-playing agent does, which is why Gemini Robotics is built with an explicit reasoning layer that evaluates actions for safety before they execute, rather than hoping safety emerges from scale alone4. Neither problem is solved by a bigger transformer. Both are solved by treating them as first-class engineering disciplines with their own teams, their own failure modes, and their own budgets.
"A model that's brilliant in evaluation and unsafe in deployment isn't a smaller version of the problem. It's a different problem, being scored on the wrong axis."Lambda Robotics — Research
04The flywheel needs a business
Closing this loop once is a research result. Closing it repeatedly, at the pace competitors are closing it, costs real money — teleoperator hours, compute, hardware iteration, fleet maintenance — and that money has to come from somewhere more durable than a funding round timed to a demo video. The teams making visible progress on long-horizon tasks all made the same bet: anchor the loop in a real commercial scenario that pays for it to keep turning.
1X is explicit about this. Teleoperation isn't a stopgap while they wait for autonomy — it's the current business model, generating subscription revenue today while every session doubles as training data for tomorrow. As CEO Bernt Børnich has put it, if they don't have your data, they can't make the product better2. Figure's logic runs the same direction from the hardware side: more deployed units generate more data, which makes the model better, which justifies deploying more units — a flywheel that only turns because actual commercial pilots, not internal test rigs, are generating the usage3. And outside humanoids entirely, Amazon's DeepFleet model was trained on real operational data from the more than a million robots already working its warehouses — the least glamorous deployment in this entire essay, and the one with the largest, least curated dataset behind it5.
The common thread is that none of this data comes from a demo performed for a camera. Curated demos produce curated data — clean lighting, cooperative objects, no real stakes if a run fails. The data that actually improves a long-horizon model — the dropped plate, the rearranged kitchen, the customer who moved the furniture — only shows up when a real customer with a real incentive is depending on the system and something goes wrong. Autonomous driving learned this a decade earlier: the value of a fleet's data was never a function of test-track laps, it was a function of real trips, driven for real reasons, by people who needed to get somewhere. Embodied AI is relearning the same lesson at the scale of a kitchen instead of a highway.
05The thesis
Nobody is going to announce a model that single-handedly makes embodied intelligence work. It's going to get assembled — stage by stage, discipline by discipline — by teams willing to treat data pipelines, simulation, RL, hardware, deployment, and safety as equally load-bearing, and willing to find a real commercial scenario patient enough to fund the loop before the model is impressive enough to trend on its own.
That's the bet we're making too: pick the deployment that generates real, high-value, unglamorous data before you chase the demo that generates attention. The loop compounds either way. Only one version of it is still running in five years.
"The robots that matter are the ones you never notice."Lambda Robotics
- Physical Intelligence, "π0.5: a Vision-Language-Action Model with Open-World Generalization" — pi.website/blog/pi05
- 1X Technologies NEO home deployment and teleoperation-to-autonomy strategy — humansareobsolete.com
- Figure AI, BotQ manufacturing scale-up and the Helix data flywheel — ai2.work
- Google DeepMind, "Gemini Robotics On-Device brings AI to local robotic devices" — deepmind.google
- Amazon, "Amazon deploys its one millionth robot" — aboutamazon.com