Imitation Learning for Robotics: The Ultimate Guide

A person picks up a teleoperation rig, drives a robot arm through fifty pick-and-place cycles, and an hour later a neural network flies the same arm through the task on its own. No reward function, no simulator, no state machine. The network watched what the human did and copied it. This is the shortest path from "a human can do this task" to "a robot does this task," and in 2026 it is the dominant way real manipulation policies get built. The last three years of robot learning (ACT, diffusion policies, the vision-language-action models, the big teleoperation datasets) all sit on top of one deceptively simple idea: turn demonstrations into a policy by supervised learning.

This guide is the long version for the people building those systems: the manipulation engineer who can collect demonstrations but keeps hitting a policy that drifts and fails halfway through a task, the ML person who knows supervised learning cold but not why it behaves so strangely in a control loop, and the maker who has read the ACT and diffusion-policy papers and wants the recipe and the failure modes. We go end to end: the math of behavior cloning and the precise reason its errors compound, DAgger and the interactive fix, how demonstrations actually get collected (teleop, kinesthetic, play data), the modern policy architectures (action chunking, diffusion, flow matching) and what problem each one solves, why multimodal demonstrations break naive regression, when imitation beats reinforcement learning and how the two combine, data efficiency and scaling, evaluation, and what breaks in real deployments.

The take: Imitation learning converts the human skill of doing a task into a policy, and it wins whenever demonstrations are cheaper to get than a reward function is to design. Its central problem is what happens between the demonstrations: a policy that makes a small error drifts into states no demonstrator ever visited, and with nothing to imitate there it compounds. Every serious method (DAgger, action chunking, diffusion policies, RL fine-tuning) is a different answer to that one problem. The 2026 frontier is data (how you collect it, how much you need, how it transfers across robots) far more than the loss function.

Companion reading: reinforcement learning for robotics, foundation models & VLA for robotics, robot teleoperation, robot simulation & digital twins, and end-effectors & grippers.

Table of contents

1. Key takeaways
2. What imitation learning is, and when to reach for it
3. Behavior cloning: the math
4. Why errors compound: covariate shift
5. DAgger and the interactive fix
6. Collecting demonstrations: teleop, kinesthetic, play
7. Multimodality: why naive regression collapses
8. Action chunking and ACT
9. Diffusion and flow-matching policies
10. Imitation vs reinforcement learning, and how they combine
11. Data efficiency and scaling
12. Evaluation
13. Real deployments and failure modes
14. Frequently asked questions

What imitation learning is, and when to reach for it

Imitation learning is the family of methods that produce a control policy from demonstrations of the desired behavior. You give the system examples of an expert (usually a human, sometimes a scripted controller or an optimal planner) doing the task, and it learns to reproduce the mapping from what the robot senses to what the expert did.

The reason it matters is a specification problem. Reinforcement learning needs a reward function: a scalar that says how good every state and action is. For many tasks that reward is genuinely hard to write. Consider "fold this shirt," "plug in this connector," "wipe the spill." Encoding those as a dense reward that an optimizer cannot game is a research project on its own, and see the reward-hacking section of the RL guide for how badly that goes when you get it wrong. But showing the task once is trivial. A human picks up a teleop rig and does it. Imitation learning trades the hard problem of specifying a reward for the easy problem of providing demonstrations.

That trade is the whole decision rule. Reach for imitation when the task is easy to demonstrate and hard to reward, when you have (or can cheaply collect) demonstrations, and when the behavior you want is roughly what a human would do. Reach for RL instead when demonstrations are impossible, dangerous, or unnatural to collect (a robot moving faster than a human can teleoperate, a gait no human can perform) and a reward is writable. Most of 2026 tabletop manipulation lands on the imitation side; most legged locomotion lands on the RL side, and the two meet in the middle for the hardest problems.

Rule of thumb: If you can teleoperate the task yourself in a few minutes, start with imitation learning. If you cannot demonstrate it but you can write down what "good" means, start with RL.

Behavior cloning: the math

