Physical AI companies build different parts of the system that lets machines perceive, decide and act in the real world. Some develop simulators and synthetic data tools. Others train generalist robot models, manufacture humanoids or specialized robots, supply actuators and sensors, or integrate complete workflows at customer sites.
A useful company map begins with the product and responsibility, not a fashionable label. A foundation-model developer and a warehouse integrator may both describe Physical AI, yet their revenue, technical risks and evidence look different. The same company can also span several layers through partnerships or internal development.
This guide complements the overview of what Physical AI means and the humanoid robot categories. It is an evaluation framework, not an investment ranking. Company status, products and partnerships can change quickly and require current primary-source checks.
The ecosystem starts with simulation and data
Simulation companies and platforms provide virtual robots, environments, physics, sensors and testing workflows. Data infrastructure captures demonstrations, trajectories, failures and labels. These layers reduce the cost of experimentation, but their value depends on how well simulated or collected evidence transfers to the target robot.
NVIDIA’s Isaac platform spans simulation and robot development, while open tools and datasets support research across vendors. Compare supported robot formats, sensor models, deployment workflow, license, reproducibility and integration rather than counting the number of downloadable scenes.
Foundation-model companies build reusable robot policies
Robot foundation-model developers train systems across tasks, environments or embodiments. Their products may accept images, language and robot state, then output actions or reusable representations. The commercial offer can be model weights, an API, training services, data collection or a complete software stack.
Examples of the research direction include Google DeepMind Gemini Robotics, Physical Intelligence pi0 and NVIDIA GR00T. Compare public evaluation, supported action spaces, adaptation data, inference requirements and the boundary between a model demonstration and a deployable controller.
Robot manufacturers own the physical platform problem
A robot maker must integrate mechanics, actuators, power, sensors, compute, controls and safety into a serviceable machine. Humanoid manufacturers pursue general mobility and manipulation in human-designed environments, while industrial arms, AMRs and specialized machines optimize narrower workflows.
Companies such as Figure, Boston Dynamics and Agility Robotics publish different product and deployment evidence. Compare intended environment, payload, runtime, autonomy, human involvement, fleet size and customer operation rather than appearance.
Component suppliers determine performance ceilings
Motors, gearboxes, encoders, force sensors, batteries, cameras and compute modules shape torque density, precision, runtime and cost. A manufacturer may design its own joint module while buying critical components. Supplier qualification, lead time and manufacturability become as important as prototype specifications.
The humanoid actuator industry guide maps that layer in detail. When a company claims a breakthrough robot, ask whether the enabling component is production-ready, available at scale and integrated with thermal, structural and control requirements.
| Ecosystem layer | Primary output | Core evidence | Typical risk |
|---|---|---|---|
| Simulation and data | Scenes, trajectories and labels | Transfer and downstream utility | Reality gap |
| Foundation models | Reusable perception-action policy | Held-out task and hardware results | Coverage and latency |
| Robot platforms | Integrated physical machine | Repeated autonomous operation | Reliability and cost |
| Components | Motors, sensors, compute and power | Qualified specifications and supply | Integration and scale |
| Deployment | Working customer workflow | Sustained operational metrics | Exceptions and support |
Integrators turn capabilities into workflows
System integrators connect robots to fixtures, conveyors, WMS or MES software, safety systems and operator procedures. They define the process boundary, handle exceptions and perform acceptance testing. A robot with strong manipulation can still fail commercially if the surrounding workflow is not redesigned.
Deployment companies may sell a project, subscription or outcome-based service. Compare who owns site preparation, uptime, software updates, spare parts, remote assistance and recovery. The contract should match the technical boundary measured during the pilot.
The ecosystem map prevents false peer comparisons
A model provider can scale software without manufacturing thousands of robots, while a hardware company carries inventory, certification and service obligations. A simulator may gain adoption through developer usage rather than robot revenue. These businesses require different metrics and timelines.
Classify the company’s primary deliverable, customer, dependency and recurring responsibility. Then identify adjacent layers it controls or partners for. Vertical integration can reduce interfaces, but it also concentrates capital needs and operational risk inside one company.
Demo evidence should be separated from deployment evidence
A continuous uncut task shows that a capability can occur. Repeated trials show reliability within a test distribution. Customer operation adds shift length, maintenance, changing inventory, people and business constraints. Each evidence level is useful, but they should not be presented as equivalent.
Use the robot video evaluation checklist to inspect editing, teleoperation, speed and task setup. Strong company reporting discloses interventions, failures, operating hours and the denominator behind success rates.
Operating metrics reveal the real product
For deployed robots, measure autonomous task coverage, verified throughput, intervention rate, uptime, damage and safety events. Include the customer process before and after the robot. A fast laboratory motion may not increase output if replenishment, verification or exception handling becomes the bottleneck.
Fleet size should distinguish prototypes, paid pilots and production systems. Operating hours need definitions for planned downtime and supervised testing. Customer names can validate market access, but technical evidence still requires task scope and sustained results.
| Claim | Evidence to request | Misleading shortcut |
|---|---|---|
| General-purpose | Performance across defined task families | Many scripted demos |
| Autonomous | Intervention taxonomy and rate | Ignoring setup and resets |
| Production-ready | Uptime, service and acceptance data | Prototype appearance |
| Lower cost | Total workflow cost per verified outcome | Robot price alone |
| Scalable | Manufacturing, deployment and support capacity | A large announcement |
Business-model questions follow technical responsibility
Hardware sales recognize revenue differently from subscriptions, licensing or Robotics as a Service. A recurring model may include maintenance and software, but it also creates service obligations. Gross margin cannot be interpreted without understanding installation, remote operation and field support.
The RaaS guide explains responsibility and service-level questions. For every offer, identify who owns the robot, integration, data, updates, consumables, downtime and end-of-term removal. A monthly price does not define the actual risk transfer.
Build a living company watchlist
Record each company by layer, product, supported tasks, announced customers, deployment evidence, funding or ownership only when primary sources are current. Add the date and link for every claim. Partnerships, model releases and robot specifications can change faster than an annual market map.
Avoid treating the watchlist as a recommendation. It should expose unanswered questions and evidence maturity. Update a company when it publishes a model card, safety document, customer acceptance result or reproducible benchmark, not only when it releases a promotional video.
- Classify the company's primary ecosystem layer.
- Identify the exact deliverable and customer.
- Separate model, robot and workflow evidence.
- Require denominators for deployment metrics.
- Date every claim and recheck primary sources.
Frequently asked questions
What counts as a Physical AI company?
A company can qualify when it builds a material part of the perception-action system, including simulation, robot data, models, hardware, components or deployment. The layer should be stated explicitly.
Are all Physical AI companies humanoid-robot makers?
No. Humanoids are one segment. Industrial robots, mobile robots, autonomous vehicles, component suppliers, simulators and model developers can all participate.
How should private robot companies be compared?
Use primary product documents, customer deployments, technical evaluations and disclosed operating metrics. Funding and valuation do not substitute for evidence of task performance.
What is the most important deployment metric?
Use verified task output with coverage, intervention, uptime, safety and total workflow cost. No single motion or model metric describes the complete product.
How often should a company list be updated?
Check whenever a major product, model, customer deployment or business change occurs, and date every entry. Fast-moving early markets make undated rankings unreliable.
Company and Market Note
Company products, partnerships, financing and deployment status can change quickly. Verify every current claim from primary sources and treat this ecosystem map as an analytical framework, not investment advice.