Designing for a World That Won’t Hold Still

In the cloud, you design once for a known workload. In the physical world, the site, the mission, and the people all change under you. Designing for that is a different discipline.

You set up a site. You get the coverage right, you align the radios, you orient the cameras, you check that every device is online. Then you drive away.

Come back three weeks later and it is a different place.

This has happened to us half a dozen times. Enough that we stopped calling it bad luck and started calling it the design problem. The site you plan for is almost never the site you end up operating, and the gap between the two is where a surprising amount of the hard engineering in Physical AI actually lives.

The cloud got to assume a world that holds still

To see why this matters, look at how the cloud handled the same problem - because, for the most part, it did not have to.

When you design AI infrastructure for a data center, you know the workload. You know roughly how much compute, networking, power, and cooling you need, and you dimension the building for it. The walls do not move. The racks do not wander. A server you install in row 14 stays in row 14 for its entire life. When you need more, you provision it from a near-infinite pool and hand it back when you are done. The environment is controlled, and the resources are elastic. That combination is the quiet advantage underneath modern cloud AI.

Physical AI gets neither. The environment is not controlled and it does not hold still, and the resources are tied to physical things - radios, cameras, edge compute, power - that live in specific places doing specific jobs. You cannot dimension the site once, because the site you dimensioned for is gone by the time the work is done.

Four ways the ground moves under you

The change comes in four flavors, on two very different clocks.

The structure changes. On a greenfield build - a data center rising out of an empty field is the clearest case - the physical world reshapes itself weekly. A coverage map you validated on Monday is obsolete by Friday, because a steel-and-concrete building now stands where there was open air and your signal is bouncing off a wall that did not exist. The map is out of date before the concrete has cured.

The layout changes. Roads get cut, rerouted, and paved as a project marches across a site over one to two years. On the last day of one solar build, the ground was soft, and a trailer we had fully installed and aligned had to be moved thirty feet so the tractor-trailers could reach their drop on the rerouted roads. The mast keeled to twenty degrees on the way, and the point-to-point radio alignment we had carefully dialed in was simply gone. Indoors it is the same story on a faster clock: factories change their layouts constantly, and every time a machine moves, the Ethernet drops hanging from the ceiling have to be re-run, fixed cameras lose the view they were mounted for, and the automated vehicles have to learn new routes. We have had a wireless access point run perfectly for months and then vanish behind a metal slab that someone parked in front of it.

The mission changes. This is the one people miss, and it is the most important. As a site moves through its life, the cast changes - a construction crew hands the site to the operator; electricians give way to carpenters give way to an operations team - and when the people change, the job of the infrastructure changes with them. What mattered most during construction (site safety, worker connectivity, tracking equipment) is not what matters once the facility is running (security, monitoring, uptime, tight service levels). The infrastructure tuned for the day-one mission has to re-orient to the day-two-hundred mission without being ripped out and reinstalled. Static infrastructure assumes a static world. It also, more quietly, assumes a static mission. Physical AI gets neither.

And the people interfere. All of that unfolds over weeks and months. On top of it runs a second, much faster clock: the people on site. They reconfigure the network. They unplug a switch to borrow a port. They pull a power connection, or trip the supply feeding your devices by plugging in their own high-amperage gear. On a food line, a coating spray meant for the product drifts onto a camera lens and blinds it in an afternoon. You do not get a clean, controlled environment. You get a working one, full of people doing their jobs, and your infrastructure has to survive all of it.

You cannot solve this by dimensioning once

The instinct from the data center world is to plan for the worst case and build it in up front. In the physical world that fails twice over. Overbuild for every possible future and you are hauling a fifty-thousand-dollar trailer of capacity to a job that needed a fraction of it. Underbuild and you are down the first time the site moves. Neither the cloud’s “design once for a known load” nor a bigger static design survives contact with a world that will not hold still.

So the answer is not a better static plan. It is a different kind of infrastructure - one that expects change and re-plans itself as the site moves.

What that looks like in practice is a subject in itself, and it is where this series goes next. Two moves carry most of the weight. The common functions every vendor needs - connectivity, location, timing - have to live in a shared substrate that everyone draws on, rather than being brought in and swapped out by each vendor. And capacity has to follow the work as the work moves across the site, instead of being fixed in place on day one. Each of those deserves its own treatment, and we will take them apart in the pieces that follow.

The takeaway

You are not designing for a site. You are designing for a site whose geography, mission, and operators all keep changing - some of it over months, some of it in a single afternoon.

Static infrastructure assumes a static world. Physical AI never gets one. The infrastructure that wins will be designed around that reality. That is the layer we are building at Ramen.

^{Field Notes from the Last Mile is a running series on what Physical AI actually takes to deploy in the real world - from the people building it. Subscribe to get the next one.}

‍