Behavior cloning (BC) is the simplest imitation method and the base case for everything else. Frame it as supervised learning. You have a dataset of demonstrations, each a trajectory of observation-action pairs generated by an expert policy π*:

D = { (o_1, a_1), (o_2, a_2), ... , (o_N, a_N) }

where each a_i is the action the expert took (a target end-effector pose, a joint-position target, a gripper command) given observation o_i (camera images, proprioception). You fit a policy π_θ(a | o) to predict the expert's action. The objective is straightforward supervised learning:

θ* = argmin_θ  E_{(o,a) ~ D} [ L( π_θ(o), a ) ]

For a continuous action space the loss L is often mean-squared error if the policy outputs a single action, or a negative log-likelihood if it outputs a distribution:

# Deterministic head, regression:
L_MSE = || π_θ(o) - a ||^2

# Probabilistic head, maximum likelihood:
L_NLL = - log π_θ(a | o)

Written as maximum likelihood, BC is minimizing the KL divergence between the expert's action distribution and the policy's, averaged over the expert's state distribution d_{π*}:

θ* = argmin_θ  E_{o ~ d_{π*}} [ D_KL( π*(·|o)  ||  π_θ(·|o) ) ]

Notice the state distribution in that expectation. It is d_{π*}, the distribution of states the expert visits. That single detail is the seed of the whole problem, and the next section is entirely about it.

Mechanically, BC is appealing. It is stable, it trains fast, it needs no simulator, no reward, and no interaction with the environment during training. It is offline supervised learning, so all the standard machinery (data augmentation, dropout, learning-rate schedules, large-batch training) applies directly. If you have clean demonstrations and the deployment states stay close to the demonstrated ones, BC alone can be an excellent policy. The trouble starts when the robot leaves the states the expert showed it.

Why errors compound: covariate shift

Here is the central pathology of imitation learning, and the reason it behaves differently from ordinary supervised learning with a robot attached.

Supervised learning assumes the training and test data are drawn from the same distribution. BC violates that assumption the moment you deploy. At training time the states come from the expert's distribution d_{π*}. At test time the states come from the policy's own distribution d_{π_θ}, because the policy's actions determine where it goes next. The two distributions are different, and the gap between them is called covariate shift.

The mechanism is a feedback loop. The policy is trained to be accurate on expert states. It makes a small prediction error, which moves the robot to a state slightly off the expert's trajectory. That state is a little out of distribution, so the policy is a little less accurate there, so it makes a larger error, which moves it further off distribution. Errors do not average out. They accumulate, and the policy walks itself into states no demonstrator ever visited, where it has learned nothing and behaves arbitrarily. A pick-and-place policy drifts a centimeter, then the object is at an angle it never saw, then the gripper is somewhere off the table.

The theory makes the scaling precise. Suppose the policy makes a mistake with probability at most ε on states drawn from the expert distribution (its expected 0-1 loss under d_{π*} is ε). For a task of horizon T steps, the classic result (Ross and Bagnell, 2010) is that the expected total cost of the behavior-cloned policy grows as:

J(π_θ)  -  J(π*)   ≤   O( ε · T^2 )

The T^2 is the whole story. A policy whose per-step error is tiny still accumulates cost quadratically in the horizon, because each mistake compounds the chance of the next one over the remaining steps. Contrast this with a policy trained on its own distribution (the DAgger guarantee below), where the bound is linear, O(ε T). That gap between quadratic and linear is exactly the cost of the distribution mismatch. On a 10-step task the difference is mild; on a 500-step manipulation task it is the difference between a policy that works and one that falls apart two-thirds of the way through, which is precisely the failure practitioners see.

War story: A team collects a hundred clean teleoperated demonstrations of a connector-insertion task and trains a behavior-cloning policy that reaches 98 percent action-prediction accuracy on the held-out demonstrations. On the real robot it succeeds maybe one time in five. Watching the rollouts, the approach and grasp are perfect, then a millimeter of drift near the socket puts the plug at an angle the demonstrations never contained, and from there the policy has no idea and jams the connector sideways. Nothing was wrong with the fit. The 98 percent was measured on the expert's states. The robot was failing on its own.

