Embodied Intelligence Begins Teaming Up to Build a Foundational Platform

Paradigm is turning PhanthyMotus from an open-source project into an ecosystem foundation jointly maintained by complete-machine manufacturers, platform companies, and developers.

In August, Paradigm held a launch event for the PhanthyMotus Ecosystem Community Co-Building Program, announcing that it would work with more than a dozen embodied-intelligence companies, including UBTECH, to jointly develop this cross-platform general-purpose embodied Agent framework. Compared with the unilateral release and open-sourcing of the framework in June, the message from this initiative is clearer: competition in embodied intelligence is beginning to shift from “who can build a robot that runs first” to “who can enable more robots to share a sustainable, continuously evolving software system.”

The value of this initiative does not lie in adding yet another robotics framework. Rather, it addresses the industry’s most practical bottleneck: hardware companies train and adapt their systems independently, ultimately producing a collection of intelligent capabilities that can only be demonstrated on a single robot model.

Robot Hardware Is Advancing Rapidly, but the “Brain” Has Not Kept Up

Over the past few years, robot hardware has evolved significantly faster. Humanoid robots, quadruped robots, drones, and robotic arms are entering an increasing number of real-world scenarios, while sensors, joint modules, and motion controllers are becoming more mature. But more flexible hardware does not mean that robots truly possess general intelligence.

Many public demonstrations already appear close to “autonomous operation”: robots can pick up objects, avoid obstacles, and even complete sequences of continuous actions. But when examined more closely, these systems often still rely on teleoperation, fixed scripts, preset points, and policy models trained for a single scenario. When switched to another robot model, or when a task is moved from the laboratory to a warehouse, shopping mall, or home, the success rate drops significantly.

The reasons are not mysterious. Different robots use different sensors, coordinate systems, actuators, and control interfaces. For a person, “Hand me the cup on the table” is a simple instruction. For a robot, the sentence must go through a long chain of transformations: first identifying the cup and the person, then understanding what “hand it to me” means, followed by path planning and grasp-pose selection, and finally translating the high-level decision into the movements of each joint.

If every hardware manufacturer builds the entire stack from perception, memory, and task planning to motion control independently, development costs become extremely high. More troublingly, these capabilities cannot be transferred naturally. One robot learning to organize shelves does not mean another robot can learn the same task directly.

PhanthyMotus’s entry point is to break this chain into relatively general-purpose software layers. Paradigm previously positioned it as a cross-platform general-purpose embodied Agent framework, attempting to provide robots of different forms with a unified “embodied brain.”

From “Open Source” to “Co-Building”: The Challenge Shifts from Code to Interfaces

When PhanthyMotus was released in June, it was already open source and proposed connecting hardware from different manufacturers, including humanoid robots, quadruped robots, drones, and robotic arms, to a unified intelligence platform. Its capability stack covers modules such as WAM, WM, VLM, and LLM. In simple terms:

• WAM (World Action Model): Connects environmental understanding with action execution, answering the question, “How should the robot move in this world?”
• WM (World Model): Maintains internal representations of the environment, object states, and task progress, helping the Agent predict the consequences of actions;
• VLM (Vision-Language Model): Maps what the camera sees to natural-language instructions;
• LLM (Large Language Model): Handles task decomposition, planning, tool use, and multi-turn interaction.

These terms themselves do not constitute a barrier. Nearly every robotics project today uses some form of vision model, language model, and motion policy model. The real difficulty lies in getting them to cooperate reliably within the same runtime and enabling deployment across devices.

Open source addresses the question of “whether others can view and use the code.” Co-building addresses whether “different participants can continue contributing according to the same rules.” Once complete-machine companies such as UBTECH join, the platform must deal with real hardware differences: different numbers of degrees of freedom, different end effectors, different sensor frequencies, different control latencies, and different safety constraints.

Therefore, the core focus of this ecosystem initiative is not the length of the participating-company list, but whether these differences can be consolidated into stable standard interfaces. A mature embodied Agent foundation must answer at least four questions:

1. How is hardware connected? Can robots expose their visual, positional, force-sensing, and execution capabilities through a unified API?
2. How are tasks described? Can developers describe cross-platform tasks using natural language or structured task definitions?
3. How are policies transferred? Can a policy trained on a quadruped robot be adapted and transferred to a robotic arm or humanoid robot?
4. How are failures handled? When recognition errors, grasp failures, or environmental changes occur, can the Agent fall back, replan, and leave traceable logs?

If these four layers cannot be delivered, the framework risks becoming merely a package for assembling models. If they can, it may have an opportunity to become the “operating-system layer” of the robotics industry.

An Embodied Agent Is More Than Connecting a Large Model to a Robot

Putting a large language model into a robot does not automatically produce embodied intelligence. Language models are good at processing symbols, knowledge, and task intent, but robots must act in a continuous, noisy, and uncertain physical world.

In a purely software-based Agent, if a model fails to call a tool, it can usually simply try again. In robotics, a failure may mean colliding with a shelf, breaking an object, or even causing a safety incident. The software world allows an output to be “not quite good enough”; the physical world requires actions to be controllable.

This is why PhanthyMotus discusses WAM, WM, VLM, and LLM within the same architecture. A large model can handle high-level task understanding, but it cannot directly control motors. Intermediate layers are still needed for world-state modeling, action policies, motion planning, and safety control.

The division of labor can be compared to a team: the LLM is like a project manager responsible for understanding “tidy up the conference room”; the VLM is like an on-site observer responsible for confirming what is on the table; the WM is like memory and a sandbox, recording which objects have been handled and which paths are blocked by obstacles; WAM and the low-level controllers are like the execution team, responsible for turning “tidying up” into a series of precise actions.

