Embodied intelligence has too many technical models and too few business models. Ask a company what it does and the answer is a technology label: models, bodies or data. Those labels slot a company into an industry map and sketch its team. Ask what exactly it sells, to whom, and why a customer keeps paying, and the answer is usually less clear than the technical positioning.
At a recent internal meeting, Figure went through a locked Figure 04 design, what Helix 3.0 will do, and how much its index data costs. On commercialisation it said nothing, while noting USD 2 billion of cash on the balance sheet.
A label with mixed parentage
Into that gap has stepped the deployment company. The members are a mixed group: teams building on open models, model companies rooted in one scenario, integrators connecting hardware, models and customers, and data companies that have started writing deployment into their positioning. Mixed origins do not make deployment a pumped-up narrative. What the term describes is solution-style delivery, with each player finding the posture that fits its own background. The point is to push technology into commercial territory.
Model capability is also being handed over as a service. Physical Intelligence opened an API beta, and Dream Labs launched Dream-1, callable through an API. Some providers supply general capability, others run business around specific tasks, and an interface where research and use can transact has appeared between them.
Both moves point at the application layer, and at a division of labour on the delivery side. Model companies, body companies and data companies used to sit in separate lanes or in a simple chain, which is normal for an early industry. As the industry matures, embodied companies are starting to define themselves by how they make a business.
Not a new segment, a new posture
Deployment is not a new slice of the chain so much as a business model that companies adopt, sometimes by choice and sometimes by force. A team that understands a process can buy models and hardware and integrate them. A model company can go deep into one task on site. A data company can extend from collection through post-training and evaluation into delivery. The pricing differs. The common thread is organising capability around a real requirement and taking responsibility for the result.
The clearest example sits with data companies. Varun Nair, a researcher and investor in physical AI, argues in his work on embodied data scale-up that physical AI gives post-training specialists a rare opening to become an application layer as well, and that the best data companies will end up as deployment companies.
That pushes the value of a data firm past the dataset. A delivery used to end when a batch of training material met spec. Inside a real scenario the supplier has to understand which variations affect task success, which failures deserve more collection, and whether new data actually improved the robot. Following those questions leads into model adaptation, performance evaluation and on-site operation. Capability built to help a customer train a model becomes capability to help a customer finish work.
Mecka has written that into its positioning, calling itself the data and deployment layer for physical AI and an integrator linking hardware, models and commercial customers. For companies without a robotics team, it bundles hardware, data collection, post-training, systems integration and continuing operations, and insists that data gathered on site keeps improving the system after go-live. In China, Guanglun Intelligence builds continuous-learning infrastructure around data, simulation, evaluation and deployment feedback, carrying failures from live operation back into the next iteration.
The extension is not automatic. Owning data is not enough. A company also needs field engineering, customer service and operations before it can carry deployment responsibility.
The arithmetic is starting to exist
Several commercial shapes are visible. A data company sells scenario data and then charges a deployment fee, taking both layers. Sunday Robotics charges a low subscription and pulls data back to train models, trading cheap access for a high-value position later. AgiBot runs an ecosystem in which bodies go to industrial and commercial projects, a rental arm serves consumers, and data is collected and sold through a separate unit.
The API route made part of the relationship concrete. On 13 October Physical Intelligence opened its API beta: developers upload their own data, fine-tune on compute and infrastructure managed by the company, and run inference through a hosted service. Collection, training, on-machine testing and improvement from failure become a process an outside team can run itself.
Dream Labs, fresh from a USD 90 million seed round, published a runtime price of USD 3 per hour for Dream-1, and reported that within 24 hours of launch it had controlled 31 robot types it had never seen across 53 countries, with more than 372,000 inference calls. The product is early, but the cost of capability and the way to estimate it are now legible.
For application companies that changes the arithmetic. A team working in catering, manufacturing or material handling can buy general capability and concentrate its spending on task adaptation and on-site delivery. Model research, infrastructure and application development no longer have to sit inside one balance sheet.
Why deployment stays inside the loop
Practitioners give a more complicated answer than the pitch decks. Deepak Pathak, co-founder and chief executive of Skild AI, has reflected on his own early assumption that he could build a general robot platform and leave deployment to others. In reality, he says, deployment is deeply part of the research cycle, and while the technology is still growing it is hard to hand that work away entirely.
Robots meet materials the training set never covered, encounter changes in cycle time, and expose in continuous operation problems a single demonstration never shows. Some of those need a process change, some need more data, and some go back into the model and the system. Field feedback decides what to research next, and research decides what can be delivered next.
That puts a requirement on model providers as well. Whether an outside team can get diagnosis and improvement support, whether it has tools to adapt the model, and whether failure experience turns into capability, all decide whether a developer can keep going. Releasing a model and pushing every remaining problem downstream is not a mature product supply.
Physical Intelligence’s API announcement shows how this can progress. The Almond team spent four days iterating until its dual-arm robot Axol had a model for deburring parts it assembles itself. Physical Intelligence also showed an Actor autonomous loader working on a commercial site. Each case has its own conditions, but together they show that some capability is already sufficient for a specific task without waiting for every general problem to be solved.
Take one class of work, prove value inside defined conditions, then use what was learned to widen the boundary. The identity of an embodied company will get harder to summarise as model, body or data. The business should get easier to explain: who pays, what problem was solved, and whether revenue supports continued delivery and improvement.
Editor’s note: This is an adapted translation of the original OFweek report. It has been trimmed and restructured for readability for an international business audience. The full original (in Chinese) is at https://robot.ofweek.com/2026-10/ART-8321205-8420-30708835.html.