Everything that follows is an attempt to break this loop: relabel the policy's own states (DAgger), act in chunks so there are fewer decision points to compound (ACT), model the full action distribution so the policy stays decisive off-manifold (diffusion), or add reward so the policy can recover from states no demonstration covered (RL fine-tuning).

DAgger and the interactive fix

The cleanest solution to covariate shift is to make the training distribution match the deployment distribution. If the policy is going to be tested on the states it visits, train it on those states. That is DAgger (Dataset Aggregation, Ross, Gordon, and Bagnell, 2011).

DAgger is an iterative loop:

D <- demonstrations from the expert          # initial dataset
π <- train on D
repeat:
    roll out π in the real environment        # collect states π actually visits
    for each visited state o:
        query the expert for the correct action a* = π*(o)
    D <- D  ∪  { (o, a*) }                     # aggregate
    π <- retrain on the aggregated D

The idea is to let the current policy drive, watch where it goes (including its mistakes), and have the expert say what should have been done in exactly those states. Over iterations the dataset comes to cover the policy's own state distribution, including the off-manifold states BC never saw, and the compounding-error loop is broken at its source. The theoretical payoff is the linear bound: DAgger achieves O(ε T) cost instead of BC's O(ε T^2), because the policy is now trained and tested on the same distribution.

The catch is the expert query. DAgger needs an expert you can ask "what is the right action here," in states the expert would never have chosen to be in. When the expert is an algorithm (an MPC controller, an optimal planner, a privileged-information teacher in simulation) this is easy, and DAgger-style distillation is exactly the teacher-student recipe used in legged locomotion. When the expert is a human, it is awkward and unnatural. A person asked to label the correct action for a robot that has wandered into a strange state, without themselves being in control, gives noisy and inconsistent answers.

Human-friendly variants soften this. HG-DAgger and related interactive methods have the human take over the controls only when the policy is about to fail, providing corrective demonstrations exactly where the policy is weak, which is both more natural and more sample-efficient than labeling every state. This intervention-based data collection is common in modern manipulation pipelines: deploy the policy, let a human teleoperator grab control when it drifts, and fold those interventions back into training. It is DAgger with an ergonomic front end.

Rule of thumb: If your expert is a piece of software you can query anywhere, use DAgger and stop worrying about covariate shift. If your expert is a human, use intervention-based collection: run the policy, take over when it fails, retrain on the takeovers.

Collecting demonstrations: teleop, kinesthetic, play

Imitation learning is only as good as its demonstrations, so how you collect them is a first-class design decision, not a detail. Three families dominate, with different cost, quality, and scaling properties.

Teleoperation is the workhorse. A human operates the robot remotely through some interface (a spacemouse, a VR controller, a leader arm that the follower arm mirrors, a handheld gripper instrumented with cameras) while the robot's sensors record the observations and the commanded actions. Teleop gives clean, correctly-embodied action labels: the recorded action is exactly what the robot did, in the robot's own action space, seen through the robot's own cameras. Its weakness is throughput and hardware. Good teleop needs low latency and enough degrees of freedom to be natural, and even then a human collects demonstrations in real time, one at a time. Low-cost bimanual leader-follower rigs (the ALOHA and mobile-ALOHA systems from Stanford, and the many designs that followed) drove a wave of manipulation results precisely by making teleop cheap and ergonomic. See robot teleoperation for the interface side of this.

Kinesthetic teaching skips the interface: a human physically grabs the robot and moves it through the task while the joint encoders record the trajectory. It is the cheapest possible method and needs no teleop hardware. Its limits are real. It only works on backdrivable, gravity-compensated arms that a person can move by hand (many industrial arms are not), the human's body occludes the cameras and stands in a viewpoint the deployed robot will not have, and you cannot easily kinesthetically teach a moving base or a fast dynamic motion. It shines for slow, quasi-static arm tasks on collaborative hardware, and see collaborative robots (cobots) for the arms built to be moved this way.

