By Shaoshan Liu
When people discuss the future of embodied AI, the conversation often jumps directly to the most visually compelling destination: a general-purpose humanoid robot capable of performing almost any task designed for a person. That vision is understandable. The physical world is built around the human body, and a machine that can use our tools, navigate our spaces, and work alongside us would be extraordinarily valuable.
But a destination is not the same thing as a development path.
In my Communications of the ACM article, “An Evolutionary Path for Embodied Robotics,” I contrasted two ways of thinking about how robotics may advance. One is creationist: first define an ideal general form, then attempt to engineer all required capabilities into it. The other is evolutionary: allow multiple robotic forms to develop in response to specific applications, economic constraints, deployment scale, and the data generated through real use.
I believe the evolutionary path offers the more credible route from today’s demonstrations to broadly useful embodied AI. It does not reject humanoid robots. Rather, it treats any eventual convergence toward humanoid capabilities as a possible result of technical and market selection – not as an assumption that must govern every step from the beginning.
AIRSEAI is our attempt to turn that idea into an open engineering program.
The project is being developed in three stages. These are not simply version numbers or a sequence of increasingly impressive hardware. Each stage represents a different evolutionary pressure and addresses a limitation revealed by the stage before it.
Stage One: Build a Reliable Organism Before Pursuing Generality
AIRSEAI 1.0 began with a deliberately constrained embodiment: a single-arm mobile platform supported by modular navigation, LLM-assisted high-level task planning, failure-aware replanning, and simulation-based validation.
Why begin there rather than with a full humanoid?
Because useful intelligence depends on a closed and dependable interaction loop. A robot must interpret a task, perceive the environment, select and execute actions, detect when an assumption has failed, and revise the plan. If this loop is unreliable, adding more joints, sensors, or model parameters usually increases complexity faster than capability.
AIRSEAI 1.0 therefore focused on system composition. Its ROS 2 architecture separated the principal modules so that navigation, planning, perception, and control could evolve independently. Replanning was treated as a core capability rather than a patch applied after failure. Simulation was used not only to produce demonstrations, but to create a repeatable environment for validating system behavior before deployment.
This first stage reflects a basic evolutionary principle: survival precedes specialization. Before a robotic platform can expand into more complex forms, it must establish a stable way of sensing, acting, failing, and recovering.
Stage Two: Expand Physical Capability in Response to Real Tasks
AIRSEAI 2.0 moves from a single arm to the OPENARMS dual-arm platform and from a primarily planner-driven system toward a standardized, data-driven manipulation pipeline.
This transition is not based on the belief that more arms automatically produce more intelligence. It is driven by the structure of real tasks. Many activities in homes, laboratories, service settings, and industrial environments require one hand to stabilize while the other manipulates; coordinated lifting; opening containers; handling flexible objects; or responding to contact that vision alone cannot fully describe.
Dual-arm manipulation is therefore a capability selected by application demand.
AIRSEAI 2.0 also addresses three software and data limitations exposed by the first stage.
First, the project moves from dependence on a fixed “single brain” toward an elastic model zoo. Embodied tasks differ greatly in their perception, reasoning, control frequency, and computational requirements. There is little reason to expect one model to be best for every task and every platform. AIRSEAI therefore uses modular interfaces that allow models and policies to be exchanged, evaluated, and improved without rebuilding the entire system.
Second, evaluation shifts from asking only whether a robot succeeds on a familiar task to asking where and why its capability breaks down. Benchmarks can become saturated while concealing brittleness. AIRSEAI 2.0 emphasizes challenging evaluation and explicit analysis of the simulation-to-reality gap. The objective is not to produce the most flattering aggregate score, but to identify the boundary beyond which the system can no longer reason or act reliably.
Third, AIRSEAI 2.0 replaces ad hoc data handling with a full loop: collect, train, fine-tune, evaluate, and deploy. Data quality and consistency ultimately limit model performance. A reproducible pipeline makes it possible to compare models, reuse demonstrations, align multiple sensing modalities, and feed deployment experience back into the next training cycle.
Vision-based tactile sensing is another part of this evolution. When robots manipulate objects, contact is not an exception; it is the task. By allowing the robot to observe deformation, force distribution, texture, edges, and slip at the fingertip, tactile sensing adds information that distant cameras cannot provide. This is a good example of evolutionary specialization: the system gains a new sense because the environment and the task require it.
Stage Three: Evolve Beyond the Individual Robot
AIRSEAI 3.0 extends the project from individual capability toward collective adaptive intelligence among heterogeneous robots.
This stage may appear to be a large leap, but it follows directly from the evolutionary argument. The physical world contains many niches. A wheeled platform may be efficient for transportation, a dual-arm system for manipulation, a drone for inspection, and a legged robot for difficult terrain. Forcing every capability into one embodiment may be technically possible in some cases, but it is often economically inefficient.
A more scalable approach is to let different robots retain their advantages while learning to coordinate.
Real multi-robot environments are not static. Tasks, priorities, available resources, communication quality, energy levels, and physical conditions change during execution. Robots also differ in what they can sense and do. AIRSEAI 3.0 will therefore investigate adaptive task allocation, communication-aware planning, group-level learning, and coordination across robots, edge systems, and cloud resources.
The goal is not merely to deploy more machines. It is to build systems that can reorganize themselves when the mission changes – assigning work according to current capability rather than a fixed script.
Why Open Source Is Part of the Evolutionary Mechanism
Joining LF AI & Data is important because evolution requires variation, selection, and inheritance. In technical communities, those mechanisms appear as alternative implementations, transparent evaluation, shared interfaces, reusable data, and the ability to preserve successful components while replacing weak ones.
A closed system can evolve within one company, but its range of variation is limited by that company’s hardware, priorities, and resources. An open project can bring together robot manufacturers, model developers, computing-platform providers, researchers, application owners, and users. Different groups can test the system in different environments and contribute improvements that no single team would encounter alone.
Neutral governance also matters. AIRSEAI should not become a showcase for one robot form, one model family, or one vendor’s computing platform. The Technical Steering Committee, public contribution process, open roadmap, and community discussions under LF AI & Data are intended to keep the project technically grounded and broadly accessible.
The Three Stages Are a Direction, Not a Prediction
AIRSEAI’s roadmap – from modular single-robot planning, to dual-arm data-driven manipulation, to heterogeneous multi-agent coordination – is a reasoned development path, not a claim that embodied AI must evolve in exactly this order everywhere.
Other applications will create other paths. A warehouse system may begin with fleets and add manipulation later. A medical robot may prioritize safety, teleoperation, and compliant control. An agricultural platform may evolve around terrain, endurance, and seasonal data. The important point is that embodiment and intelligence should co-evolve with the task.
This is also why AIRSEAI’s architecture must remain modular. A project that claims to support evolution cannot hard-code its own current embodiment as the final answer.
What Comes Next
Our immediate work is focused on strengthening AIRSEAI 2.0: completing the multimodal data pipeline, integrating dual-arm hardware and tactile perception, expanding the model zoo, developing stronger capability-boundary evaluations, and preparing software, datasets, and hardware resources for open release.
At the same time, we are laying the research foundation for AIRSEAI 3.0 through multi-agent simulation, task-allocation methods, communication-aware coordination, and real-world deployment studies.
The ambition is significant, but the method is intentionally incremental. Start with systems that work. Learn from the limitations exposed by real use. Add physical and cognitive capabilities when applications justify them. Preserve successful components through common interfaces. Allow multiple embodiments to coexist and collaborate.
Embodied AI does not need to arrive as a finished artificial species. It can evolve – one deployed capability, one shared dataset, one interoperable module, and one community contribution at a time.
Reference
Shaoshan Liu, “An Evolutionary Path for Embodied Robotics,” Communications of the ACM, Vol. 69, No. 3, 2026. DOI: 10.1145/3788648.
Source and review notes:
Primary conceptual reference: Shaoshan Liu, “An Evolutionary Path for Embodied Robotics,” Communications of the ACM, 2026 (DOI: 10.1145/3788648).
Project source material: AIRSEAI-v1 project deck, dated July 31, 2026, including the AIRSEAI 1.0-2.0-3.0 roadmap, AIRSEAI 2.0 architecture, and 2026 milestones.
