I have spent a lot of time watching AI programs try to land on every site at once. Platform everywhere on day one. Same stack, same use-case list, same steering deck for a network that does not run the same way on Tuesday night in Atlanta as it does on Friday in Dallas.
What I find interesting is how often the stall is not that the network is hard. The program never proved one workflow on one floor with an owner and a definition of done.
Why "everywhere" feels responsible
A network rollout looks like leadership. It matches how other systems were bought. It keeps every site GM in the conversation so nobody feels left out.
It also lets a program stay in motion without forcing a production decision. If twelve sites are "in scope," nobody has to say which dock, which changeover, or which staging lane will ship first. The calendar fills with workshops. The floor still cannot answer when work on a trailer started and finished.
I have seen that pattern more than once. Broad scope. Thin ownership. A pilot that never survives night shift.
What one site first actually means
One site first is not a smaller ambition. It is a harder bar.
Pick a plant or DC where ops already owns the pain. Name one workflow: detention and dwell on the dock, empty-bay minutes, staging that eats capacity, a changeover sequence that slips, a blocked aisle that shows up before the stop.
Name the owner on that site. Site GM, warehouse lead, plant manager. Someone who will say whether the workflow worked on this shift.
Define done in operational terms they would recognize. Not "we detected anomalies." Done means the exception reaches the person who can act, within a window that matters, and the team can tell whether dwell, wait time, or a stop got better.
If you cannot say that in one sentence, you do not have a network plan. You have a research portfolio.
Prove it holds, then reuse
The useful sequence is boring on purpose.
Ship the workflow into production on that floor. Run it long enough that night shift and a handoff have touched it. Keep what held. Drop what only worked in a clean demo.
Then reuse the motion, not a copy-paste of the deck. The next site gets the same shape: owned exception, floor signal, done definition. The checks and the configuration will differ because the dock layout, labor model, and carrier mix differ. The discipline stays the same.
That is how a network gets built without pretending every site needed the same platform on day one.
Where vision fits without becoming the story
Vision often shows up as the way the first signal arrives. Plants and warehouses already have cameras. Most of that video is still a footage library until something fails.
With vision models, the camera can behave more like a sensor for start/finish, queues, sequence, and dwell. That can be the wedge that gets one site's workflow into production without waiting for a new sensor stack.
It is mid-piece, not the opener. The opener is still the ops problem and the owner. You are not rolling out a camera program across the network. You are proving one production workflow, then taking what held to the next floor.
What to resist on day one
Resist the urge to pick twelve use cases so every function feels included. Resist buying the platform story before any site has a shipping workflow. Resist treating EHS as the buyer when the P&L sits with ops. Safety can champion. Downtime, detention, yield, and labor minutes still need an ops owner.
Also resist measuring progress by sites "touched." Measure by workflows in production with a named owner and a done condition the floor would defend.
If you own a network of plants or DCs, the practical path is still small at the start.
One site. One workflow. An owner. A definition of done. Expand only after it holds.
That, to me, is how ops AI survives contact with the network. Not platform everywhere on day one. Proof on one floor, then reuse.