Play data is unstructured, task-agnostic interaction: a human teleoperates the robot to just mess around in an environment, touching, pushing, and rearranging objects with no particular goal. There are no task labels. The value is coverage and scale: play data visits a huge diversity of states cheaply, exactly the off-manifold states that trip up narrow single-task datasets. To use it you condition the policy on a goal (a goal image, a language instruction, or a learned latent) and train it to reach that goal, relabeling each visited state as a valid goal that the preceding actions achieved (hindsight relabeling). The "learning from play" line of work (Lynch and collaborators) showed a single goal-conditioned policy trained on play data performing many tasks without any per-task demonstrations.

Method	Action label quality	Throughput	Hardware needed	Best for
Teleoperation	High, correctly embodied	Low (real-time, one at a time)	Teleop rig (VR, leader arm, spacemouse)	Precise single or multi-task manipulation
Kinesthetic	Medium (no camera-consistent view)	Medium	Backdrivable, gravity-comp arm	Slow quasi-static arm tasks on cobots
Play data	Weak per-step, strong coverage	High (unstructured)	Teleop rig	Broad goal-conditioned policies, pretraining

A recurring theme cuts across all three: the embodiment gap. Data collected on one robot, or from human video, is in a different action space and viewpoint than the robot you deploy on. Human hands are not robot grippers, a leader arm is not the follower, and a phone-mounted gripper is not the mounted arm. Correcting for that gap (retargeting human motion to robot joints, aligning viewpoints, learning embodiment-invariant representations) is one of the hardest and most active parts of scaling demonstration data.

Multimodality: why naive regression collapses

Human demonstrations have a property that quietly breaks the simplest version of behavior cloning: they are multimodal. For the same observation, a human will legitimately choose different actions on different demonstrations. Going around an obstacle, some demonstrations go left and some go right. Both are correct. Approaching a mug, one demonstration grasps the handle, another grasps the rim.

Now train a policy with mean-squared-error regression on that data. MSE is minimized by predicting the mean of the target actions for a given observation. The mean of "go left" and "go right" is "go straight," which drives directly into the obstacle. The mean of "grasp the handle" and "grasp the rim" is a point in empty space between them. Averaging valid modes produces an invalid action. This is not a fitting failure you can fix with more data or a bigger network; more multimodal data makes it worse, because the regression target is the average and the average is wrong.

The fix is to stop predicting a single action and instead model the distribution over actions, π_θ(a | o), so the policy can represent "left OR right" and commit to one mode rather than blending them. The design question becomes which distributional model to use, and this is precisely the axis along which the modern architectures differ:

• Discretization. Chop each action dimension into bins and predict a categorical distribution over bins (as autoregressive transformer policies and some VLAs do). A categorical head represents multiple modes natively. The cost is quantization error and the awkwardness of discretizing a continuous, correlated action vector.
• Mixtures. Predict a mixture of Gaussians (a mixture density network). Each component can capture a mode. It works but is finicky to train and struggles as the number of modes grows.
• Latent-variable / generative models. Model the action distribution implicitly with a generative model: a conditional VAE (used in ACT), a diffusion model (diffusion policies), or flow matching. These represent arbitrarily complex multimodal distributions and are the dominant choice in 2026.

Rule of thumb: The moment your demonstrations contain more than one valid way to do something, a mean-squared-error policy will average the ways together and fail. If you see a policy confidently doing the "in-between" action that no demonstration ever showed, multimodality is your bug.

Action chunking and ACT

Action Chunking with Transformers (ACT), from the ALOHA work (Zhao and collaborators, 2023), attacks compounding error from a different angle than DAgger, and it does so without needing an interactive expert.

The core idea is action chunking: instead of predicting one action per observation and re-deciding every timestep, the policy predicts a chunk of the next k actions at once (typically k around 10 to 100 depending on control rate) and executes them open-loop before predicting the next chunk. Two things improve. First, the number of decision points drops by a factor of k, and since compounding error accrues per decision, fewer decisions means less accumulation over a task. Second, chunking sidesteps a subtle pathology of human demonstrations: pauses and hesitations. When a human pauses, the demonstrated action is near-zero for several steps, and a per-step policy that mispredicts these produces jittery, indecisive behavior. Predicting a temporally-extended chunk smooths through this.

