The model is perhaps a tenth of the work. Sensor timing and synchronization, the data path from photons to decision, thermal and power budgets on real compute, over-the-air updates, the safety case, and the loop that turns field data into the next release — that is the other ninety percent, and it is what decides whether the robot works on a rainy Tuesday when the lighting is bad and the network is flaky.
Where the effort actually goes
Look at the engineering calendar of any team that has put a robot into a customer's building and kept it there. Most weeks are spent on things that never appear in a demo. Getting three sensors to agree on what time it is. Deciding what the system does when one of them stops. Keeping inference inside a thermal envelope that was fine in the lab and is not fine in a warehouse in August. Shipping an update to four hundred units without bricking any of them. Writing down, in a form an auditor will accept, why the machine is safe to operate around people.
None of this is glamorous, and none of it is optional. It is also where most of the failures happen — not because the model was wrong, but because the pipeline delivered it a stale frame, or the watchdog fired, or a firmware update changed a timing assumption nobody had written down.
Demos versus product
Teams that treat autonomy as a research artifact ship demos. Teams that treat it as a distributed system — with interfaces, budgets, observability, and a release train — ship product. The difference is visible in how they talk. A research team says "the model achieves ninety-four percent." A product team says "the system meets its latency budget at the ninety-ninth percentile, degrades safely when the depth sensor drops out, and we can tell you which build every unit in the fleet is running."
The skills involved look more like network engineering and embedded systems than like machine learning: deterministic scheduling, bounded latency, back-pressure, fault containment, versioned interfaces between components that will be updated on different cadences. The organizations that win staff accordingly. They hire the person who has kept a distributed system running at scale and pair them with the person who trained the model, and they make sure the first one owns the architecture.
The best autonomy team we know spends most of its week on plumbing. That is not a failure of ambition. It is what shipping looks like.
The data loop is the product
There is one more piece of plumbing that separates a fleet from a pilot: the loop from field data to the next release. Every unit in the field is generating the training set for the next model, but only if the system captures the right moments — the near-misses, the interventions, the cases where confidence dropped — labels them cheaply, and gets them into a retraining and validation pipeline that produces a release the fleet can trust. Companies that build this loop early compound. Companies that don't are still hand-collecting datasets in year three, and their model is still a tenth of the work — it's just that the other ninety percent never got built.
What we tell founders
Put a systems architect at the top of the engineering organization, not a researcher. Write the interface contracts and the timing budgets before the second sensor arrives. Build observability into the first unit, because you will not be able to debug the four-hundredth without it. Treat the safety case as product design rather than paperwork; the customer's insurer will read it before the customer's engineers do. And plan the release train from the start — a robot that cannot be updated safely is a robot that will be retired at its first serious bug.
Red Tomatoes Enterprises · Published · Updated