Amazon has deployed more than a million robots. I was surprised to hear Tye Brady @spaceguytye, CTO of Amazon Robotics for the last decade, talk about how much work still begins when a system leaves the lab. There is no getting around this even for the most experienced deployment team out there. A system may look convincing in testing, but when it reaches the real operating environment, something is always wrong. Nothing like reality to humble you. Even today, Amazon starts in one corner of one floor of one building, works through problems, and expands from there. A million deployed robots buys you an extraordinary amount of experience (and data). It does not let you assume the operating environment will cooperate. There is substantial work available to teams that can turn improving models into faster deployment operations a customer will actually run. Consider what has to happen after a robot performs a task successfully. Someone has to connect it to an existing process. Decide what happens when something goes wrong. Give an operator a useful way to intervene. Recover without turning a small exception into a production stoppage. Then collect enough evidence to know whether the next revision helped. Each of those decisions changes the product. Each depends on the facility and the people in it. Rodney Brooks @rodneyabrooks made this clear in another session moderated by the excellent @rocketalignment. In an industrial deployment, there are really three customers: the corporate buyer, the facility manager and the person beside the machine. They experience the same deployment through different problems. The buyer wants the investment to pay off. The facility manager wants production to run smoothly. The person on the floor wants an interaction that makes sense and does not make the job frustrating. A successful demonstration powered by advancing models answers only part of what those people need to know. My bet is that teams with a repeatable way to satisfy all three (and more) will become increasingly valuable as model capabilities improve. They will know which task is worth doing, which failure matters, and what the customer can tolerate while the system gets better. This is a demanding kind of work. It requires spending time in the facility, hearing conflicting requests and deciding which problems the system must solve. It also creates an opening for companies willing to take responsibility for the full customer experience.