Humanoid robot manufacturers
How to evaluate a humanoid platform rather than compare specifications, and an honest view of where commercial deployment actually stands.
Why this is not a league table
Lists of humanoid robot companies with funding rounds and specifications go out of date within weeks and were never the useful thing anyway. Payload, degrees of freedom and runtime tell you almost nothing about whether a platform can do your job, and a company's valuation tells you nothing at all about that.
What follows is the set of questions that actually discriminates between platforms, and then a dated snapshot of where deployment stands — labelled as a snapshot, because that is what it is.
What to evaluate instead of specifications
- The integration surface. What interfaces are exposed, which are supported versus merely tolerated, what is documented, and whether a third party can build against them without a special relationship. A platform with no supported interface is a product, not a platform.
- Safety architecture and authority. Which safety functions exist, what they are rated to, whether safety logic is independent of the application controller, and what a third party is permitted to influence. The answer should be "very little", and a vendor that offers more should worry you.
- Test hardware access. Whether you can get a unit, on what terms, with what support. Integration written against documentation alone does not survive contact with a real machine.
- Stopping performance, measured. Not the rated figure — the measured one, including detection and reaction time, because that is what separation distance depends on.
- Serviceability. Spares availability, mean time to repair, who performs service, and what happens when a unit is down for a week.
- Fleet and version management. Whether you can tell what software every machine is running, stage a rollout, and roll back.
- Data terms. Who owns data generated on your site, whether it improves a product sold to competitors, and whether it leaves the premises.
- Support ownership. When a task fails, who triages it, and how a fault is divided between hardware and capability.
- Company durability. Not valuation — whether the platform survives a change of strategy, and what you hold if it does not.
Form factor: ask whether you need a humanoid at all
The honest question, and it is frequently skipped. Humanoid form is justified when the environment is built for humans and cannot economically be changed, when the task genuinely needs the reach and dexterity envelope of a person, or when one machine must do several different jobs.
It is not justified when a wheeled base with an arm would do the job better, cheaper and with far fewer failure modes — which covers a large share of warehouse work. Legs buy the ability to handle stairs and uneven ground, and they cost balance complexity, energy, cost and a failure mode where the machine falls over. For a bounded task in a structured building, the humanoid form is usually the expensive answer.
Where commercial deployment actually stands
Snapshot as of November 2026. Treat it as perishable.
The clearest publicly documented position belongs to Agility Robotics, because it is now subject to securities disclosure. In an announcement dated 4 November 2026, the company stated it had completed a business combination with Churchill Capital Corp XI, with shares expected to trade on Nasdaq under "AGLT" from 5 November 2026. In the same release it reported that its Digit robot had accumulated more than 65,000 hours of real-world operation, named GXO — which it said had recently expanded its agreement to deploy Digit at two additional US facilities — along with Schaeffler and Toyota Motor Manufacturing Canada, and a commercial agreement with AGCO to pilot Digit at its Hesston, Kansas facility beginning in 2027. It also reported more than $300 million in committed multi-year orders for Digit 5, stated as subject to contractual milestones, and described its RoboFab facility as designed to produce up to 10,000 robots annually.
Those qualifiers matter and are reproduced deliberately. Committed orders subject to milestones are not revenue. Design capacity is not production volume. And 65,000 hours across a period of years is a meaningful number that is also small relative to a single human workforce — one person working full time accumulates roughly two thousand hours a year.
Other well-funded programmes — including efforts at Tesla, Figure, Boston Dynamics, Unitree and 1X among others — are at varying stages, but their deployment claims are not subject to the same disclosure obligations, which makes them harder to evaluate on comparable terms. That asymmetry is itself worth knowing: a company that must file is a company whose numbers carry qualifiers.
What a first conversation with a manufacturer should cover
Before specifications, before pricing, and before anyone demonstrates anything:
- Scope. One robot model, one revision, one workflow with a measurable baseline. Anything broader cannot be validated and teaches nothing specific when it fails.
- Interfaces. Which are supported, which are documented, and which would break on the next firmware release.
- Constraints. Rated envelopes, duty cycles, thermal and power limits, and the conditions under which the platform expects software to stand down.
- Safety boundaries. Where the manufacturer's authority begins and ends, and which interlocks are non-negotiable. The correct answer involves very little being negotiable.
- Validation. What the manufacturer requires before considering an integration validated on its platform, and who performs that work.
- Acceptance criteria. Written before the work starts, by both parties.
- Failure ownership. When the task stops working, who triages, and what each side records to make that possible.
A manufacturer that engages seriously with those questions is more valuable than one with better specifications, because those are the questions that decide whether anything ships.
How to read any humanoid announcement
- Hours of operation, across how many machines, over what period?
- Is it a pilot, a paid pilot, or production work on a critical path?
- Orders, letters of intent, or revenue? And subject to what conditions?
- What is the intervention rate, and is a person supervising continuously?
- Is the task bounded, and would it fail safely?
- Design capacity or actual production?
- Is the customer named and have they confirmed it?
Apply that list to any announcement in this category, including an optimistic one from a company you like. The gap between a real deployment and an impressive one is almost always visible in the qualifiers.
Questions a vendor should be able to answer immediately
These are not difficult questions, and the speed and specificity of the answers is itself diagnostic. A platform team that has deployed will answer them without hesitation; one that has not will reframe them.
- How many units are currently operating outside your own facilities, and doing what?
- What is the mean time between interventions on those units, measured rather than targeted?
- What is the measured stopping time, including detection and reaction?
- Which interfaces are supported, and what is your policy on breaking them between releases?
- What is the lead time for a replacement unit, and for a replacement of the most commonly failing part?
- Which safety functions are rated, to what, and assessed by whom?
- Can I see the fleet view that shows software versions across machines?
- What happens to data generated on my site?
The risk nobody prices
Platform durability. A humanoid deployment involves integration work, environment modification, training and process change that are specific to that platform, and most of that investment does not transfer if the vendor changes direction, is acquired, or stops supporting the model you bought.
That is not an argument against buying from a young company — in this category almost every option is a young company. It is an argument for knowing what you would hold if the platform went away: whether your integration targets documented interfaces or undocumented ones, whether your capability layer is portable in principle, whether the environment changes you paid for remain useful, and whether you have the data and documentation to run or migrate without the vendor's help. Asking that question at purchase costs nothing and changes what you negotiate for.