Hardware-agnostic robotics: why your humanoid platform shouldn't lock you in
Over 100 companies build humanoids, most with closed software. The signs of vendor lock-in, what EU law gives you, and how to keep skills portable.
Motion team ·
Vendor lock-in with humanoid robots happens when the skills, data and fleet software you build only work on one maker's robots. Switching then means re-teaching every task. Most humanoid makers ship closed software, so your protection sits in the contract and in software that runs several brands. Moving a skill to a new robot still takes retraining and re-validation.
The fragmentation problem
The humanoid robotics market is fragmenting fast. Over one hundred manufacturers are now shipping or preparing to ship humanoid robots, more than 140 in China alone. Most come with their own software, control interfaces, programming tools and maintenance requirements. For a manufacturer evaluating humanoid automation, this creates a risk that is easy to overlook in the excitement of a first deployment: vendor lock-in.
Physical AI is the part that makes a robot useful: the perception, the learned skills, the task model and the fleet logic. Bodies will keep changing and keep getting cheaper. The intelligence layer is the asset worth keeping, which is why it should not belong to whoever sold you the hardware. We explain the layers in more detail in beyond the humanoid.
Vendor lock-in is a familiar problem in enterprise technology. Companies that adopted proprietary ERP systems, cloud platforms or industrial control systems learned, often painfully, that switching costs compound over time. The longer you operate inside one vendor's ecosystem, the more your workflows, data, training and know-how become entangled with that vendor's tools and interfaces. Eventually switching becomes so expensive that it is effectively impossible, even when better or cheaper alternatives appear.
Humanoid robotics is on the same path. Most humanoid makers ship their own closed software. If your deployment software is tied to one manufacturer, your workflows do not transfer, your training data is not portable and your operators' skills are vendor-specific. When a better or cheaper humanoid ships from a competitor, you face a choice between starting over or staying on hardware that no longer fits.
Signs your humanoid deal locks you in
- Skills or workflows cannot be exported in a format another system can read.
- The contract lets the vendor train its models on recordings of your people.
- The fleet software runs only that vendor's robots.
- There is no open interface to the robot, such as ROS 2 or a documented API.
- Maintenance and spare parts come only through the vendor, with no service levels.
- The software licence is tied to the robot's serial number and ends when the hardware is swapped.
- Operation is cloud-only, so the robots stop if the vendor's service does.
- There is no clause on access to the data your robots generate.
- The exit terms say nothing about returning or deleting your data.
What hardware-agnostic actually means
Hardware-agnostic robotics software puts a layer between the task you want done and the specific robot that does it. You describe what needs to be done. The software works out how to do it on the hardware you have.
This has several practical consequences for a manufacturer's flexibility and total cost of ownership.
The same workflow can run on different robots. A packaging workflow developed and validated on one humanoid model can be adapted to a model from another manufacturer. The task logic (what to pick, where to place it, in what order) is preserved. What changes is how the task maps onto the new body: joints, hands and sensors differ, so the skill is retargeted and retrained, then validated again on the line. That takes far less time than teaching the task from scratch, but it is real work.
Different robot brands can work side by side in the same facility and be managed through a single dashboard. A manufacturer might use lightweight humanoids for material handling on one line and models with a higher payload for palletising on another, both managed with the same fleet software, the same interface and the same operator training. What that software needs to do is covered in what manufacturers need from fleet software.
Upgrading hardware needs far less retraining. When a newer humanoid ships, and in this market new models arrive often, a manufacturer can bring it into the fleet through a lease without rebuilding the workflows developed over months of operation. The skills are retrained for the new body and re-validated, and the operational knowledge behind them is kept. A new robot also changes the cell, so the risk assessment is redone.
How the abstraction layer works
The architecture behind hardware-agnostic software has four levels, each with a different relationship to the hardware.
At the top is the task layer, which is hardware-independent. This is where the job is captured: what the operations manager needs done, and recordings of the operators who already do it. There is no reference to joint angles, motor torques or sensor specifications, only the desired outcome in human terms.
Below that is the behaviour layer, where the AI system breaks the task into a sequence of actions and trains a policy through simulation. This policy captures the logic of the workflow (what to do, when and in what order) with as little of a particular robot's body in it as possible.
The translation layer is where hardware specifics enter. The policy is mapped onto the kinematics of the target robot: its degrees of freedom, joint limits, velocity limits, gripper type and sensor layout. This step is repeated for each new robot model without rebuilding the layers above, and the result is fine-tuned and tested on the new body before it goes into production. Moving a learned skill between very different bodies, for example between different hands, is still an open research problem.
At the bottom is the execution layer, where low-level motor commands are sent to the robot's actuators. This layer is fully hardware-dependent and is handled by the manufacturer's own firmware.
The task logic and the decision-making live in the top two layers, which carry over between robots. The bottom two layers touch the hardware and are redone for each model. This separation is what makes workflows portable, with retraining, across robot models.
What EU law gives you
The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. It gives the user of a connected product, including a company that rents or leases it, the right to access the data the product generates and to have that data shared with a third party of its choice. Trade secrets, security and the rule that the data cannot be used to build a competing product can limit that right. The Act also sets rules for switching between cloud and edge data-processing services, including export in a machine-readable format, and switching charges end on 12 January 2027 (European Commission summary). Whether those switching rules cover a given fleet software contract depends on how it is sold, so ask your lawyer.
The Act gives you a right to the data. It does not make a skill trained for one robot run on another, so you still need the contract terms below.
How to avoid lock-in
- Get the right to export your task definitions, skills and recordings in a documented format.
- Agree in writing who owns recordings of your people and whether anyone else's robots can be trained on them.
- Add a data access clause that matches your Data Act rights, with a format and a response time.
- Choose fleet software that already runs more than one robot brand.
- Ask what retraining and re-validation a move to a different robot model would involve, and how long it takes.
- Check that the robots keep working if the vendor's cloud service is unavailable.
- Set service levels for maintenance and spare parts in the contract.
- Make sure the exit terms cover returning and deleting your data.
The strategic implications for manufacturers
Hardware independence affects your negotiating position, your technology risk and your supply chain.
Negotiating leverage is the most immediate benefit. A manufacturer that can switch between robot makers negotiates price, support and contract terms from a stronger position than one locked into a single vendor.
Technology risk is managed by keeping options open. The humanoid market moves fast enough that today's leading hardware may be outclassed within a couple of years. Software that runs several brands means your investment in workflows, training data, operator skills and fleet management survives a hardware change, with retraining instead of a restart.
Supply chain resilience improves when you do not depend on one manufacturer's production capacity, component supply or business continuity. If your only hardware supplier has delays, shortages or financial trouble, a hardware-agnostic setup lets you source alternatives without rebuilding your automation from the ground up.
In a market with over one hundred humanoid manufacturers, the software and the contract matter more over the long run than the choice of robot. Motion works with several robot makers, so customers are never tied to one.
If you have a task in mind, book a 30-minute call and we will tell you whether a humanoid fits it.