XPENG has commissioned a dedicated production line for its IRON humanoid robot, and the first completed unit autonomously walked off the line. The company says more than 80% of the line’s core processes are automated, bringing automotive-grade manufacturing methods into humanoid robotics as IRON moves toward mass production.

The first completed IRON walked off the line on its own

XPENG has moved its humanoid robot program from prototyping into line manufacturing.

On September 8, the company said its dedicated humanoid robot production line had officially entered operation and that the first completed IRON unit autonomously walked off the line after production.

That detail is more than a launch-stage flourish. A humanoid robot is a tightly integrated machine: actuators, joints, sensors, controllers, compute, power systems, dexterous hands, software, and calibration all have to arrive at the end of the line as one functioning system.

XPENG is positioning the new facility as the bridge between the engineering work behind IRON and the repeatable manufacturing process needed for larger-scale deployment.

The company says the line was designed for scale from the beginning, with more than 80% of its core processes automated.

XPENG is borrowing the manufacturing discipline of a car company

XPENG did not build the robotics line as an isolated lab.

The company says it brought automotive-grade quality systems from its electric-vehicle manufacturing operations into humanoid robotics. The goal is to apply the same kind of process control, repeatability, inspection, and capacity planning used for complex vehicles to a new product category.

That is a logical fit for a humanoid robot.

IRON has dozens of moving joints, high-performance onboard compute, custom control hardware, and mechanical structures that have to work together with consistent tolerances. Moving from a few engineering units to repeatable production means those elements need manufacturing processes that can be measured and reproduced.

XPENG describes the line as high-precision, flexible, and intelligent, with automation concentrated in the critical processes that determine final product consistency.

For a company already operating large vehicle plants, robotics becomes an extension of an existing manufacturing skill set rather than a completely separate discipline.

IRON was already being prepared for mass production

The production line follows a roadmap XPENG has been signaling for months.

The company has been developing IRON as a general-purpose humanoid platform and previously said the robot was moving toward mass production in 2026.

Its earlier public demonstrations focused heavily on the robot itself: human-like movement, dexterous hands, onboard AI compute, and the ability to operate in environments designed around people.

The new announcement shifts the emphasis from the prototype to the factory.

That is an important change in the story. A robot can look impressive in a controlled demonstration and still be far from a product that can be built repeatedly. A dedicated line introduces another layer of engineering: assembly sequence, calibration, inspection, traceability, throughput, and quality control.

XPENG is now showing that layer alongside the robot.

The hardware is built around 76 degrees of freedom

The current IRON platform uses 76 degrees of freedom across the body, according to XPENG.

Each hand contributes 21 degrees of freedom, giving the robot a large mechanical range for hand and finger movement.

The company also uses a fully enclosed flexible lattice structure intended to combine a human-like form with a protected mechanical design.

Those specifications explain why manufacturing matters so much.

A humanoid with this many articulated elements is not assembled like a simple mobile robot. Every joint, actuator, linkage, controller, and sensor relationship has to end up inside a repeatable mechanical system that can move as intended after final assembly.

The same applies to the hands. High dexterity only becomes useful at scale if the geometry, calibration, control electronics, and software behavior remain consistent from one unit to the next.

The new line is therefore part of the product architecture, not just the place where the product happens to be assembled.

Three Turing AI chips put up to 2,250 TOPS on the robot

IRON’s compute stack is another part of the manufacturing challenge.

XPENG says the robot uses three of its Turing AI chips for up to 2,250 TOPS of effective computing power.

That onboard compute is intended to run XPENG’s Physical AI foundation model directly on the robot. The company says this allows IRON to perform complex tasks autonomously without relying on remote operation, while keeping inference latency low.

It also makes IRON part of the same broader technology strategy XPENG has been developing across vehicles, Robotaxi, and robotics.

The interesting manufacturing consequence is that a humanoid unit is not only a mechanical assembly. It leaves the line as an edge-AI computer with motion hardware attached to it.

Compute modules, controllers, actuators, sensor systems, software images, and final calibration all become part of a single production target.