ACT adds two more pieces that matter in practice. It wraps the policy in a conditional VAE so the action-sequence decoder is conditioned on a latent variable, letting it model the multimodality of human demonstrations rather than regressing to the mean. And it uses temporal ensembling at inference: because chunks predicted at successive timesteps overlap, ACT runs the policy every step and averages the multiple predictions that exist for each future action, which smooths the executed trajectory and recovers some of the closed-loop reactivity that pure open-loop chunk execution gives up.

The tension in chunking is open-loop versus reactive. A long chunk reduces compounding error and smooths motion but commits the robot to a stale plan: if the object moves mid-chunk, the policy cannot react until the chunk ends. A short chunk stays reactive but recovers less of the benefit. Temporal ensembling is ACT's compromise. In practice ACT and its descendants made fine, contact-rich bimanual tasks (threading a zip tie, inserting a battery, manipulating a deformable) work from a few tens of demonstrations, which is why action chunking became a standard ingredient across imitation policies, including the action heads of several vision-language-action models. See foundation models & VLA for robotics.

Diffusion and flow-matching policies

The other workhorse architecture of 2026 borrows the generative model behind image synthesis. A diffusion policy (Chi and collaborators, 2023) represents the action distribution π_θ(a | o) implicitly, as the endpoint of a learned denoising process, and this turns out to be an unusually good fit for the demands of manipulation.

The mechanism: to sample an action (or action chunk), start from pure Gaussian noise and iteratively denoise it, conditioned on the observation, until it becomes a clean action. Training reverses the process. Take a demonstrated action, add a known amount of noise, and train a network to predict the noise (equivalently, the denoising step) that removes it. At inference you run the reverse chain:

a_K ~ N(0, I)                                  # start from noise
for k = K ... 1:
    a_{k-1} = a_k  -  γ · ε_θ(a_k, o, k)  +  noise    # denoise, conditioned on o
return a_0                                      # a clean action (chunk)

Why this works so well for robots comes down to three properties. First, diffusion models represent multimodal distributions natively: different noise seeds denoise to different modes, so "left" and "right" are both reachable and the policy never averages them. Second, they express complex, high-dimensional, correlated action distributions (a diffusion policy predicts a whole action chunk jointly, capturing the correlations between successive actions and between joints). Third, they train stably by a simple regression-to-noise loss, avoiding the mode-collapse and instability that plague GANs and the tuning pain of mixture density networks. Diffusion policies set strong results on contact-rich, high-precision tasks where the multimodality and precision both matter.

The cost is inference. A naive diffusion policy runs many denoising steps (tens to a hundred) per action, which is expensive inside a control loop. The practical fixes are the same ones the image world developed: fewer, larger denoising steps via better samplers (DDIM), and consistency or distillation methods that collapse the chain to one or a few steps. Flow matching is the closely related successor gaining ground: it learns a continuous velocity field that transports noise to data along a straighter path, which needs far fewer integration steps than diffusion for comparable quality, and it underlies the action heads of several 2026 VLA models (the pi-series policies among them).

Architecture	Multimodality	Inference cost	Strength
MSE regression	None (averages modes)	Cheapest	Simple unimodal tasks only
ACT (CVAE + chunking)	Moderate (via latent)	Low	Fine bimanual tasks, few demos, smooth motion
Diffusion policy	Strong (native)	High (many denoise steps)	Contact-rich, high-precision, multimodal
Flow matching	Strong (native)	Medium (few steps)	Diffusion quality at lower latency; VLA action heads

Rule of thumb: If your task is unimodal and simple, regression is fine and fastest. If it is multimodal and you want proven robustness on contact-rich manipulation, reach for a diffusion or flow-matching policy and budget for the inference cost. ACT sits in between and is a strong default for fine bimanual work from small datasets.

Imitation vs reinforcement learning, and how they combine