This division also offers a practical advantage: models can be replaced. Developers do not need to bind the entire system to one particular language model or vision model. As long as the high-level task protocol and low-level action interfaces remain stable, models can be upgraded as needed. For robotics companies, this is more important than chasing every round of large-model rankings.

Why More Than a Dozen Companies Need to Work Together

The word “general-purpose” in embodied intelligence is difficult for a single complete-machine company to achieve on its own.

Complete-machine manufacturers understand their own robots best, but usually cover only a limited range of hardware configurations and application scenarios. Model companies have algorithmic capabilities but may not understand joint control, real-time systems, or safety certification. Platform companies excel at toolchains and developer ecosystems, but need enough real devices to validate their interfaces. The interests of these three groups are not completely aligned, yet all of them need a common software foundation.

The significance of multi-party co-building is that it turns originally fragmented adaptation costs into shared infrastructure. Suppose every company maintains its own robot SDK. To support five types of devices, a developer would have to learn five sets of interfaces, write five sets of motion-adaptation logic, and separately debug, deploy, and monitor each system. If a unified foundation can provide device abstraction, task orchestration, simulation testing, and runtime monitoring, developers can shift from “adapting to each robot” to “designing transferable tasks.”

But this also means that the project must address the most difficult aspects of open-source ecosystems: how contributors collaborate, how versions remain compatible, how data is shared, and how responsibilities are divided. In robotics in particular, code, models, data, and hardware safety are four distinct layers that cannot be solved simply with a single Git repository.

The metrics that should genuinely be monitored as the ecosystem program develops include:

• How many real robots and simulators it supports;
• Whether it provides a stable hardware abstraction layer and sensor protocols;
• Whether it can offer reproducible training, evaluation, and deployment processes;
• How much task success rates and inference latency degrade after cross-platform transfer;
• Whether community-contributed modules can run on devices from different manufacturers;
• Whether it provides access control, emergency stops, and audit mechanisms for high-risk actions.

These metrics are more indicative of whether the project is moving toward infrastructure than the number of models it has released.

The Opportunities and Boundaries of an Open-Source Foundation

From an industry-trend perspective, PhanthyMotus’s choice to go open source and promote joint development among companies is a relatively pragmatic path. Embodied intelligence has not yet developed standards as mature as those in cloud computing, making it difficult for any single company to define all the interfaces independently. Releasing the framework, toolchain, and basic protocols first, then attracting hardware manufacturers to provide feedback, may make it possible to identify real problems more quickly than refining everything behind closed doors.

However, open source does not automatically create an ecosystem. The barriers to embodied intelligence lie not only in code, but also in data and hardware. Collecting real-robot data is expensive and involves large numbers of failure samples and safety boundaries. Different devices also produce inconsistent data formats, action spaces, and annotation methods. Without sufficient real-world operating data, a so-called general-purpose Agent can easily remain at the demonstration level.

Furthermore, success in a simulation environment does not mean stable execution in the real world. Changes in lighting, object friction, camera vibration, network latency, and temporary obstacles can all cause an apparently reasonable action sequence to fail. The foundation must give simulation, data replay, online monitoring, and failure recovery equal importance, rather than merely presenting a single successful demonstration.

Commercialization will also test the project’s degree of openness. Complete-machine manufacturers are usually willing to join because they want to reduce duplicated development and expand their application ecosystems. But they may also worry that their core data, customer scenarios, and control capabilities will become locked into the platform. PhanthyMotus therefore needs to draw a clear boundary between open interfaces and companies’ private capabilities: which modules must be shared, which data can remain local, and which capabilities manufacturers may differentiate. The clearer the rules, the easier it will be for the ecosystem to remain stable.

This Is Not the End Point of a “Robot Operating System”

At present, the more accurate assessment is that PhanthyMotus is in the early stage of transitioning from a framework into a platform. It has identified a real need: robot hardware is developing in a fragmented manner, while software capabilities need to be reusable. But whether a “general-purpose embodied Agent foundation” can ultimately become a reality will depend on whether it can move from a conceptual architecture into large-scale real-world deployment.

For developers, the most important things to watch are not the generality claimed in promotional materials, but three verifiable questions: First, is connecting new hardware genuinely faster than developing from scratch? Second, is the cost of transferring the same task across different robots low enough? Third, can the system be explainable, debuggable, and recoverable when failures occur?

If the answer is yes, PhanthyMotus could become an important connective layer in China’s embodied-intelligence ecosystem, allowing hardware manufacturers to avoid repeatedly building their own “brains” and giving developers the opportunity to reuse robot tasks like software services. If the answer is no, it may simply become another project that places vision models, language models, and control modules together.

What Paradigm is doing now is turning an open-source framework into a foundation jointly maintained by the industry. This path is slower and more difficult to coordinate than releasing a single model, but for an embodied-intelligence industry that remains at an early stage and has highly fragmented devices, it may be a direction more worthy of investment. The real competition will not be limited to whose robots move more like humans. It will also be about who can enable more robots to learn, collaborate, and continuously evolve in the same way.

Sources

• Zhihu: After Burning Through 93.5 Billion Yuan in Half a Year, Who Will Build the Foundation for Embodied Intelligence? — Further discussion of embodied-intelligence foundations, task success rates, and the industry’s need for infrastructure.
• Reference material: Paradigm’s announcement of the PhanthyMotus Ecosystem Community Co-Building Program — Factual basis for this article’s discussion of the launch event, participating companies, and the framework’s positioning.