More than 80% automation is aimed at repeatability

XPENG says automation exceeds 80% across the production line’s core processes.

The company connects that automation directly to quality consistency and future capacity expansion.

For humanoid robots, that is especially relevant because scale depends on repeatability. A production system has to turn complex electromechanical assemblies into units that behave consistently enough for software, control models, and downstream testing to work across the fleet.

Automation can also make the manufacturing data more structured.

Every repeated process creates measurable information about tolerances, calibration, component quality, and final-system behavior. Over time, that can give the engineering team a tighter feedback loop between how IRON is designed and how it is actually built.

XPENG’s advantage here is straightforward: it already knows how to connect software-heavy products to automated manufacturing at vehicle scale.

Stores and campuses are the first commercial environments

XPENG says IRON is scheduled to enter mass production by the end of 2026.

Initial commercial rollouts are planned for XPENG’s own stores and campuses, giving the company controlled environments in which to deploy the robots before broader customer delivery.

The company plans an official market launch and deliveries in China and overseas markets in 2027.

That rollout sequence gives the manufacturing program a clear next step.

The new line establishes repeatable production. Internal stores and campuses create real operating environments. Broader delivery then expands the number of places in which the robot can collect experience and perform useful tasks.

For Physical AI, those stages are closely connected. More deployed robots mean more real-world interaction, and a scalable factory is what makes that deployment loop possible in the first place.

The Upgrade Feeling

The most important part of XPENG’s announcement is not simply that another humanoid robot exists.

IRON now has a production system behind it.

A dedicated line, more than 80% automation in core processes, automotive-grade manufacturing methods, 76 degrees of freedom, dexterous hands, and 2,250 TOPS of onboard compute all point toward the same transition: from building a robot that works to building the same robot repeatedly.

That is where humanoid robotics starts looking less like a sequence of demonstrations and more like an industrial product category.

XPENG’s next milestone is scale. The factory is now part of the robotics story.

AI Agents Are Moving From Software Tools Into Physical Equipment

AI agents have already learned how to work with software.

They can call APIs, search databases, edit files, use developer tools and coordinate workflows across applications.

The next interface is physical equipment.

A robot arm has position, speed, payload and safety limits.

A camera has exposure, focus and image data.

A laser system has tunable parameters and sensor readings.

A manufacturing machine may expose its own commands, status values and control software.

The Model Hardware Standard, or MHS, is designed to give AI agents a common way to understand that equipment.

Anthropic opened MHS as a limited research preview on August 27, 2026 after developing it with HHMI Janelia Research Campus and a group of partners across science, robotics, electronics and manufacturing.

The central idea is straightforward.

A physical device should be able to describe what it is, what it can measure, what can be changed and which operating limits must be enforced.

An AI agent should then be able to discover that description and interact with the device through a common interface.

That takes the agent architecture beyond software tools.

The tool can now be a physical machine.

MHS Adds a Standard Driver Between the Agent and the Device

The main technical layer in MHS is the driver.

A driver is software that translates between a higher-level system and the specific hardware underneath.

Operating systems already use this pattern.

A printer driver turns generic print operations into commands a specific printer understands.

A graphics driver connects a software graphics stack to a GPU.

MHS applies a related idea to AI-controlled equipment.

The device gets an MHS driver.

That driver exposes the machine through a standard structure instead of requiring the agent to understand every vendor-specific interface directly.

Anthropic describes simple primitives such as read and write.

Read can request a value such as temperature, position or another sensor state.

Write can change a supported parameter.

The actual machine may still use a proprietary SDK, serial protocol, command-line tool or control application underneath.

The MHS layer translates the common operation into whatever the device requires.

That separation matters.

The agent can reason at the level of the task.

The driver handles the device-specific control path.

The same agent architecture can therefore interact with several types of equipment while each machine retains its own implementation underneath.

A Device Can Describe Itself in a Machine-Readable Reference

Control commands are only one part of physical operation.

An agent also needs context.

A robot may have a maximum payload.

A motor may have a permitted speed range.

