The Denominator Problem: What Warehouse Robots Taught Me About Reliability
Shivansh Inamdar builds AI and manipulation software for autonomous warehouse robots at Nimble Robotics.
gettyA robot that picks items correctly 95% of the time is impressive, but run that robot in a warehouse processing tens of thousands of items a day, and the math turns on you. Zoom out, and scale changes what a robotic system’s success rate actually means. That 5% failure rate becomes thousands of failed picks that need to be dealt with every single day.
In my experience, automation becomes commercially viable not when failures disappear, but when the system is built to handle them without flinching. This is especially stark in robotics, where the problem space is vast and failures play out in the physical world, but the lesson applies to any system that operates at scale.
At a warehouse doing 50,000 picks a day, a 95% success rate means 2,500 failed picks. Fight your way to 97%, where every incremental point is a tough battle, and you still end up with 1,500 failures a day. Left unhandled, each one turns into a person fixing an issue or an order getting delayed. At that volume, no success rate makes the failures disappear.
A pilot doing a few hundred items a day can have the exact same success rate as a production line, and yet the two can be miles apart. At low volume, failures are rare enough that the stakes are low. I have watched a launch that looked flawless in testing meet full production volume. With real-world variation, the failure rate that had been a footnote turned into daily operational work. The demo was not wrong; it was just small.
In production, a failed pick should almost never mean a person walking over. The robot’s job is to work down a ladder of fallbacks, each one trying to resolve the failure more cheaply than a person could. Only a failure that escapes every layer should reach a human. Recovery cannot just be an error handler bolted on at the end. It has to be a system of its own, and in my experience, there’s more engineering in that than in the picking itself.
The most important rung on that ladder is the last one: knowing when to stop and ask for help. When a failure does reach a person, the system’s job is to make that moment cheap. It should pass along what went wrong and what it needs help with. A system that fails clearly and safely is worth more than one that succeeds slightly more often, but fails confusingly when it does.
Eventually, you stop treating failures as anecdotes and start treating them as a dataset. Some failures are cheap and some are expensive. Some disappear with a retry while others, like a dropped item, might need a different, more expensive kind of recovery.
The real win isn’t chasing another percentage point; it’s identifying the highest-leverage failure class and going after that.
At scale, you cannot fix incidents one at a time. You need systems that fix entire categories. The failure data is what makes that possible, because it tells you exactly where to focus engineering effort, and in many cases, it can literally train the system that will fix it.
It is quiet, unglamorous engineering to just make things work, but done right, it is what takes a system from prototype to production.
Not all failures are physical. The same math applies to any system at scale: APIs, data pipelines, AI agents. Even a tiny error rate, multiplied by enough volume, is a constant stream of failures.
The questions that matter are the same ones we ask on the warehouse floor. How big is the denominator? What happens when something fails? And which failures actually hurt?
The answers say more about long-term viability than any success rate, because the system that survives at scale isn’t the one that fails least, but the one that fails best.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
