A boring definition of Physical AI

The term Physical AI has always confused me. It gets used as if everyone agreed on what it means, and yet I’ve never read a definition that satisfied me.

My middle school literature teacher, Ms. Laforgia, used to say: “if you don’t know how to define something, you know half of that something at best.”

So I went looking for a definition, and I thought the largest company on Earth by market cap (and the one that puts the term on 50% of their keynote slides) could help me out.

I was quite disappointed:

“Perceives through sensors, cameras, lidars.” Wait what? Robots have used sensors, cameras, lidars and encoders for decades. Perception predates “physical AI” by a long way. What separates physical AI from a 2015 self-driving prototype, or from classical robotics running a perception-planning-control loop?

“Requires powerful physics-based simulation.” Does it? I know at least five companies shipping autonomous robots that actually work, and none of them runs the IsaacSim suite.

NVIDIA describes a capability (”interact with and adapt to surroundings”) and a product narrative. It never tells you what the thing is.

None of this is surprising once you look at NVIDIA’s three-computer strategy: a chip for training, a chip for simulation, a chip on the robot. “Physical AI” gets used as a marketing term - and a very effective one - that combines today’s strongest topoi of the venture ecosystem (ie. you should build “AI”, you should build for the physical world and you DEFINITELY should run expensive simulations on our stack!).

Fine. If the largest company on earth can’t define it, let me give it a crack, hoping Ms. Laforgia approves.

Physical AI is non-deterministic software running in the control loop of a machine. A learned policy that perceives through sensors, acts through hardware, and then perceives again as its own actions keep changing the world it is sensing.

That’s the physically embodied closed loop (perceive → act → world changes → perceive) plus the fact that the policy in the middle is learned, generating actions through probabilistic inference rather than executing hand-coded logic.

One post scriptum: notice I dropped the cognitive verbs entirely. No “understands,” no “reasons.” I’d rather define by mechanism and behavior (eg. what the system does and how the loop closes) than by attributing it a mind.

Yes, this definition feels broad. It includes the 2015 self-driving prototype. It includes a forklift running a vision model that decides obstacle / no obstacle. But that’s the entire point! The only honest definition of physical AI is a boring one.

Because if the definition includes everything from a smart forklift to a laundry-folding humanoid, then “physical AI” carries zero strategic information. It doesn’t tell you what to build, what to buy, or where value accrues. Physical AI is not a category but rather a property (just like “connected”, “electrified”).

Everything that people actually argue about when they say “physical AI” lives on gradients after the definition. Two matter most:

• Gradient one: how much of the sensorimotor mapping is learned. At the minimum threshold (the point where the word “AI” first earns its place in the loop) a trained vision model makes one decision (obstacle / no obstacle) inside an otherwise deterministic stack. At the maximum, the entire perception-to-action policy is learned end-to-end: the system was trained until it discovered the mapping on its own.
• Gradient two: degree of generalization. At the low end, the system handles exactly its training distribution and breaks the moment the world shifts (think: the pick-and-place policy that works perfectly under factory lighting and fails when clouds cross the sky). At the high end, it handles what it was never shown: new objects, new lighting or a jobsite it has never mapped.

What the gradient framework implies is that every step up in either gradient buys you some capability and costs some deployability. More learned means less interpretable, harder to certify, harder to diagnose when it fails. More general means a bigger input space, more corner cases you haven’t seen, weaker uncertainty estimates. The real challenge is to maximize how much capability each notch costs you in deployability!

This is purely performative so I really hope I did not get this formula wrong, but if I’m right I just defined the exchange rate between capability and deployability!

The economics of non-determinism

Why does this matter for where value goes?

For LLMs, the cost of a sampling error rounds to zero because you can retry to get the right answer at near-zero cost (unless you run critical systems on LLMs, which you probably shouldn’t yet).

When a non-deterministic policy is wrong inside a physical control loop, you get downtime or a damaged workpiece or - worse - someone gets injured. In the physical world, errors are thermodynamically costly, and their economic implications may completely kill the ROI of your automation.

This simple fact means that:

1. Somebody has to underwrite the uncertainty. A probabilistic policy will, by design, occasionally do something out of distribution. Industrial customers buy automation through SLAs, which means that between the model and the customer there must be a layer that absorbs the variance (through engineering, maintenance, or human fallback) and gets paid for it.
2. The model layer is commoditizing in real time. At the top of the capability gradient, the frontier labs are open-sourcing models and chasing the RedHat playbook. “Powering your robots with AI” is a claim that is losing value, what will be left to charge for is embodiment, integration, operation, and guarantee.
3. Capability without deployability is a demo. But this I’ve written about ad nauseam so no need to repeat it.

The inversion here is that the very property that defines physical AI (ie. non-determinism in a physical loop) is the property that pushes value away from the AI itself and toward whoever manages complexity it in the field.

Own the vector, not the property

If this is the right framing, and Physical AI is really a property, the value question becomes: who owns the vector this property ships on?

The vector is everything around the policy:

• The machine: the embodiment proven right for one task, with its boring engineering (power, weatherproofing, tooling, safety rating)
• The workflow position: the slot inside a customer’s process where the machine does work that gets invoiced or that honors the SLA.
• The deployment muscle: which is basically the antithesis to the “drop-in hardware laborer”. A key bottleneck to deployment is, and will remain, electrical and wiring works, facility re-layouting, robot-adjacent infrastructure. A factory built for humans is hostile terrain for robots (and humanoids alike).
• The customer relationship, the SLA, the financing: the track record that solves supplier risk, the audit trail, the contract and the financial rails that make the deployment feasible for both integrator and operator.

Essentially, improvements in capability flow downhill to whoever holds deployment: whoever owns the vector captures the upside of every model improvement for free because a better open-source policy makes their machine faster, their margins fatter, their SLA cheaper to honor.

Go own the vector!

Concretely, three archetypes own vectors today:

1. Outcome-as-a-Service operators. They look like a traditional contractor from the outside and run robot-augmented crews in the backend. The crew absorbs the failures the robots will inevitably produce so that when the robot goes down, humans finish the job, and the customer never sees the messy middle. Autonomy phases in progressively (likely very slowly) and makes margins better.
2. Integrators - old or new. Somebody has to manage the model’s uncertainty on site, and that somebody holds the SLA. If anything, RFMs increase the integrator’s importance in the near term. The open question is whether legacy integrators will build the AI/ML muscle for it, or whether a new class of software-first integrators takes the seat.
3. Robot builders who pick a wedge. A machine for one job (and in their generational version, a catalogue of N of these, modular, interoperable). These machines become standard issue tools, customers will budget projects around them and will want to secure units earlier than competitors. These robots will be able to get out of their niche (or monopolize more of it) via progressively capable (likely non deterministic) features while remaining deployable (remember the formula!).

What realistic deployment of AI in industrials looks like, then, is almost anticlimactic: learned components phasing into deterministic scaffolding, one bounded decision at a time, with humans and integrators underwriting the variance, on machines that already pay for themselves.

This is Physical AI. Boring, right?