Raphael Levy leads Go-To-Market strategy for Europe at Foxglove, an agentic data platform for robotics developers. He works with founders and engineers across Europe who are taking robots out of the lab and into the field.
Fleet size gets its own slide in almost every robotics pitch deck. More robots deployed, more hours logged, more data collected. The logic runs that more data makes a smarter robot, and a smarter robot is a moat. This assumption doesn’t hold up well.
Collecting data is not the same as learning from it
A company running 500 robots that never reviews what went wrong is not ahead of a company running 50 robots that does. The first company has more raw material but it does not have more insight.
This matters more in robotics than it did in software. A recommendation engine can be wrong quietly, in the background. Nobody gets hurt if the wrong song plays next. A robot’s mistakes are physical: a dropped payload, a missed grasp, a near miss with a person on a warehouse floor. The cost of an unexamined failure is higher, and so is the value of examining it.
The real question is what happens after something goes wrong in the field, and whether that failure ever turns into a specific, fixable problem, or just becomes another clip nobody watches again.
Most teams already have more footage than they’ll ever review. The bottleneck isn’t collection anymore but what happens between the moment something goes wrong and the moment someone actually looks at it.
The loop that really matters
The companies pulling ahead share a habit I see across the robotics teams I work with at Foxglove. They run a tight loop: understand what happened, find the gaps worth fixing, fix them, and confirm the fix worked before it ships to the rest of the fleet. Teams with that loop treat one failure as information for the whole fleet. Teams without it file it under one robot’s bad day.
Understanding what happened sounds obvious until you try to do it at scale. Most teams can tell you what a robot did. Fewer can tell you why, especially when the failure only shows up under one lighting condition, one surface, one edge case that happened twice in ten thousand runs. What I mean by real understanding is being able to search a fleet’s history and find all fifteen instances of a subtle problem, not just the one that got flagged by hand.
Take a warehouse robot that occasionally misjudges the edge of a pallet. On any single day, that looks like one weird miss. Pulled across three months of fleet history, it might be the same miscalculation happening every time a pallet is wrapped in a particular shrink film under a particular light. This pattern is invisible at the level of one robot, one shift, one clip. It only shows up once you can search across the whole fleet’s history at once.
Deciding which gaps to fix is a filtering problem because not every anomaly deserves attention. The teams moving fastest are ruthless about prioritising failures that recur, that carry real risk or that block a specific customer, instead of chasing every interesting one-off.
Fixing the problem is usually the part people assume is hardest, and it is real work, but most robotics teams are strong engineers already. What they’re missing is the input: a clean, labeled, retrievable set of examples that truly represents the gap they’re trying to close.
Confirming the fix is the step that gets skipped under deadline pressure. A fix that isn’t validated against the conditions that caused the original failure tends to come back later, usually at a worse time, in front of a worse audience.
A useful test
Deployment footprint and learning ability are separate things. When a company fixes a problem on one robot, ask whether the fix reaches the rest of the fleet or whether every site relearns the same lesson alone. Companies with a real moat have built the infrastructure that makes the first answer true. The rest are running dozens of small, disconnected experiments that happen to share a hardware platform.
This is also the question worth asking before writing a check or signing a deal. Not “how many robots have you deployed,” but “give me one example of a failure you found, fixed, and confirmed didn’t come back.” A team that can’t answer that with something concrete probably has a fleet of robots that each learned nothing from each other.
The advantage compounds, if you build for it
Fleet size does still matter. A bigger fleet means more edge cases surfaced, more conditions tested, but that’s raw material, not an advantage. It only becomes one when there’s a system turning those opportunities into measurable improvements: fewer failures, faster deployment cycles, lower cost per successful task.
This is also where the economics start to diverge. A company with a working loop gets cheaper to run as it grows, since every new robot adds signal to a system that already knows what to do with it. A company without one gets more expensive as it grows, since every new robot just adds footage to a pile nobody has time to watch. If you run that forward twelve months, the gap isn’t small. One fleet gets more reliable, faster to deploy into new sites, and cheaper to operate with each passing quarter. The other spends that same year fighting the same handful of failure modes on repeat, one customer complaint at a time, without ever building the muscle to stop it from happening again.
A 2026 study on fleet-scale reinforcement learning found real evidence for this. Researchers closed the loop between deployment, shared experience, policy improvement, and redeployment across a fleet of 16 dual-arm robots, and a single shared policy improved to a 95% average success rate as fleet experience accumulated. The gains compounded with the fleet, not with any single robot. This is the clearest evidence yet that the loop, not the fleet size alone, is what actually compounds.
The next real advantage in robotics will go to whoever closes the loop between deploying, learning and improving fastest. Fleet size is easy to put on a slide. Learning speed is harder to fake.
