Six Levels for Robots: Arm Wants to Make Physical AI…

Robotics has a comparison problem. Two machines may both be described as “AI-powered” or “autonomous,” yet one repeats a carefully programmed motion while the other perceives a changing scene, plans around obstacles and recovers from failure. Arm now wants to replace that marketing fog with a shared six-level language for Physical AI.

Why robot capability is so hard to compare

Industrial robotics was built around tightly defined tasks. A conventional arm can weld, paint or place parts with extraordinary speed and repeatability when fixtures, lighting and component positions remain stable. The challenge begins when the environment changes. A box arrives at a different angle, a worker crosses the cell, a product variant requires another grip or an object slips unexpectedly.

Vendors often answer those situations with broad terms such as intelligent, adaptive or autonomous. Those labels are attractive, but they do not tell a buyer where inference runs, how quickly the system reacts, whether it can explain a decision, or what happens when a model encounters something outside its training data. The absence of a common vocabulary makes procurement difficult and can hide the gap between a demonstration and a production-ready machine.

What Arm has proposed

On September 8, Arm announced an expansion of its Total Design initiative for Physical AI and introduced a proposed Robotics Capability Framework. The ecosystem named by Arm includes more than 80 companies, among them AWS, Hugging Face, NXP, QNX, Siemens, Unitree and several AI and mobility specialists. The aim is not a single robot design. It is a common foundation that connects chips, operating software, AI models, simulation and complete robotic systems.

The framework describes six levels of increasing sophistication. Arm has presented it as a starting point for industry discussion, not as an adopted international standard. That distinction matters. The useful idea is less the number itself than the attempt to define what a machine can do, under which conditions, and with which system requirements.

A low-level system could be highly capable inside a fixed and predictable cell but have little ability to interpret novelty. Higher levels would add richer perception, planning, adaptation and independent execution across less structured environments. At the top end, a robot would need to combine real-time sensing, reasoning and safe physical action while dealing with uncertainty. The framework therefore tries to map a continuum rather than divide robots into the simplistic categories “automated” and “autonomous.”

The technical questions behind the six levels

Robot intelligence cannot be judged by model size alone. Physical AI is constrained by latency, energy, heat, memory bandwidth, sensor quality and mechanical response. A cloud model may offer impressive reasoning, but a moving machine cannot always wait for a network round trip before avoiding a collision. Some decisions must happen on the robot, close to cameras, force sensors and motors. Other workloads can be distributed to an edge server or cloud platform.

Arm’s framing therefore highlights issues such as compute placement, memory and power budgets, determinism and safety. Determinism is particularly important in factories: an operator needs to know not merely that a robot usually succeeds, but that critical reactions occur within a bounded time. A language that connects visible behavior to those system properties could help buyers distinguish a clever prototype from a dependable deployment.

It could also expose trade-offs. More autonomy may require more sensors and computation, increasing cost and power consumption. A smaller on-device model can respond quickly but may understand fewer situations. A larger remote model may reason more broadly but introduces connectivity and cybersecurity dependencies. There is no universally best level; the correct level depends on the job and the acceptable risk.

What buyers could gain

For manufacturers, the framework could become a structured checklist. What variability can the robot tolerate? Can it recover after a failed grasp? Does it need human approval for an unfamiliar case? Which functions continue when connectivity is lost? How is performance measured after a software update? These questions are more valuable than an isolated autonomy badge.

System integrators could use the same vocabulary to specify interfaces between components. A perception supplier, model developer and robot manufacturer would have a clearer basis for defining latency, safety and validation responsibilities. Insurers and regulators could also benefit if capability claims were tied to measurable evidence rather than promotional language.

For European industry, the timing is relevant. Companies are investing in flexible automation while also facing stricter expectations around machine safety, cybersecurity and AI governance. Siemens’ presence in the announced ecosystem gives the proposal a connection to industrial automation, but participation does not mean that every member has endorsed every detail. The framework will only become meaningful if users outside Arm’s commercial orbit help shape it.

The limits of a vendor-led taxonomy

Arm is not a neutral standards organization. It supplies processor architectures and has a clear interest in making its computing ecosystem central to Physical AI. That does not invalidate the proposal, but it means the industry should examine which workloads and architectures the framework favors. A credible standard must work for competing chips, robot types and software stacks.

Six levels can also create false simplicity. A robot may be excellent at navigation but poor at manipulation, or safe in a warehouse yet unreliable outdoors. Collapsing those differences into one number could encourage a new kind of marketing race. A stronger approach would pair the level with a capability profile covering perception, mobility, manipulation, human interaction, recovery and operational boundaries.

Testing is the hardest part. Benchmarks must reflect real variability rather than rehearsed demos. Success rate, intervention frequency, recovery time, energy use and performance under sensor degradation all matter. Safety cannot be inferred from general intelligence. It requires separate evidence, risk analysis and compliance with established machinery standards.

From a label to an engineering contract

The automotive industry shows both the power and danger of autonomy levels. Shared terminology helped organize a complex debate, but consumers sometimes interpreted technical labels more broadly than engineers intended. Robotics should learn from that experience. Every level needs plain descriptions of its operational design domain: the environments, objects, speeds and human interactions for which the claim is valid.

Software updates add another complication. A robot’s capability is not fixed when it leaves the factory. Models, maps and policies change. A useful framework must therefore support versioning and revalidation. If an update expands what a system can attempt, it may also change its failure modes. Capability classification should be treated as a living engineering record, not a permanent sticker.

The Alpha Bionic view

Arm’s proposal is valuable because the robotics market needs a language that starts with observable performance and ends with the computing and safety requirements underneath it. The biggest opportunity is not to crown the “most autonomous” robot. It is to make claims comparable enough that a factory, hospital or logistics operator can buy the right amount of autonomy for a real task.

The decisive test will be openness. If the six levels evolve through measurable, cross-vendor benchmarks and detailed capability profiles, they could reduce hype and accelerate deployment. If they remain a broad ecosystem message, the terminology may simply decorate existing products. For now, the Robotics Capability Framework should be read as a serious invitation to standardize—not as a finished standard.