What is physical AI?

The short definition

Physical AI is artificial intelligence that perceives and acts in the physical world, rather than only producing text, images, predictions or recommendations. A language model answers a question. A physical AI system picks something up, moves somewhere, or changes the state of an object — and has to be right about the world while doing it.

That distinction sounds obvious and is routinely underestimated. Almost every property that makes software AI tractable is weakened or absent once a system has to act physically.

What actually changes when AI gets a body

• Mistakes have consequences that persist. A wrong sentence can be regenerated. A dropped object is broken, a collision has already happened, and there is no refresh.
• The world is only partially observable. Cameras are occluded, sensors are noisy, and the thing that matters is frequently behind, underneath, or inside something else.
• Time is not negotiable. A control loop that misses its deadline is not slow, it is unstable. Latency is a correctness property, not a performance metric.
• Physics does not generalise politely. Friction, compliance, mass distribution and contact dynamics vary in ways that are hard to observe and harder to simulate.
• Data is expensive. Text was lying around on the internet. Robot interaction data has to be generated by a robot, in real time, at real cost, on real hardware that wears out.
• Safety is a hard constraint. There is no acceptable error rate for injuring somebody, which means the system has to know when to refuse to act at all.

Physical AI, embodied AI, robotics: the terminology

These terms overlap and are often used interchangeably. The distinctions that are actually useful:

• Robotics is the whole discipline, including mechanical design, actuation, electronics, controls and manufacturing. Most of robotics is not artificial intelligence.
• Embodied AI is the research framing: the argument that intelligence is shaped by having a body that senses and acts, and that learning grounded in interaction differs from learning from a corpus.
• Physical AI is the more recent, more commercial framing of the same territory, emphasising deployment: AI that does useful work in real environments.

Nothing turns on which phrase is used. What matters is whether the system has to be right about a physical world it can only partly see.

The parts of a physical AI system

Any system that acts physically has to solve several problems at once, and a weakness in any one of them caps the whole.

• Perception. Turning camera, depth, force and proprioceptive data into an estimate of what is present and where. This is where occlusion, lighting and calibration bite.
• State estimation. Knowing where the machine itself is, and how confident that estimate is. Confidence matters more than the estimate, because it determines when to stop.
• Representation. Some internal account of the scene — objects, surfaces, affordances, constraints — that planning can act on.
• Planning. Deciding a sequence of actions that achieves the goal without violating constraints, and re-deciding when the world moves.
• Control. Executing those actions on real actuators, in real time, with the stability guarantees the hardware requires.
• Learning. Improving from experience without regressing on things that already worked, which is harder than it sounds when the deployment is physical.
• Safety supervision. A layer whose job is to stop the system, independent of whether the rest of it believes it is doing well.

Why this became plausible recently

Three changes arrived at roughly the same time.

Hardware became purchasable. Capable arms, mobile bases and humanoid platforms are now products rather than research builds, so a software team no longer has to design a robot before testing an idea.

Learned methods started handling variation. Hand-written perception and planning pipelines fail at the edges of their assumptions, and the real world is mostly edges. Learned policies cope with more variation — imperfectly, but differently enough to matter.

Transfer across robots became a research programme rather than a hope. Cross-embodiment datasets, most visibly the Open X-Embodiment effort, pooled demonstrations from many robot types and showed that training across embodiments can beat training on one. That is the empirical foundation under the idea that capability might be portable at all.

What is genuinely still hard

An honest account has to include the parts that are not working.

• Reliability at task level. Per-step success rates look good and compound badly. A step that works ninety-five times in a hundred is close to a coin flip across fourteen steps.
• Contact-rich manipulation. Anything involving deformation, friction-dependent grip, insertion or force control remains substantially harder than pick-and-place of rigid objects.
• Long-horizon tasks. Chaining skills requires knowing when the previous one actually succeeded, and failure detection is less mature than the skills themselves.
• Evaluation. There is no agreed way to say a capability is ready. Offline metrics do not predict deployed reliability, and a video predicts nothing.
• Data. Collection is expensive, teleoperated demonstrations are slow, and simulation systematically misrepresents exactly the physics that matters most.
• Specifying safety. Enumerating every condition under which a capability must refuse to act, and showing the list is sufficient, is harder than producing the capability.

Where it is being applied first

The pattern across serious deployments is the same: bounded tasks, structured environments, high repetition, measurable baselines, and failure modes that cost time rather than safety. Material handling and logistics fit that description better than anything else, which is why they lead. Inspection and observation in less structured settings follow, because producing a record is more forgiving than changing the world. Domestic assistance is last, because homes are unstructured and the tolerance for error is lowest exactly where the setting is most personal.

How to tell a real result from a demonstration

Most public claims in this field are demonstrations, and demonstrations are selected. The questions that separate them from evidence are the same every time:

• How many trials? A success rate without a denominator is a best run.
• What was the intervention rate? How often did a human have to step in, and was that counted as a failure?
• Whose environment? The lab it was trained in, or somewhere it had not seen.
• Were the objects familiar? New instances of trained categories are much easier than genuinely novel items.
• Task-level or step-level? Per-step figures hide the compounding that decides whether a job completes.
• What did the failures look like? A system that fails safely and detectably is deployable. One that fails confidently is not.
• Could someone else reproduce it? If the protocol is not described, the number is not checkable.

Applying those questions to any announcement, including from this venture, is the fastest way to tell whether something has actually moved.

What physical AI is not

It is not general intelligence, and progress in it is not evidence of progress toward that. It is not autonomy in the sense of a machine that can be left alone with an open-ended goal. It is not a solved field with a deployment gap — the research problems above are open. And a demonstration video is not a capability: the relevant questions are what the intervention rate was, over how many trials, in what conditions, and what happened in the failures.

Being clear about that is not pessimism. The tractable near-term version — narrow, supervised, measured tasks that are genuinely useful — is valuable on its own, and it is the only version with an honest evidence base behind it.

Sources

• Open X-Embodiment: Robotic Learning Datasets and RT-X Models