Buying a humanoid robot means evaluating a working system, a supplier relationship, and an implementation project. The machine is only part of the decision. A platform that performs well in a demonstration may still need task development, facility changes, supervision, or a commercial agreement tailored to a particular application.
The market includes commercial deployments, limited-access programs, pilot systems, pre-production products, and research platforms. Product generations and supported capabilities also change. A sound buying decision therefore tests two things together: whether the robot can perform your work, and whether the manufacturer can deliver and support that application on acceptable terms.
This guide provides a practical evaluation framework. It is not a ranking or a claim that one platform suits every buyer. Manufacturer statements below are attributed to their sources; the worksheets and procurement questions are editorial tools for your own assessment.
Go directly to: task requirements, technical evaluation, commercial readiness, deployment cost, pilots, or the comparison framework.
Start With the Work You Need Done
Replace “Which humanoid robot is best?” with a description of the work. “Support warehouse operations” is too broad. “Transfer closed totes from a defined collection point to a conveyor, with exceptions routed to an operator” is a useful starting brief.
Observe the current workflow before writing requirements. Record object variation, cycle frequency, travel distance, required movements, handoffs, interruptions, and the people sharing the area. Capture busy periods and awkward cases, not just an orderly demonstration of the task.
- Task: What starts the job, what actions follow, and what confirms successful completion?
- Environment: What floor, lighting, access, weather, and human-traffic conditions apply?
- Workload: What volume, schedule, peak demand, and required uptime must be supported?
- Physical requirements: Which objects, weights, surfaces, reaches, grips, and placements are involved?
- System requirements: Which machines, software, approvals, and operational signals are needed?
- Deployment goal: Are you testing feasibility, relieving a bottleneck, or preparing a repeatable production process?
Separate essential requirements from desirable future capabilities. Document who will verify each requirement. Our sourcing process starts with this application context because it makes later conversations more specific.
Is a Humanoid Robot the Right Form Factor?
A human-shaped platform may be relevant where workstations, containers, doors, tools, and equipment interfaces were designed around human height and reach. Legs may be useful where the route genuinely requires stepping or stairs. These are reasons to investigate a design, not proof that a particular robot can use every human space.
Compare the complete task with alternative automation. Fixed machinery may suit a stable, high-volume process. A robotic arm may handle work within a bounded station. Autonomous mobile robots (AMRs) or automated guided vehicles (AGVs) may address transport without needing hands. A purpose-built mobile manipulator may combine transport and handling without a bipedal body.
Ask what the humanoid form enables that a simpler system cannot achieve economically or operationally. Include any fixtures, route changes, or workflow redesign in both proposals. Choosing the right form factor strengthens the project even if the first task ultimately uses another kind of automation.
Evaluate Application Fit Before Specifications
An industry label does not establish suitability. The useful unit of comparison is the task within that industry. These are evaluation questions, not claims of broad humanoid deployment:
- Manufacturing: Can the platform handle the relevant parts, placement tolerances, station timing, and machine handshakes?
- Warehousing and logistics: Which tote, carton, picking, or transfer variations are supported, and how are exceptions handled?
- Construction and agriculture: Has performance been evaluated on the actual terrain, changing layouts, dust, moisture, and outdoor conditions?
- Healthcare, hospitality, and retail: What restrictions apply around patients, visitors, hygiene, privacy, and unpredictable public interaction?
- Research and education: Are the documented interfaces, developer access, repair options, and experimental permissions adequate?
- Mining and energy: Is the equipment explicitly suitable for the site’s environmental and hazardous-area requirements?
Use our industry application pages for context, then narrow the discussion to a documented workflow. An indoor handling demonstration should not be treated as evidence of outdoor, clinical, or hazardous-environment readiness.
Understand the Type of Humanoid Platform
HRD groups platforms into General Purpose, Industrial, Logistics & Warehouse, Commercial & Service, Research & Development, Healthcare, Construction, and Other / Emerging categories. These are discovery labels, not certifications or guarantees of supported tasks.
General-purpose positioning expresses a broad design ambition; a commercial offering may initially support only a narrow workflow. An industrial or logistics design may prioritize repeatable handling. A research platform may emphasize programmability while expecting the buyer to supply substantial engineering effort. Healthcare or construction positioning still requires application-specific verification.
When browsing the Humanoid Robot Directory, read the type alongside commercial status, current documentation, and the exact configuration. Ask which functions are delivered today and which belong to a development roadmap.
Mobility: Can the Robot Move Through Your Environment?
Map the complete route: aisle widths, turning areas, ramps, thresholds, floor transitions, obstructions, and any stairs. Record whether doors or elevators require interaction, authorization, or integration. An indoor rating or a level-floor trial does not resolve outdoor exposure or uneven-ground requirements.
Maximum walking speed is less useful than reliable travel while doing the job. Request a supervised evaluation of the intended load, route, stopping behavior, and repositioning at the workstation. Ask how the robot responds when a route is blocked, an object is misplaced, or localization is interrupted.
Also establish the recovery procedure. Who clears an obstruction? Who authorizes restart? Can the robot resume the job, or must an operator reset the sequence? Keep fall and recovery scenarios within a manufacturer-approved test plan and the site’s safety assessment. Do not improvise physical challenges around employees.
Manipulation: Hands, Grasping and Tool Use
Finger count, reach, and payload describe only part of handling capability. The relevant question is whether the complete robot can identify, grasp, move, orient, and release your objects consistently. Slippery packaging, flexible bags, handles, fragile parts, and poorly presented items create different requirements.
Evaluate two-handed work, tool compatibility, tactile sensing, placement precision, and the ability to recover from an unsuccessful grasp. Ask whether a task requires a special gripper, fixture, training data, or software development. Include tool weight and the effects of gripping force on the object.
NIST’s end-effector benchmarking research treats grasp strength, cycle time, finger strength, and repeatability as distinct measures. For buyers, the practical lesson is to request task evidence rather than infer dexterity from a photograph of a hand. Test a representative object set and record failed attempts as well as completed cycles.
Payload: Look Beyond the Maximum Number
Confirm what a published payload means. It may describe a whole-body carrying limit, an arm limit, or a handling capacity under specified conditions. Those figures are not automatically interchangeable.
Ask for the allowable load in the intended posture and grasp, including tools and accessories. A compact object held close to the body differs from an awkward load held at reach. Shape, balance, distance, acceleration, repeated handling, and task duration should all appear in the evaluation.
Use actual object measurements and an agreed test procedure. Record the practical operating range and restrictions, not only the highest load shown once. Similar headline payloads can mask different usable capabilities, especially when carrying and precise placement must happen within the same cycle.
Runtime, Charging and Shift Coverage
Plan the full operating cycle: productive work, travel, waiting, charging or battery exchange, checks, and recovery. A hypothetical five-hour runtime rating does not mean five hours of uninterrupted productive output. Ask what workload and test conditions produced any quoted runtime.
Charging arrangements are platform-specific. They may involve docking, a cable, battery swapping, or inductive charging. For example, Figure’s Figure 03 announcement describes wireless inductive charging. That establishes a manufacturer-described design feature, not the time your workflow will spend charging or its achievable shift output.
Request a shift plan that includes charger location, power requirements, docking access, battery condition, queueing if several robots share infrastructure, and who handles charging failures. Determine whether charging can coincide with natural pauses and how the operation continues while the robot is unavailable.
Software, AI and Autonomy
Describe autonomy at the task level. A robot may execute a trained sequence independently while needing a person for setup, unusual objects, recovery, or a new workflow. Language interaction does not by itself establish dependable physical task execution.
Ask whether a demonstration used teleoperation, scripted actions, remote assistance, or autonomous control. Request the intervention log, not just an edited video. Distinguish a person observing from a person approving actions or directly controlling motion.
Review vision requirements, learning methods, available APIs and SDKs, fleet-management tools, and the effort needed to add a task. Have IT examine network dependency, access controls, data retention, video handling, and remote-support permissions. Establish what remains functional if connectivity is lost and how software updates are tested before they enter your production workflow.
Integration With Your Existing Operation
Map how a job reaches the robot and how completion is reported. Warehouse management systems (WMS), manufacturing execution systems (MES), and enterprise resource planning (ERP) systems may play different roles. Machines, conveyors, doors, elevators, tools, and safety systems may each require their own interface.
Agility describes its Arc platform as connecting Digit with compatible warehouse automation and management systems on its official solutions page. Compatibility is the important qualifier. Buyers should verify their specific system versions, interfaces, and required engineering rather than assume a named integration covers every installation.
Assign an owner to each interface and exception. If a conveyor stops or a receiving station is full, what tells the robot to wait, reroute, or hand over? Include commissioning, acceptance testing, documentation, and rollback procedures in the statement of work. Delivery of hardware is not completion of integration.
Safety and Human-Robot Interaction
Bring the site’s safety team and a qualified integrator into the evaluation early. OSHA’s industrial robot safety guidance emphasizes risk assessment of the application, including operation, programming, maintenance, and foreseeable hazards. Review human proximity, operating boundaries, dropped loads, trapping points, emergency stops, recovery, training, and control of hazardous energy.
A humanoid appearance or a collaborative marketing claim does not establish that unrestricted operation near people is acceptable. Ask for the safety documentation supporting the exact configuration and task, then validate the proposed safeguards before operation.
ISO 10218-1:2025 addresses industrial robot safety and points to Part 2 for integration and applications. Its scope contains exclusions, including mobility on mobile platforms and certain public-access uses. It is not a universal humanoid certification. The applicable standards and legal obligations depend on the machine, application, jurisdiction, and environment; have competent specialists determine them.
Commercial Readiness May Matter More Than the Demo
HRD’s status labels help organize research. Confirm the underlying evidence and date for each platform:
- Commercially Available: A commercial route exists, subject to the supported configuration, application, territory, and supplier terms.
- Limited Availability: Access is constrained, for example by customer selection, geography, allocation, or supported use cases.
- Pilot / Early Access: Access is centered on evaluation or early deployment programs with specific conditions.
- Pre-Production: The platform is being prepared for production; a delivery commitment still needs verification.
- In Development: Development activity or demonstrations do not establish a deliverable commercial offer.
- Research Platform: The product supports experimentation and may require substantial buyer engineering.
Keep evidence categories separate. Publicly announced describes a statement. Demonstrated describes an observed capability under particular conditions. Piloted describes an evaluation. Commercially deployed describes use under a commercial arrangement. Available for purchase requires an actual offer to an eligible buyer. None automatically proves the others.
Agility reports a multi-year commercial Digit deployment at GXO. That is a specific deployment example, not evidence that every buyer can obtain the same workflow or terms. Request written confirmation of regional access, current supported applications, production allocation, lead time, support, and pricing visibility.
Evaluate the Manufacturer as Well as the Robot
Assess the supplier’s documentation, production capability, product history, software ecosystem, and support organization. Ask which entity contracts with you, who integrates the system, and who is responsible when a fault crosses those boundaries.
Check parts availability, maintenance intervals, repair arrangements, training, warranty exclusions, and support coverage for your location. Request relevant customer references where available. Separate a planned factory capacity from delivered units and a product roadmap from contractual support commitments.
Generation changes deserve particular care. BMW’s June 25, 2026 announcement distinguishes its completed Figure 02 body-shop pilot from the Figure 03 logistics sequencing project it was starting. Evidence from the earlier generation should not silently become a performance claim for the successor.
The Figure 03 profile and Figure AI profile provide contextual research routes, not an endorsement or a general purchase recommendation. Use the broader manufacturer directory to organize supplier research.
How Much Does a Humanoid Robot Cost?
There is no useful universal price for a humanoid deployment. Public pricing is not consistently available, and an application-specific quotation may be required. An advertised hardware figure, where available, should not be treated as an installed and supported system price.
Request an itemized offer covering configuration, pilot fees, shipping, installation, charging equipment, software, integration, training, service, maintenance, spares, and engineering. Clarify which items are included, optional, recurring, usage-based, or the buyer’s responsibility.
Also distinguish purchase from subscription or Robotics as a Service (RaaS). Agility’s documented GXO arrangement illustrates the latter model; it does not establish another supplier’s pricing or contract terms. Compare offers over the same operating period and workload, including renewal, usage limits, and exit costs where applicable.
Treat price discovery as part of a scoped commercial inquiry, with explicit assumptions and exclusions. Use the cost worksheet below to organize the complete deployment budget.
Calculate Total Deployment Cost, Not Just Robot Price
Build a cost worksheet before requesting final quotations. Keep one-time costs separate from recurring expenses, and mark unknowns instead of inserting optimistic estimates.
| Cost area | What to include or clarify |
|---|---|
| Robot and configuration | Hardware or subscription, hands, tools, accessories, freight, taxes, and applicable import costs. |
| Integration and engineering | Task development, system interfaces, testing, commissioning, and documentation. |
| Infrastructure | Charging, power, networking, fixtures, layout changes, and required safeguards. |
| Software | Licences, fleet tools, connectivity, updates, and usage-dependent charges. |
| Training and internal time | Operations, engineering, IT, safety, procurement, and change-management effort. |
| Support, maintenance and spares | Service coverage, wear parts, batteries, repair shipping, and replacement arrangements. |
| Pilot and contingency | Evaluation fees, supervision, temporary equipment, downtime, and a fallback operating process. |
Compare the resulting operating cost with measured useful output, such as accepted transfers or completed tasks. Include intervention time and rejected work. Run conservative and expected scenarios using your own observations. A convincing business case makes uncertainty visible; it does not depend on a universal payback promise.
Why a Pilot May Be the Best First Step
A pilot tests the gap between a promising demonstration and your operating reality. Availability depends on the manufacturer, platform, application, region, and commercial program. Access should never be assumed.
Agree on the scope and acceptance criteria before equipment arrives. Use representative objects, shift conditions, lighting changes, interruptions, and human interactions within an approved operating plan. Define what constitutes a completed task and who records the result.
- Task completion: Accepted completions divided by attempted tasks, with rejected work recorded.
- Interventions: Frequency, cause, duration, and skill level needed for human assistance.
- Availability: Time ready for the agreed work, with charging, planned stops, and faults reported separately.
- Throughput: Useful output over the full observation period, including waiting and recovery.
- Operational burden: Staff time, integration issues, service response, and remaining restrictions.
Agility’s published deployment process distinguishes controlled workflow validation, on-site validation, and an operational pilot. It is one supplier’s model, not a universal program. For your project, agree in advance whether the outcome leads to expansion, further testing, redesign, or a stop.
Questions to Ask Before Moving Forward
Send a written questionnaire so answers can be compared and converted into requirements:
- What is this model’s current commercial status, regional availability, and expected lead time?
- Which applications and configurations are supported today, and which are still planned?
- What payload, reach, runtime, and charging assumptions apply to our exact workflow?
- Which actions are autonomous, and when are teleoperation or human supervision required?
- Which APIs, SDKs, system integrations, and network services are available to us?
- What facility changes, safety documentation, and operator training are required?
- Who handles maintenance, repairs, replacement parts, and escalation in our region?
- What support is included, and what response or restoration commitments are offered?
- What demonstration or pilot options exist, with what fees and acceptance criteria?
- How are software updates approved, validated, rolled back, and supported over time?
- What costs and responsibilities sit outside the robot quotation?
Ask suppliers to distinguish documented limits from estimates. Record the model, software version, configuration, source, and date beside every material answer.
Questions Your Organization Should Answer
Supplier readiness cannot compensate for an unowned internal project. Identify an operational owner with authority to coordinate engineering, IT, safety, finance, and procurement.
- What problem are we solving, and which task should be addressed first?
- What measurable result would justify continuing beyond evaluation?
- What budget and internal staff time are available?
- Who owns integration, charging arrangements, maintenance, and daily operation?
- How will employees be trained and involved in evaluating the workflow?
- What happens when the robot cannot complete a task or is unavailable?
- Do we need a pilot, and what timeline is realistic for each decision stage?
Write down the fallback process before the pilot. It makes the evaluation safer to schedule and prevents an experimental deployment from becoming an unmanaged production dependency.
How to Compare Humanoid Robots
Use one requirements sheet for all shortlisted platforms. Apply essential constraints first, then compare advantages. A platform that fails an essential site requirement should not win because it has a higher headline specification elsewhere.
NIST’s performance assessment framework examines perception, mobility, dexterity, and safety in relation to robotic task performance. Our worksheet applies that task-centered approach to a buying conversation, while adding commercial and support questions. It is an editorial framework, not a NIST certification or test standard.
| Evaluation area | Comparable evidence |
|---|---|
| Application fit | Completion of your defined task with representative objects and conditions. |
| Commercial status and availability | Current program, region, configuration, delivery terms, and restrictions. |
| Payload and manipulation | Usable loads, reach, grip, precision, and repeated handling results. |
| Mobility | Loaded route performance, turning, transitions, stopping, and recovery. |
| Runtime | Workload-specific operating cycle and charging plan. |
| Autonomy | Supported behaviors plus an intervention and supervision record. |
| Integration | Documented interfaces, delivery responsibilities, and commissioning scope. |
| Safety and support | Application documentation, training, service coverage, and repair arrangements. |
| Pricing visibility | Comparable commercial offers with inclusions, exclusions, and recurring charges. |
Mark each entry as documented, observed in your test, supplier-estimated, or unknown. This evidence record is more useful than a single score that hides uncertainty. Recheck it when the model or software changes.
Explore Humanoid Robots to begin a shortlist, then verify the current commercial details directly.
Common Mistakes to Avoid
The most expensive mistake may be selecting a platform before defining a workable first task. Other recurring decision traps include:
- Treating a demonstration, announcement, or pilot as proof of general availability.
- Comparing only maximum payload, speed, or runtime without test conditions.
- Budgeting for hardware while omitting integration, supervision, maintenance, and support.
- Assuming one successful workflow proves suitability for every department.
- Using old specifications or transferring evidence between product generations.
- Calling a pilot successful without measuring failed tasks, interventions, or operational burden.
Keep claims and evidence together throughout the decision. A candid limitation from a supplier is useful information, especially when it helps define a feasible first deployment.
A Practical Humanoid Robot Buying Process
- Define the first application and the problem it should solve.
- Document task, site, workload, and system requirements.
- Research platforms and alternative forms of automation.
- Compare technical capability against the same requirements.
- Check current commercial readiness and regional access.
- Evaluate manufacturers, integrators, and support arrangements.
- Estimate deployment cost, including internal effort.
- Request current commercial information and clarify exclusions.
- Consider a demonstration or pilot with agreed success measures.
- Plan integration, safeguards, training, and fallback operation.
- Evaluate pilot results against the original acceptance criteria.
- Move toward procurement only when the remaining requirements and commitments are acceptable.
Use the HRD sourcing process to organize the next conversation. Where appropriate, the outcome may be further research or a narrower task rather than an immediate purchase.
When to Request Sourcing Help
You do not need to have selected a robot before making an inquiry. A useful brief describes the application, industry, location, operating environment, anticipated quantity, timeline, critical requirements, and budget context. Identify unknowns honestly.
Share enough detail to separate essential needs from exploratory interests. If you already have a shortlist, include the unresolved questions rather than asking only for a price. Current availability, supported tasks, and commercial programs can then be considered alongside the technical requirements.
Request Sourcing Help with the application brief you have today.
Choosing the Right Humanoid Robot
There is no universally best humanoid robot. The right platform is the one whose demonstrated capabilities, commercial access, integration requirements, supplier support, and deployment economics fit a defined task in a defined environment.
A disciplined process turns an interesting machine into an assessable project. Start small enough to measure, demand clear evidence, and expand only when the operating results support the next step.
Explore Humanoid Robots or Request Sourcing Help with your application requirements.
