What is embodied AI?

Two words doing different jobs

Embodied AI is used in two ways that have drifted apart, and most confusion about the term comes from not noticing which one is meant. The older use is a research position: that intelligence is not a property of a disembodied reasoner but something that arises from a body acting in an environment, and that you cannot build the first without the second. The newer use is a market label, applied to any machine learning system that ends up controlling hardware.

The research position is specific and old. Rodney Brooks argued through the late nineteen eighties and early nineties that the symbolic approach had the architecture backwards — that behaviour should emerge from tight loops between sensing and acting rather than from a world model that perception fills in and planning consumes. The argument was not that representation is useless. It was that a system which must keep a model of the world accurate enough to plan from has taken on a harder problem than the one it was trying to solve.

That lineage matters because it explains why the field keeps rediscovering the same obstacle. Every generation of approach runs into the fact that the world supplies evidence only when you act, and acting costs something.

Embodied AI and physical AI

The two terms now overlap almost entirely in commercial usage, and anyone who tells you there is a crisp boundary is selling something. The practical difference is tone and provenance. Embodied AI carries the academic lineage above and is the term you will see on papers, labs and benchmarks. Physical AI is the industry-facing label, popularised more recently, and tends to be used when the subject is deployment rather than research. The guide on physical AI takes the deployment view; this one takes the research view.

If you are reading a paper, expect embodied AI to mean a specific experimental setting: an agent, a body real or simulated, a task, and a measurement. If you are reading a press release, expect it to mean approximately nothing.

What embodiment actually changes

It is tempting to treat robotics as machine learning with a slower data loader. The differences are structural.

• Data is generated, not collected. A language model is trained on text that already existed. A robot policy is trained on experience that someone had to cause, on hardware, in time. There is no equivalent of scraping the web.
• Observation is partial and chosen. What the system sees depends on where it looked, which depends on what it did. The dataset is a consequence of the policy, which makes the usual assumption of independent, identically distributed samples false in a way that matters.
• Mistakes are not symmetric. A wrong token is corrected by the next one. A wrong torque puts a load through a gearbox. Exploration has a cost denominated in hardware.
• The clock is real. A policy that needs three hundred milliseconds to decide is not a slow policy; for some tasks it is a wrong one. Latency is part of the problem specification, not an implementation detail.
• The environment answers back. Contact changes what is possible next. Pushing an object moves it. The world is not a fixed input distribution.

Each of these breaks a convenience that the rest of machine learning relies on, and together they explain why progress in this field is measured in demonstrations rather than benchmarks.

What the field currently contains

Three bodies of work sit under the label and they are not equally mature.

Simulated household and navigation benchmarks. Environments where an agent navigates, searches and occasionally manipulates in a simulated interior. These produced real progress on navigation and on the engineering of large-scale simulation, and they have a well-known weakness: results transfer to other simulators far more readily than to hardware.

Large-scale real-robot learning. Collecting demonstrations across many robots and tasks and training a single policy on the aggregate, then testing whether it does anything useful on a platform or task it has not seen. This is where the interesting results of the last few years have come from, and it is covered in more depth under robot foundation models and vision-language-action models.

Classical robotics with learned components. A conventional stack — perception, state estimation, planning, control — in which one or two modules are learned rather than written. Unfashionable, and responsible for most robots that currently do paid work.

The benchmark problem

Embodied AI has no equivalent of a held-out test set, and this is not a gap waiting to be filled; it is a property of the subject. A benchmark needs a fixed task, a fixed environment and a reproducible measurement. A robot result depends on the specific unit, its wear, its calibration, the lighting that day, the objects used, and how the person running it chose to count a success.

The practical consequence is that reported success rates across groups are not comparable, and that a number without a protocol is not evidence. When you read that a system succeeds eight times in ten, the questions that decide whether that means anything are: on how many distinct objects, over how many trials, on how many physical robots, with what counted as a failure, and with a human doing what during the attempt.

Within a single lab, held fixed, these numbers are genuinely useful for tracking progress. Across labs, they are close to meaningless, and treating them otherwise is the most common error made by people assessing this field from outside it.

What would count as progress

Three things would be hard to argue with, and none of them is a success rate.

Transfer to an unseen platform. A policy trained on one set of robots performing usefully on a robot that was not in the training data, without per-platform retraining. This is the claim that would make the aggregation approach worth its cost.

Duration without intervention. Not a demonstration but a shift: a system operating for a working week at an economically interesting intervention rate. Most demonstrations are minutes long and most of the difficulty lives after hour one.

Failure that degrades rather than breaks. A system that recognises it is outside its competence and stops, rather than continuing confidently into damage. This matters more than peak capability for anything that will be deployed, and it is the property least often reported.

Where this leaves the term

Embodied AI is a useful word for a real research tradition and an almost useless word in a product description. If you encounter it attached to a claim, the question that resolves most ambiguity is simply: what is the body, and what did it do, for how long, without help. Where the answer is a simulated agent in a simulated house, that is legitimate research and not evidence about hardware. Where there is no answer, there is usually no result.

This venture has released no robotics software, so nothing here is a demonstration of anything. The development status page is the record of what actually exists.

The data problem is the whole problem

If you strip the field down to one obstacle, it is this: there is no equivalent of the internet for robot experience, and there may never be one.

Text and images were already being produced at enormous scale for human reasons, and machine learning took advantage of a corpus it did not have to pay for. Robot experience does not exist until somebody builds a robot, puts it somewhere, and operates it. Every hour of it has a hardware cost, a human cost and a wall-clock cost that cannot be parallelised by buying more processors.

Three strategies exist for getting around this, and each has a cost that shows up later. Simulation produces unlimited experience that is subtly wrong in ways that matter most for contact, which is the part manipulation depends on. Teleoperation produces real, correct data at roughly the rate a person can work, which makes the dataset a payroll line. Pooling across institutions produces scale at the cost of consistency, since the data comes from different robots, different cameras, different conventions and different ideas of what success means.

None of these is a solved problem, and the choice between them is the main strategic decision a robot learning group makes. It is also the reason this field moves at the pace it does rather than the pace that text models conditioned everyone to expect.

Reading a claim

A practical filter, for anyone assessing announcements in this area. Ask what the body was, and whether it was real. Ask how many physical units, because one unit tuned over months is not a result about a system. Ask over what period, because the gap between a two-minute clip and an eight-hour shift contains nearly all of the engineering. Ask what a human was doing during the attempt — resetting the scene between trials is a very different claim from not touching it. And ask what happened in the failures, because a system that fails safely and a system that fails into a wall have the same success rate and are not the same product.

Claims that survive all five questions are rare, and they are the ones worth paying attention to.