A camera may expose several imaging modes.

A temperature controller may have upper and lower operating limits.

Some of that information exists in code.

Some exists in manuals.

Some exists as operating knowledge held by the people who work with the equipment.

MHS adds a structured way to bring that information into the interface.

Anthropic says MHS drivers support tags where users can describe machine characteristics in natural language.

The system can then produce a reference file describing the device.

That reference can include what the machine measures, which parameters can be adjusted and which safety limits are enforced.

The result is more than a list of functions.

It is a device model.

The agent receives both verbs and context.

Read this value.

Set this parameter.

This part moves.

This value has a defined range.

This machine has a physical characteristic the agent should know before operating it.

That turns hardware documentation into part of the agent’s working interface.

Discovery Lets Agents Find Devices Through a Common Format

A shared hardware interface becomes more useful when devices can also be discovered consistently.

MHS is designed to make connected equipment discoverable in a standard format across a network.

That gives an agent a way to learn what hardware is available before it starts building a workflow.

A system might expose a camera.

Another node might expose a robotic arm.

A third might expose a sensor controller.

The agent can inspect the available devices, read their reference information and determine which capabilities fit the task.

This resembles what has happened in software-agent systems.

A software agent can discover tools exposed by an MCP server.

Each tool has a name, a description and an input structure.

MHS extends the same general idea into physical devices.

The available capability is not only “search database” or “write file.”

It can be “read camera,” “move arm,” “set controller value” or another machine-specific operation represented through the common hardware layer.

Discovery changes orchestration.

The agent does not have to begin with one hard-coded machine.

It can begin with the equipment that is present.

MCP Becomes One of the Ways an Agent Reaches MHS Hardware

MHS does not replace the Model Context Protocol.

It can sit behind it.

Anthropic says MHS is model-agnostic and can be accessed by agent harnesses through standard protocols such as MCP.

That creates two distinct layers.

MCP gives an AI application a standard way to discover and call tools.

MHS gives physical equipment a standard way to describe and expose its hardware capabilities.

The layers can connect.

An MCP tool can represent an action that ultimately reaches an MHS driver.

The agent sees a callable operation.

MHS handles the relationship between that operation and the physical device.

This is why MHS is a different topic from MCP even though the two standards can work together.

MCP standardizes model-to-tool interaction.

MHS standardizes the hardware side of the tool.

The distinction becomes visible when a workflow crosses from software into the physical world.

The agent may use MCP to reach the tool.

The tool may use MHS to reach the machine.

The result is a stack rather than one protocol trying to describe everything.

Command Line and Code Files Give MHS More Than One Control Path

Anthropic describes three control mechanisms for MHS: MCP, command-line interfaces and code files or APIs.

That gives the agent several ways to operate the same hardware layer.

Interactive reasoning can use MCP calls.

A developer or operator can use command-line access.

A long-running workflow can be packaged into code.

The code path is important because an AI agent does not need to reason through every low-level step forever.

The agent can explore a device, learn a sequence and then turn that sequence into deterministic code.

Anthropic demonstrated this pattern with laser alignment.

Claude adjusted the laser, observed the result through a camera and repeated the process while learning the relationship between control changes and the observed beam.

It then packaged the learned sequence into a script.

The final operation could run as a deterministic command rather than requiring live reasoning for every adjustment.

That creates two operating modes.

Reason while discovering the procedure.

Execute code after the procedure has been defined.

MHS provides one hardware interface underneath both.

The Standard Can Coordinate Several Machines as One Workflow

The main architectural value appears when a task needs more than one device.

A production cell may contain several robot arms.

An imaging system may combine cameras, motors, sensors and optical equipment.

A test setup may use measurement devices on different computers.

MHS gives the agent one structured control surface across those devices.

The agent can read state from one machine.

Wait for a condition.

Trigger a second device.

Inspect another sensor.

Adjust a parameter.

Continue to the next stage.

Anthropic describes MHS as supporting parallel operation across multiple instruments and says device commands can be chained together in code files.

The standard therefore sits above the individual machine.