Imitation and RL are the two ways to get a policy without hand-coding it, and they fail in opposite places, which is exactly why they combine so well.

Imitation needs demonstrations but no reward. It is stable, sample-efficient in environment interactions (it needs zero, the data is offline), and it produces natural, human-like behavior. Its ceiling is the demonstrator: a behavior-cloned policy is at best as good as the demonstrations, and it inherits their gaps, so it cannot discover a better strategy or recover from states the demonstrator never entered. RL needs a reward but no demonstrations. It can exceed human performance and discover behavior no one showed it, and it can learn recovery from any state its exploration reaches. Its costs are the reward-specification problem, sample inefficiency, and unstable, unsafe exploration.

Dimension	Imitation learning	Reinforcement learning
Needs	Demonstrations	A reward function
Environment interaction	None (offline)	Extensive (online rollouts)
Performance ceiling	The demonstrator	Can exceed humans
Recovery / robustness	Poor (only demonstrated states)	Good (explores off-manifold)
Exploration risk	None	High (flailing policy)
Behavior style	Natural, human-like	Whatever maximizes reward
Main failure mode	Compounding error	Reward hacking

The complementary structure writes itself, and the strongest 2026 stacks use both:

• Imitation to bootstrap, RL to refine. Behavior-clone a competent policy from demonstrations, then fine-tune with RL to add robustness and push past the demonstrator. The BC warm start solves RL's exploration problem (the policy starts in a sensible region instead of flailing), and the RL phase solves imitation's recovery problem. This is the dominant recipe when a reward is available.
• Demonstrations as a reward signal. When you cannot write a reward but you have demonstrations, infer one. Inverse reinforcement learning recovers a reward function that explains the demonstrations, and adversarial imitation (GAIL, and for robots adversarial motion priors) trains a discriminator to tell policy behavior from demonstration behavior and rewards the policy for fooling it, which sidesteps compounding error by using RL's on-policy rollouts. Motion-capture-referenced humanoid gaits are exactly this: demonstrations set the style, RL makes it robust.
• Offline RL as the bridge. When you have demonstrations and logged rewards but cannot safely interact, offline RL learns from the fixed dataset while staying close to the demonstrated actions, getting some of RL's improvement without online exploration.

Rule of thumb: Use imitation to get into the right neighborhood cheaply, use RL to make it robust and push past the demonstrator. Pure behavior cloning rarely survives the real distribution shift; pure from-scratch RL wastes enormous exploration on states a demonstration could have handed you for free. See the RL guide for the other half of this.

Data efficiency and scaling

The practical question every team asks is "how many demonstrations do I need," and the honest answer is that it depends on task difficulty, the variability you need to cover, and the architecture, but the ranges are known.

For a narrow single task with a modern architecture (ACT, diffusion policy), useful policies come from surprisingly little: often 50 to 300 demonstrations. The strong inductive bias of chunking and the distributional action model do a lot of work. The number climbs fast with the variation you need to handle. Ten fixed object positions need far fewer demonstrations than "any position, any lighting, any distractor clutter," because the policy has to see enough of that variation to interpolate across it. A useful mental model: demonstrations must cover the product of the variations the policy must generalize over, which is why coverage, not raw count, is the real currency.

The other regime is broad, multi-task, cross-robot policies, and here the field went the way of language models: scale the data. The Open X-Embodiment dataset (2023) pooled demonstrations from many labs and robot types into over a million trajectories, and training on it produced policies (RT-X) that transferred across embodiments and generalized better than single-robot training. DROID added a large, diverse in-the-wild manipulation dataset. These corpora underpin the vision-language-action models (RT-2, OpenVLA, Octo, the pi-series) that pretrain on huge robot and web data and then need only a handful of demonstrations to fine-tune to a new task. See foundation models & VLA for robotics for that thread in full.

Three levers stretch a demonstration budget:

