How many human demonstrations does it take to train a robot?
Fernando Flores can spend 8 hours a day pouring the same cup of coffee. He's not a barista. He's a robot teleoperator. His workday exists because humanoid robots need structured demonstration data before they can do anything useful in the real world. Thousands like him are being hired as Silicon Valley's humanoid systems scale toward commercial deployment, the Los Angeles Times reports. The story raises an implicit question. If a full workday of pouring still isn't enough, what does "enough" mean for a team building a deployable dataset?
TL;DR
Physical Intelligence collected 10,000 hours of demonstrations for a single foundation model.
Fine-tuning a pretrained VLA model can work with far fewer demos, if they're labeled precisely.
The bottleneck is grounding, not volume: raw motion data isn't robot supervision.
Diffusion policies improved on prior imitation learning baselines by 46.9 percent on manipulation tasks.
The teams reaching deployment fastest label fewer demos more precisely.
The gap between a research dataset and a deployable policy
Physical Intelligence collected 10,000 hours of human demonstration data to train their PI0 foundation model. That number has become the industry's reference point for what a real-world robotics dataset looks like at foundation-model scale. It is also the wrong target for almost every team working on a specific industrial task.
The reason is that training from scratch and fine-tuning a pretrained model are different problems with different data requirements. Training from scratch means the model has no prior understanding of physical interaction, object geometry, or force dynamics. Every hour of demonstration data has to teach the basics that a pretrained foundation model already carries. A 2026 analysis found that fine-tuning a pretrained foundation model produces a usable policy from far fewer demonstrations than training from scratch requires. The foundation model's prior data handles the generalization work that used to require task-specific engineering.
The gap between those two scales is the article's central tension. Training a robot for a specific task can take up to one month, a timeline that often slows the pace of commercial adoption. That barrier is real when teams are training from scratch. It collapses significantly when teams fine-tune a pretrained model on task-specific data. Labeling quality determines which scenario applies: whether those demonstrations let the model learn from grounded action signals or just raw motion data.
Why the number varies by orders of magnitude
The short version: more demonstrations do not automatically produce a better robot. A dataset of 50 well-labeled, varied demonstrations can outperform 500 unlabeled repetitions of the same motion path. The reason lies in how current policies learn.
Grounding is the missing variable
A 2026 survey of robotics training pipelines identified a structural problem. Beyond policy learning, teams lack mechanisms to convert unstructured behavioral data into grounded robot supervision. The pipeline is shifting from robot-data-centric (collect more robot demos) to grounding-centric (convert behavioral data into action supervision the model can use).
Grounding separates a raw video of a person pouring coffee from a training episode a robot policy can actually learn from. The same survey identifies four grounding interfaces a Vision-Language-Action (VLA) model requires. These are: data interfaces for autolabeling unstructured behavior, embodiment interfaces for retargeting human motion to robot actions, world-model interfaces for 3D reasoning grounded in physics, and reward interfaces. Teams that collect demonstrations without building these interfaces end up with an archive of raw motion capture and a policy that doesn't generalize.
Why diffusion policies exposed this gap
Diffusion policies outperformed prior imitation learning baselines by 46.9 percent across benchmark manipulation tasks, with the largest gains on tasks with multiple valid action sequences. That result matters here because it reveals what the older baselines were getting wrong. Unlabeled demonstrations of tasks with multiple valid solutions produce noisy action distributions. The model doesn't know which trajectory was intended. Diffusion policies handle that ambiguity by modeling the full distribution of possible actions. But they still require the training data to be labeled well enough to capture which sequences succeeded and which failed.
Heterogeneous pretraining makes the same point from a different direction. MIT research published in 2024 found that pooling data from different robots and sensor modalities into a shared representation outperformed single-task training by 20 percent. The gains held in both simulation and real-world tests. Labeling varied demonstration types outperformed stacking more repetitions of the same one. The model learned more from 100 well-labeled episodes drawn from varied tasks than from 500 identical repetitions of one.
How a teleoperator session becomes a training episode
What a session produces by default
When a teleoperator completes a task, the recording system captures a continuous motion sequence: joint angles, end-effector positions, camera frames, force sensor readings. That raw output is not yet a training episode. A training episode requires the sequence to be segmented into subtasks. Each frame must be classified by action phase (approach, grasp, transfer, release, set-down), and failure frames identified and flagged.
The gap between raw session and labeled episode is where most teams stop making progress, even as they collect more recordings. A team running 200 teleoperator sessions without a structured labeling workflow does not have 200 training episodes. It has 200 motion recordings of varying quality with no mechanism for the policy to distinguish a successful grasp from a recovery action.
Why labeling errors propagate to deployment
Hardware determines a robot's ceiling, according to McKinsey's robotics research. The trained software policy determines whether that ceiling is reached. The tight coupling between hardware and algorithm means a mislabeled subtask boundary in training surfaces as a failure mode in deployment. If the labeling workflow misclassifies a release phase as a grasp phase, the policy learns a sequence that cannot complete the task under real-world conditions.
Scaling teleoperator headcount scales recordings, not training data. Grounded supervision only follows when each session is converted into labeled, subtask-segmented episodes before training.
Three quality gates that determine whether your dataset is trainable
Three workflow stages determine whether your demonstration dataset produces a deployable policy or an archive of inconsistently labeled motion data.
Annotator onboarding gates. Before your annotators touch production data, run them through labeling tasks with known-correct ground-truth answers. Score each annotator against verified outcomes. Annotators who cannot reliably distinguish a grasp phase from an approach phase will introduce systematic noise regardless of how many episodes they label. The gate catches these errors before they introduce inconsistencies into your dataset.
Automated guardrails. During production labeling, automated checks should flag low-trust behavior. That includes annotations completed at implausible speeds, duplicate answers across similar frames, or consistent disagreement with other annotators on clear-cut cases. These signals don't always indicate bad intent. Annotator fatigue, unclear task instructions, and ambiguous video quality all produce similar patterns. Guardrails surface these signals for your reviewers, rather than automatically discarding the annotation.
Continuous ground-truth mixing. Rubric drift is the degradation of labeling consistency over time on a long-running project. Annotators interpret edge cases differently as weeks pass and the original task brief recedes. Mixing verified ground-truth tasks into your ongoing production streams lets reviewers monitor for drift and recalibrate before it affects a meaningful portion of your dataset.
HumanSignal's annotation quality workflow operationalizes all three gates: onboarding quizzes against verified tasks, automated plugins that flag low-trust behavior, and continuous ground-truth monitoring for rubric drift. For robotics-specific labeling, video frame classification lets annotators label each frame within an episode individually. Each frame gets classified by action phase, not a single label for the full clip, which makes subtask segmentation tractable at scale.
Putting a number on it
Teams fine-tuning a pretrained VLA model on a well-labeled dataset can reach deployment-grade performance with 50 to 200 demonstrations. The count depends on task complexity and the degrees of freedom involved. Teams collecting thousands of unlabeled episodes cannot reach that same performance regardless of session count. The final count follows from how well your labeling infrastructure works. It isn't a target you set before you start.
Three variables shape the range: pretrained model vs. from scratch, the task's degrees-of-freedom complexity, and labeling pipeline precision. Get the first two right and the third wrong, and the demonstrations don't transfer. Get the third right and the first two become more forgiving.
The decision variable you control
Fernando Flores pours the same cup of coffee hundreds of times. Repetition alone doesn't teach the robot anything. What teaches it is the labeling: which pour was clean, which was a recovery, and which was the failure the model should not reproduce. The teams reaching deployment fastest right now are labeling fewer demonstrations more precisely, with quality gates in place before a single episode enters training.