Its unit of work can become the complete physical workflow.

That is similar to what software agents already do across several applications.

The difference is that the state now includes real-world positions, measurements and machine status.

The workflow exists in both software and physical space.

Universal Robots Tested MHS Across Multiple Cobots

Manufacturing provides a direct example.

Universal Robots joined the MHS research preview and tested the standard on its collaborative robots.

The company described an experiment involving four separate robot applications.

An agent running on Claude Opus 4.8 coordinated them as one cell and handed payloads between the robots.

The relevant part is the interface structure.

Each robot application still runs on real industrial hardware.

The existing robot-control and safety architecture remains underneath.

MHS adds a layer where the agent can discover the devices, understand declared operating information and orchestrate the applications together.

Universal Robots also describes machine bounds, interlocks and emergency-stop information being represented through the MHS layer while the robot platform’s own safety architecture remains active.

That is how a hardware standard can participate in an industrial system.

The device controller remains underneath the MHS layer.

It provides an additional interface above it.

The agent works with the standardized representation.

The robot controller continues operating the machine.

QuEra Used MHS to Connect an Agent to Precision Quantum Hardware

Quantum computing shows another type of physical system.

QuEra Computing used MHS to connect an AI agent to parts of the laser-control system inside its neutral-atom quantum-computing hardware.

The task was laser stabilization.

A neutral-atom quantum system depends on lasers maintaining highly precise operating frequencies.

QuEra used MHS as the hardware interface while Claude developed and tested control logic for restoring the laser to its target lock.

In a later blind test reported by Anthropic and QuEra, the resulting controller recovered the lock 99.3 percent of the time.

QuEra also reports that the workflow reduced recovery from minutes of specialist work to seconds in the test environment.

The point for MHS is not the quantum algorithm.

It is the hardware loop.

Read physical state.

Change controls.

Observe the result.

Evaluate whether the target condition has been reached.

Package the resulting procedure into code.

That same loop can exist in many forms of precision equipment.

MHS gives the AI system a standard place to connect to it.

Raspberry Pi Shows How MHS Can Reach Smaller Hardware

MHS is not limited to large industrial or scientific systems.

Anthropic says Raspberry Pi is enabling MHS integration across a number of its products after successful tests with a Camera MHS Driver.

A camera is a useful small-scale example because it combines hardware state with continuous data.

The device has configuration values.

It has an image stream.

It may be connected to motors, sensors or other peripherals.

An agent can use the camera as both an input and part of a control loop.

The MHS driver provides the structured hardware interface.

A Raspberry Pi can provide the programmable compute environment around it.

That makes the standard relevant to prototyping, robotics and edge systems as well as large installations.

The physical-AI stack can therefore scale down.

It does not require a factory floor.

A developer can start with a programmable board, a camera and another controllable device.

The same general driver model can then grow with the hardware system.

Hugging Face Is Connecting MHS to the LeRobot Ecosystem

Robotics libraries add another layer to the ecosystem.

Anthropic says Hugging Face is adding MHS support to LeRobot.

LeRobot is Hugging Face’s open robotics framework for models, datasets and tools used with real-world robots.

Its current documentation describes a hardware-agnostic Python interface for controlling robots, recording datasets and deploying learned policies.

MHS can add a standardized agent-to-hardware interface to that environment.

The two systems have different roles.

LeRobot focuses on robot learning, datasets, policies and hardware abstractions.

MHS focuses on exposing physical equipment to AI agents through a common device interface.

Combining them creates a path where a robot-learning stack and an agent orchestration stack can share the same physical equipment.

An agent can discover the machine.

A policy can control learned motion.

The hardware interface can expose state and permitted operations.

That is another sign that MHS is being positioned as a layer rather than a complete robotics framework.

It can connect to existing robotics software instead of replacing it.

Model-Agnostic Design Separates the Hardware Standard From One AI Model

MHS was introduced by Anthropic, but the specification is designed to be model-agnostic.

Anthropic says any agent harness can access MHS through standard protocols such as MCP.

That matters for the architecture.