• Simulation and synthetic demonstrations. Generate demonstrations in sim with a scripted or optimal expert, or augment real demonstrations with sim variation. This trades the sim-to-real gap (see sim-to-real and robot simulation) for near-free data.
• Data augmentation. Image augmentation (crops, color jitter, and especially inpainting distractor objects or backgrounds) makes a fixed set of demonstrations cover more visual variation without collecting more.
• Pretraining and transfer. Fine-tune from a policy pretrained on a large cross-embodiment corpus rather than training from scratch, which is the single biggest data multiplier available in 2026.

Rule of thumb: Budget demonstrations to cover the variation you need to generalize over, not the task itself. A hundred demonstrations at one object pose teaches one pose well; the same hundred spread across poses, lighting, and clutter teaches a policy that works.

Evaluation

Evaluating an imitation policy is harder than it looks, and getting it wrong wastes weeks. The trap is that the natural offline metric barely predicts the thing you care about.

Validation loss lies. Low action-prediction error on held-out demonstrations does not imply high task success. The connector story above had 98 percent action accuracy and 20 percent task success. The reasons are exactly the ones this guide has been building toward: the validation set is drawn from the expert's state distribution, not the policy's, so it never measures the off-manifold behavior that decides real rollouts, and a small per-step error that looks negligible offline compounds catastrophically online. Track validation loss to catch gross training failures, but never trust it as the success predictor.

Success rate on real rollouts is the metric. You run the policy on the physical robot many times, from randomized initial conditions (object poses, distractors, lighting), and count the fraction that succeed. This is expensive (each trial is a real-time physical rollout with a human to reset the scene) which is why teams under-evaluate and then over-trust noisy numbers.

The statistics matter. Success rate is a binomial proportion, and with small trial counts its confidence interval is wide. Twenty trials at 15 successes is a 75 percent success rate with a 95 percent confidence interval running roughly from 53 to 90 percent, which is nearly useless for concluding that policy A beats policy B. Comparing two policies on 20 trials each and declaring the 80 percent one better than the 70 percent one is measuring noise. You need enough trials (often 50 or more per condition) for the intervals to separate, matched initial conditions across the policies you compare, and honest reporting of the full interval alongside the point estimate. The 2024-2025 push toward standardized real-robot evaluation protocols and shared benchmarks came directly out of this reproducibility problem.

Rule of thumb: Report success rate with a confidence interval, over enough trials that the interval is tight enough to support your claim, from randomized initial conditions matched across the policies you compare. A point estimate from 20 trials is a rumor, not a result.

Real deployments and failure modes

Imitation-learned policies run in real production systems in 2026: warehouse picking and induction, kit assembly, machine tending, food and lab handling, and the manipulation stacks of the humanoid programs. The tasks that suit imitation share a profile: relatively short-horizon, human-demonstratable, high in perceptual and contact complexity but not demanding superhuman speed or precision beyond what a teleoperator can achieve. See warehouse & logistics robotics for where this lands at scale, and end-effectors & grippers for the hardware the policy actually commands.

The failure modes cluster, and knowing them shortens debugging:

