Beyond the humanoid: what physical AI on a factory floor involves
Physical AI is AI that perceives and acts in a plant. The humanoid is one layer; sensing, simulation, skills, orchestration and integration matter more.
Motion team ·
Physical AI is artificial intelligence that perceives, decides and acts in the physical world. On a factory floor the humanoid is only one layer of it: the body. The plant-wide sensing, the synced replica of the line, the skill library, the orchestration across machines and the integration with your systems decide whether a deployment works.
The robot is the part you can see
When visitors see a humanoid robot working a line, most of them watch the arms. They watch the hands. They ask what it cost. Almost nobody asks the question that actually decides whether the deployment works, which is what the robot is connected to.
This is an understandable blind spot. The humanoid is the visible part, it moves, and it looks like the future. But in a working factory the robot is a body, and a body is close to the easiest component to buy. Over one hundred manufacturers now build them (more than 140 in China alone), capability is rising every quarter, and component costs are falling fast enough that hardware will not be the constraint for much longer.
The constraint is everything the body is attached to. That is what the term physical AI describes, and it is worth understanding properly before you sign anything.
What physical AI actually means
Physical AI is artificial intelligence that perceives, decides and acts in the physical world rather than on a screen.
A language model that writes a bad paragraph costs you a retry. A model driving a machine that fails in a real aisle costs you a damaged part, a stopped line, or worse. Everything about how physical AI is built follows from that asymmetry: it has to learn somewhere failure is free, it has to know when it is uncertain, and it has to be able to hand the job back to a person.
A humanoid is a container for physical AI. It is not the same thing, any more than a laptop is the same thing as software. Once you separate the two, most of the confusing questions about humanoid adoption get easier to answer.
Beyond one body: the mixed fleet
The first thing beyond the humanoid is other bodies.
Real plants do not end up all-humanoid, and any vendor promising otherwise is selling a form factor rather than a solution. What a mature floor looks like is a mix, with each shape doing what its geometry is good at.
Humanoids earn their place where the work was designed around a human. A bench at human height, a tool with a human grip, a gap a human body fits through, a task that changes three times a week. In those spots the alternative is rebuilding the workstation, and rebuilding the workstation can cost more than the robot.
Wheeled mobile robots move material between places. They are faster, cheaper and far more energy efficient at transport than any legged machine, and transport is a large share of what people in a warehouse actually spend their day doing.
Autonomous lift trucks handle pallets. A humanoid lifting a pallet is an engineering stunt. A lift truck lifting a pallet is a solved problem.
Fixed arms that learned their task sit at a machine or a bench and repeat. The arm has existed for decades; what changed is that it can now be taught by demonstration instead of programmed line by line. Read more on that shift in how a robot learns a task in simulation.
Inventory drones count stock in high racking, which is dull, slow and dangerous work for a person on a lift.
Exoskeletons belong in the list too, because for a good number of tasks the honest answer today is still that a person should do it, with help.
A serious physical AI company has an opinion about which body gets which task. A hardware vendor, by definition, does not. Motion deploys humanoids; when another form factor is the better answer, the assessment says so.
Sensing that is not on the robot
The second thing beyond the humanoid is perception that does not live on the robot.
A robot knows what its own sensors can see, which is a narrow cone in front of it, for the seconds it is looking. That is enough to pick up a part. It is not enough to run a floor.
To do anything at the plant level you need a model of the plant, and that comes from sensors distributed through the building: fixed cameras over the cells, depth sensors at the pinch points, weight and presence data from the conveyors, tags on the pallets and totes, and machines reporting their own state. The robot then becomes one more contributor to a shared picture instead of the only source of truth.
This is also where most of the real-world reliability comes from. A robot that can be told "the tote you are looking for moved to the other rack" behaves very differently from one that has to discover it.
The replica of the line
The third thing is a synced copy of your line that the intelligence can practise in.
The economics here are simple. Learning a task on a real floor costs minutes per attempt, occupies the line, and risks damage. Learning it in a replica costs milliseconds per attempt, runs thousands of variations in parallel, and breaks nothing. Then the learned behaviour is transferred back to the real machine, which is the process known as sim-to-real transfer.
The replica has to stay synced. A one-time scan of your building ages badly, because factories change constantly: a pallet moves, a machine is replaced, the product variant changes. A replica that keeps updating from the live sensing layer stays useful.
The skill library is the asset
The fourth thing, and the one that decides your long-term economics, is the library of learned skills.
When a robot learns to open a specific carton, that skill has value. When that skill transfers to the next carton, the next cell, the next site and, with retraining, the next body, it becomes an asset that compounds. The whole reason a second deployment should cost less than the first is that most of what was learned the first time carries over.
This is the part you should care about owning. Bodies depreciate and get replaced, and in a market moving this fast they will be replaced sooner than most equipment on your floor. The learned behaviour of your operation should not be trapped inside whichever machine happened to be on the floor when it was captured. That argument is made at length in why your humanoid platform should not lock you in, and it is the single most important thing to get right in a first contract.
It follows that the data behind those skills matters as much as the skills themselves. Recordings of how your people work are a description of your operation. Where they are stored, who can train on them, and whether they can ever be used to improve a competitor's robots are contract questions, not technical ones.
Orchestration: deciding who does what
The fifth thing is the layer that rarely appears in a demo.
Once you have more than one machine, something has to decide which one takes which job, in what order, and what happens when one of them stops. It has to handle the handovers between bodies, which is where most mixed-fleet deployments fall apart: a mobile robot brings a tote to a cell, a humanoid unloads it, a fixed arm feeds the machine, and any gap in that chain leaves a robot waiting.
It also has to know when to stop and ask. An honest physical AI system escalates. It recognises the case it has not seen, it pauses, and it brings in a person, through a remote operator or a supervisor on the floor. In a good system, the list of things it needs a human for keeps getting shorter, and it never quietly guesses. What that layer needs to do is broken down in what manufacturers actually need from fleet software.
The unglamorous half: integration
The sixth thing is the part that takes the most calendar time and gets the least attention.
A robot that cannot read the production order is a demo. To do real work it has to be connected to the systems that already run your plant: the production or warehouse system that says what needs making and where it goes, the controllers on the machines it works beside, the quality system that records what it checked, and the maintenance system that logs what it did.
These are not exotic problems, but they are specific to your site, and they are a large part of why a first deployment takes 12 to 15 weeks. A realistic integration spends more time here than on anything involving the robot's hands. Our factory readiness checklist lists what to have ready before week one.
Safety is a system property
The seventh thing is that safety does not live on the robot either.
There is no harmonised safety standard for humanoids yet: ISO 25785-1, which covers industrial mobile robots that actively control their own balance, is still a committee draft. What can be assessed today is the full deployment, against machinery safety rules and ISO 10218-1 and ISO 10218-2:2025. The thing you have to make safe is the cell: the robot, the people around it, the machine it works beside, the path it walks, the speeds it moves at, and what happens when something unexpected enters the area. Change the layout and you have changed the safety case, even if the robot is identical. Add a second robot and you have changed it again.
Under EU rules the obligations are split. The robot maker answers for the robot. Whoever builds the cell answers for it as an assembly of machinery under the Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027 and replaces the Machinery Directive 2006/42/EC that day. The employer keeps its duties for the workplace under the work equipment directive 2009/104/EC. Buying a CE-marked robot does not make the cell compliant. Every Motion deployment includes a risk assessment for your site. The detail is in our guide to humanoid robot safety and EU compliance and our guide to the Machinery Regulation for robot users.
What this means when you buy
If physical AI is the stack and the humanoid is one layer of it, the buying questions change.
Stop asking how many kilograms it lifts and how many hours the battery lasts. Those numbers will improve without your involvement. Ask instead:
- Who owns the skills the robot learns on my site, and can I take them to different hardware?
- Where does the recorded data live, and can it be used to train anyone else's robots?
- What happens when the robot meets a case it does not know? Does it stop, or does it guess?
- If I add a second and third robot, and they are not the same model, does one system still run all of them?
- What is your plan for the tasks a humanoid is the wrong shape for?
- How does this connect to the systems that already tell my plant what to make?
If a vendor cannot answer those, you are buying a robot and will be building the rest yourself.
The short version
The humanoid is the body, and bodies are becoming a commodity. The intelligence that makes a body useful on a real floor is not: the plant-wide sensing, the synced replica, the portable skill library, the orchestration across a mixed fleet, the integration with the systems you already run, and the honesty to hand a job back to a person.
That layer is where the value accumulates, and it is deliberately independent of whose hardware you buy. Motion builds it, and we start with humanoids because that is where the work in European factories and warehouses is shaped for a human body today. Motion works with several robot makers, so when the right answer for a given task turns out to be a different body, what you have learned carries over with retraining instead of starting from zero.
If you have a task in mind, book a 30-minute call and we will tell you whether a humanoid fits it.