A hardware installation can last much longer than one model generation.

A robotic system, camera rig or manufacturing cell may operate for years.

AI models can change much faster.

A model-agnostic hardware interface separates those lifecycles.

The driver describes the machine.

The agent harness connects to the driver.

The model used by that harness can change independently.

That keeps the machine integration focused on the physical device rather than one model API.

The same principle is common in computing standards.

The same USB connector can work across different processors.

The same Ethernet framing can work across different operating systems.

MHS is applying a similar separation to agent-controlled hardware.

The hardware contract lives in one layer.

The intelligence using that contract lives in another.

Physical Limits Can Be Declared as Part of the Interface

A physical interface needs more than capability descriptions.

It also needs operating boundaries.

MHS drivers can include information about safety limits that will be enforced.

Universal Robots describes bounds, interlocks and emergency-stop information being included in the MHS representation while the robot’s own safety architecture remains responsible underneath.

That layered design matters.

The agent sees what it is allowed to request.

The MHS layer can expose the permitted operating envelope.

The hardware controller still applies the machine’s own safety mechanisms.

The result is not one safety system replacing another.

It is a hierarchy.

The model works inside the capabilities it has been given.

The MHS driver describes and constrains the interface.

The device’s native controller remains responsible for its own hardware-level protections.

This is especially relevant when an AI system controls equipment with movement, energy or other physical effects.

The machine interface has to describe not only what can be done.

It also has to define the boundaries around how those actions can be performed.

The Research Preview Is Building the Standard Before Open Source Release

MHS is not yet a generally available open standard.

Anthropic currently describes it as a limited research preview.

Access is by application.

The company says the preview is being used with partners across science, robotics, electronics and manufacturing to build evaluations and deployment practices before the standard is released as open source.

The official MHS site uses the same framing.

The project began with Anthropic and HHMI Janelia Research Campus.

The current phase expands testing across outside organizations.

That status is important because it tells us where the technology sits.

The architecture exists.

Drivers are being tested on real devices.

Partners are building integrations.

The specification is still being developed through the research-preview process.

Anthropic says it plans to open-source MHS after that work.

For developers watching the standard, the present moment is therefore about the interface design and the early ecosystem rather than a finished universal hardware layer.

The direction is visible before the final open-source release.

MHS Creates a Hardware Layer Beside the Software Tool Layer

The larger architecture becomes clear when MHS is placed beside the other agent standards emerging around AI.

MCP gives models access to software tools and data.

App Intents, AppFunctions and operating-system action frameworks expose application capabilities.

Agent plugin formats package reusable agent extensions.

MHS addresses a different boundary.

It connects the agent stack to physical equipment.

That means future agent systems can have several layers of tools.

A database tool.

A browser tool.

A code tool.

An application action.

A camera.

A robot arm.

A controller.

A sensor.

To the agent, each one can become a structured capability.

The underlying implementation can remain very different.

Software stays software.

Hardware stays hardware.

The standard defines the interface where the agent meets each system.

That is why MHS can sit next to MCP rather than competing with it.

The software tool layer and the physical-device layer are becoming separate parts of the same agent architecture.

AI Agents Are Getting a Common Interface to the Physical World

The Model Hardware Standard turns one broad idea into an engineering structure.

A physical device gets a driver.

The driver exposes common operations such as reading and writing state.

The device can publish a reference describing its characteristics and operating limits.

Agents can discover connected hardware.

MCP, command-line interfaces and code files can provide control paths into the same system.

Several devices can be orchestrated as one workflow.

Model choice remains separate from the hardware standard.

Existing machine controllers and safety systems remain underneath the MHS layer.

Early integrations now span robotics, Raspberry Pi hardware and quantum-computing equipment.

Anthropic is testing the specification with partners before a planned open-source release.

This extends the agent stack in a specific direction.

The model can now work with software resources and physical equipment through separate structured interfaces.

Physical equipment can be described as a structured, discoverable capability too.

The agent gets a common interface.

The machine keeps its own implementation.

MHS connects the two.

That is the upgrade.