• Compounding-error drift is the signature failure, covered at length above. The approach is fine and the policy falls apart mid-task. Fixes: action chunking, intervention-based data collection on the failure states, or RL fine-tuning.
• Multimodal averaging. The policy confidently does an in-between action no demonstration showed (drives at the obstacle, grasps empty space between two valid grasps). Fix: a distributional policy (diffusion, flow matching, ACT's CVAE), never MSE regression.
• Observation and action mismatch. The deployment observation must be identical in meaning to the training observation: same camera crops, same image normalization, same proprioception fields and units, same action space and scaling, same control rate and chunk handling. A silent mismatch between the data-collection pipeline and the deployment pipeline is one of the most common and most maddening bugs, and it presents as a policy that "just does not work" with no obvious error.
• Distribution shift from the world, not the policy. New object instances, novel clutter, lighting the demonstrations never contained. The policy is out of distribution through no fault of its own. Fix: broaden the data (more coverage, augmentation, pretraining), and detect out-of-distribution inputs at runtime.
• Idle-state and pause artifacts. The policy stalls in near-zero-action states because the demonstrations contained hesitations. Action chunking largely fixes this.

The safety posture mirrors the RL guide: treat the learned policy as an untrusted component. Wrap it in hard joint-level and workspace limits it cannot exceed, a classical safety monitor that can halt or fall back to a safe state on anomalous behavior, and force-torque limits for contact tasks so a confused policy cannot drive the arm into the table. See robot safety & functional safety. The learned policy decides what to do; trusted guards decide what it is allowed to do.

Where this is heading: the single-task behavior-cloning policy is giving way to broadly-pretrained vision-language-action models that fine-tune to new tasks from a handful of demonstrations, the intervention-based data-collection loop is becoming the standard way to close the last reliability gap, and imitation-plus-RL hybrids are becoming the default for tasks where a reward can be scraped together. The loss function has largely stopped being the interesting variable. The interesting variables are the data (how it is collected, how much is needed, how it transfers across robots and from human video) and the guards that make a learned policy safe to deploy.

Frequently asked questions

What is the difference between imitation learning and behavior cloning? Imitation learning is the whole family of methods that learn a policy from demonstrations. Behavior cloning is the simplest member: direct supervised learning of the observation-to-action mapping. DAgger, inverse RL, adversarial imitation, diffusion policies, and ACT are all imitation learning; they differ in how they handle the compounding-error problem that plain behavior cloning suffers from.

Why does my behavior-cloning policy fail even though its validation loss is low? Because validation loss is measured on the expert's states, and the policy is deployed on its own states. A tiny per-step error moves the robot off the demonstrated manifold, where errors compound. The offline metric never sees this. Judge the policy by real-rollout success rate, not held-out action accuracy, and fix drift with action chunking, intervention data, or RL fine-tuning.

Do I need a simulator for imitation learning? No, which is one of its advantages over RL. Behavior cloning is offline supervised learning on recorded demonstrations and needs no simulator, no reward, and no environment interaction during training. Simulation helps if you want to generate synthetic demonstrations cheaply or apply DAgger with a scripted expert, but it is optional.

How many demonstrations do I actually need? For a narrow single task with a modern architecture (ACT, diffusion policy), often 50 to 300. The number rises quickly with the variation you need to cover (object poses, lighting, clutter), because the policy must see enough of that variation to interpolate across it. Broad multi-task policies rest on hundreds of thousands to millions of trajectories, but pretraining on those corpora lets you fine-tune a new task from a handful of demonstrations.

Why do diffusion policies work so well for manipulation? Because human demonstrations are multimodal and manipulation is contact-rich. Diffusion models represent multimodal action distributions natively (different noise seeds denoise to different valid modes), express complex correlated action chunks, and train stably. That combination handles the multimodality and precision that mean-squared-error regression fails on. The cost is slower inference from the denoising chain, which flow matching and distillation reduce.

What is action chunking and why does it help? Instead of predicting one action per timestep, the policy predicts a short sequence of future actions and executes them before re-planning. It reduces compounding error by cutting the number of decision points, and it smooths through the pauses and hesitations in human demonstrations that make per-step policies jittery. ACT is the well-known implementation, pairing chunking with a conditional VAE for multimodality and temporal ensembling for smoothness.

When should I use imitation learning instead of reinforcement learning? When the task is easy to demonstrate but hard to reward, which describes most tabletop manipulation. Use RL when demonstrations are impossible, dangerous, or unnatural to collect and a reward is writable, which describes much of legged locomotion. The strongest systems combine them: imitation to get a competent policy fast, RL to make it robust and push past the demonstrator.

Can an imitation policy be better than the human who demonstrated it? Not from behavior cloning alone: a cloned policy is bounded by the demonstrations and inherits their gaps. To exceed the demonstrator you need reinforcement learning, either fine-tuning the imitation policy against a reward or using the demonstrations to infer a reward (inverse RL, adversarial imitation). Imitation gets you to human level cheaply; RL is what takes you past it.

What is covariate shift in one sentence? The training data comes from the states the expert visits, but at deployment the policy visits its own states, and the mismatch between those two distributions is why small errors compound into failures. DAgger fixes it by retraining on the states the policy actually visits.