Physical AI: what software teams should build before the robots arrive

Nvidia's Jensen Huang has spent the year calling this the age of physical AI, meaning AI systems that understand physical laws and act in the physical world rather than on a screen. At GTC in March he said every industrial company would become a robotics company, and humanoid robots have moved from stage demos into commercial pilots in warehouses and factories, where the tasks are repetitive and the environment can be controlled. Gartner lists physical AI among its 2026 strategic trends alongside agentic AI. The framing from researchers at IBM and elsewhere is that this is the natural next step as gains from simply scaling language models flatten out.

All of that is true and almost none of it is your problem. For most companies, physical AI will not arrive as a robot you buy. It will arrive as a set of software problems that show up a year before the hardware does, and the companies that solve those problems first are the ones that get value from the hardware when it lands. This post is about those problems.

The robot is the last thing you buy

A humanoid in a warehouse is useless without four layers of software that have nothing to do with humanoids. It needs to know what is where, which is an inventory and location data problem. It needs tasks, which come from the warehouse management system. It needs to report what it did, which is an integration problem. And someone needs to decide whether it did the right thing, which is an observability and audit problem. Every one of those layers is something a software team can build now, with the "robot" being a forklift driver with a scanner, a conveyor with sensors, or a camera on a line.

That is why the first physical AI projects we see are not robotics projects. They are data engineering projects wearing a hard hat.

Layer one: sensor data you can actually use

Factories and warehouses already produce enormous amounts of data from machines, scanners, cameras, and sensors, most of it trapped in the equipment that generated it. Physical AI of any kind, from a vision model checking welds to a fleet of mobile robots, needs that data in one place, with timestamps that agree, in a store built for time series. The work is ingestion over industrial protocols, a time-series database with sensible retention, and quality checks that page someone when a feed goes stale. It is unglamorous and it is the foundation. We describe the shape of it on our manufacturing and logistics pages, because it is the same shape every time.

Layer two: a model of the place

Robots learn in simulation before they touch the floor, which is why Nvidia keeps talking about digital twins and world models. You do not need Nvidia's stack to benefit from the idea. A digital twin of a warehouse can be as simple as a live map of locations, stock, and equipment state that a planner can query, and as complex as a physics simulation. The useful version for most companies is in the middle: an accurate, current model of the facility that software can reason over. If a route optimiser, a maintenance predictor, or eventually a robot fleet is going to plan against your facility, the facility has to exist as data first.

Layer three: control loops with a safety envelope

The moment a model's output moves something physical, the engineering standard changes. A recommendation that is wrong costs a bad decision. A command that is wrong costs a damaged pallet or an injured person. The pattern that works is the same one that makes agents that modify customer data safe, applied more strictly: the model proposes, a deterministic layer checks the proposal against hard limits it cannot argue with, and only then does anything move. Speed limits, exclusion zones, load limits, and a stop condition are code, not prompts. The model never holds the keys directly.

This is also where an agent harness stops being a nice idea and becomes a legal requirement. Every decision logged, every action attributable, every override recorded.

Layer four: the integrations nobody budgets for

The reason humanoid pilots are in warehouses and factories is that those environments already run on software: WMS, MES, ERP. A robot that cannot take a task from the WMS and confirm completion back to it is a very expensive demo. The integration work is ordinary API and message-queue engineering, and it is usually half the project. Plan for it up front, and plan for the systems on the other end to be older than anyone admits.

What this looks like for a company that is not a factory

Physical AI reaches beyond industry. Retailers get it as shelf cameras and inventory robots. Healthcare gets it as devices that report and, increasingly, act. Logistics gets it as autonomous yard trucks and sorting. In every case the pattern holds: the hardware vendor sells the hardware, and the value is captured by whoever owns the data, the model of the operation, and the integrations. That is a software position, and it is available now.

What to build this year

1. Get the sensor and equipment data out of the machines and into a store you own, with a data model someone has written down.
2. Build the live model of the operation, even a simple one, and put a real planning question against it. Where should this order be picked from? Which machine gets serviced next?
3. Prototype one closed loop where a model's output moves something, with the safety envelope in code and a person able to stop it.
4. Map the integrations to your WMS, MES, or ERP, because they will be on the critical path of every pilot.
5. Then talk to the robot vendors, with your data and your integrations ready. The pilots that succeed are the ones where the software was waiting for the hardware, not the other way round.

Physical AI is a hardware story on stage and a software story on the floor. If you want help with the floor, that is the part we build.