the gap, named :
in early 2026, a16z published the physical AI deployment gap, the clearest market-level description so far of why robotics feels simultaneously unstoppable and stuck : research is compounding fast, deployments are not. the essay's numbers are the ones every robotics founder recognizes : roughly 95% success in the lab, degrading to around 60% in deployment, sold to customers who expect three nines.
the essay's most important sentence is its diagnosis : the gap is not a research problem, it's an infrastructure problem. it names reliability engineering as a missing layer of the stack.
we agree, obviously, it's the layer we're building. but a market map tells you where the mountain is, not how to climb it. below is the engineering answer to each gap the essay names.
gap 1 : distribution shift :
the policy was trained and tested on one distribution, the field is another. lighting, calibration drift, object variety, floor friction. this is the root gap that feeds all the others.
the engineering answer is condition-scoped evaluation : define the condition matrix of the actual deployment site, test against it with enough runs to state per-condition success rates, and record what was not tested. then watch field data for drift, when the conditions the robot sees stop matching the conditions it was validated under, that's an alarm, not a surprise.
gap 2 : reliability thresholds :
a 90% policy is a great paper and a terrible product. customers price robot labor against human labor that shows up every day.
the engineering answer has two halves. measure honestly : success rates with confidence intervals, intervention rate, per condition, the full discipline we lay out in robot reliability testing. and engineer around the ceiling : graceful failure modes, degradation-aware behavior that requests help instead of flailing, and predictable fallbacks that take over when confidence drops. no learned policy reaches three nines alone, systems do.
gap 3 : latency and compute :
control loops run at 20 to 100 hz, big models don't. every team negotiates a tradeoff between capability and reaction time.
the engineering answer from the reliability side : whatever architecture you pick, hierarchical policies, distilled edge models, remote reasoning with local reflexes, your evaluation has to test the deployed configuration, not the lab one. a policy validated at datacenter latency and shipped at edge latency is an untested policy.
gap 4 : integration :
the model is one component in a stack of hardware, calibration, perception, planning, and the customer's own workflow. behavior is a property of the whole stack.
the engineering answer : capture and version everything that can change behavior, model version, code, hardware configs, calibration state, environment conditions, task definition, so that when behavior moves, you can trace which change moved it. this is the core argument of our robot deployment reliability pillar : map changes to outcomes, or argue from memory forever.
gap 5 : safety and certification :
standards bodies want deterministic guarantees, learned systems offer statistical ones. that mismatch will take years to resolve at the standards level.
the engineering answer available today : make the statistical case airtight and documented. a complete evaluation trail, what was tested, under which conditions, with what results, what was excluded and why, is both the honest safety story and the artifact any future certification process will ask for. teams that keep it from day one will certify years before teams that have to reconstruct it.
gap 6 : maintenance and drift :
deployment is not the finish line, it's the starting line of a decade of model updates, hardware wear, calibration drift, and environment changes, each one capable of moving behavior.
the engineering answer : regression testing as a standing institution. a fixed baseline suite re-run on every change, per-condition comparison against the last known-good version, and every field failure captured so it can be replayed and turned into a test. we go deep on this in robot policy evaluation.
the meta-answer :
read the six answers again and notice they are one answer : treat deployment like an engineering discipline with its own infrastructure, not as the victory lap after training.
the loop is : capture every run. score reliability per condition. diff every change against a baseline. decide from records. every gap above is what happens when one step of that loop is missing.
what to build first, if you're a small team :
- log every run with full stack state, from day one, even before you know what you'll do with it
- define the condition matrix for your first deployment site and test against it, not against the lab
- pick a fixed baseline task suite and re-run it on every checkpoint, no exceptions
- track intervention rate from the first pilot : it is the metric your customer actually experiences
- write the do-not-deploy list and keep it in the open, untested conditions are debts, not secrets
none of this requires waiting for tooling, but all of it gets expensive to retrofit. the teams that win deployments will be the ones whose reliability records are older than their competitors' companies. the graveyard of teams that skipped this discipline is documented, with sources, in why robot deployments fail.
frequently asked questions :
What is the physical AI deployment gap ?
The physical AI deployment gap is the distance between what learned robot policies achieve in labs and demos and what they deliver in production. Typical numbers: around 95% task success in controlled settings degrading to roughly 60% in the field, against customers who expect three-nines reliability. The gap is an infrastructure and engineering problem, not a model-capability problem.
Why do robots that work in the lab fail in the field ?
Because a learned policy's performance is tied to the distribution it was trained and tested on, and the field is a different distribution : different lighting, drifted calibration, unfamiliar object poses, floor friction, sensor noise. Failures compound across long tasks, and small environment shifts that a human would never notice can move success rates by double digits.
What reliability do production robot deployments need ?
Customers buying robot labor price it against human labor that shows up every day, so expectations land near 99.9% task-level availability. No learned policy meets that alone, which is why production systems combine policy improvements with engineering: graceful failure modes, human fallback, condition-scoped deployment, and continuous regression testing.
How do you close the deployment gap for learned policies ?
Treat deployment as an engineering discipline with its own infrastructure : capture every run with full system state, evaluate per condition with confidence intervals before rollout, regression-test every model and calibration change against a baseline, monitor intervention rate in the field, and keep an explicit list of untested conditions that block deployment. The loop is capture, score, diff, decide.
the deployment gap is real, measured, and named. it will not be closed by a bigger model.
it will be closed by teams that measure their robots honestly and engineer around what they find. we are building the infrastructure for exactly that.
Get a free audit today