How do MHS and Shifu fit together? Let’s explain.
Lately, people have been asking us: is Anthropic’s new MHS doing the same thing as Shifu, the project we have been building at Edgenesis for years?
A lot of people have asked us how MHS relates to Edgenesis’s Shifu. We want to take the time to explain it properly.
The short answer: there is overlap, but neither replaces the other. MHS focuses on how AI agents discover, understand and operate hardware. Shifu focuses on connecting real devices at the edge, keeping them running reliably and managing them over time.
Once devices are connected, AI still needs to understand their relationships, state changes and physical consequences. Our answer at Edgenesis is the Physical AI Ontology System.
It is easy to compare MHS and Shifu because both involve device drivers, device descriptions and unified interfaces. But several layers of work separate “connected to the system” from “operated correctly by AI.” Breaking down those layers makes the relationship clearer.
Imagine a water pump. The AI sends a start command, and the controller replies “success.” In a software system, that might mean the job is almost done. On site, it is only beginning. How long will the pump take to build pressure? Could a partially open valve cause cavitation? Is the speed reported by the controller a setpoint or an actual sensor reading? The interface does not automatically answer these questions.
First, what does MHS actually do?
On August 27, Anthropic released a research preview of the Model Hardware Standard (MHS). Its aim is to give AI agents a more consistent way to discover devices, read their state, write parameters and understand their operating limits.
MHS is more than “MCP for hardware.” In Anthropic’s published design, MCP is just one way for an agent to access MHS. MHS also covers device drivers, device discovery and device descriptions.
Device drivers Wrap different vendors’ interfaces in basic operations such as read and write.
Device discovery Expose devices in a common format so agents do not have to find each entry point individually.
Device descriptions Describe measurements, adjustable parameters, device characteristics and operating limits.
Control interfaces Let agents operate devices through MCP, a command-line interface or a code API.
MHS covers more than giving an agent an API. This conceptual illustration is based on Anthropic’s public materials.
Anyone who has integrated devices knows the routine: read the manual, find the SDK, test the registers, then adapt the vendor’s interface into something an application can use. Switch vendors, and much of that work starts again. MHS aims to standardize the parts that can be reused.
Anthropic says that, in early projects, some hardware integrations went from weeks or months to hours or minutes. The logic is understandable: with agreed formats for drivers, device descriptions and control interfaces, an agent no longer has to start by working through a collection of unrelated SDKs.
What we appreciated most when we first saw MHS was that it made hardware integration an explicit part of agent infrastructure. Discussions about agents often assume the tools already exist and the interfaces are ready to use. MHS addresses the preceding step: helping a model find a device and understand what it is allowed to do.
MHS is still a research preview for an initial group of research labs and advanced manufacturing partners, and it has not yet been formally open-sourced. It requires devices to have programmable interfaces. An older device without an accessible interface does not become controllable simply because MHS exists.
The practical catch: MHS is another new standard
Having discussed what MHS gets right, we need to address an unavoidable problem: MHS is itself a new standard.
A long-running xkcd comic captures this neatly. Faced with 14 incompatible standards, people decide to create one universal standard that covers everyone’s needs. Soon, there are 15 standards.
xkcd #927, “Standards,” by Randall Munroe; reproduced under the CC BY-NC 2.5 license.
MHS faces this problem too. Equipment manufacturers already have their own protocols, SDKs and data models, along with their own product roadmaps and commercial interests. Whether they add native MHS support to new equipment depends on what they gain from it. Equipment that has been deployed for years is even less likely to be retrofitted wholesale for a new standard. For many devices, even the accuracy of the interface documentation and the differences between firmware versions have to be checked on site.
So if MHS adoption depends on waiting for every manufacturer to switch to MHS, progress will be slow. Research equipment and a small group of partners may move first. In factories, energy facilities and buildings, proprietary interfaces will remain for a long time.
We think bridging is the more practical approach. On the agent side, expose MHS-compatible device descriptions and controls. On the device side, continue to support Modbus, OPC UA, serial interfaces, vendor SDKs and the proprietary protocols already in use.
This is where Shifu fits. We are building Shifu into a Physical AI Operating System. It does not require real-world devices to become standardized first. Instead, it uses AI to read equipment manuals, interpret protocols, generate drivers and assist with validation on real hardware, then presents different vendors’ devices as consistent, programmable objects. MHS can provide the standard entry point for agents; Shifu connects that entry point to the real world.
Validated field meanings, state transitions and operating experience are also fed back into Shifu. This gives MHS a way to reach existing equipment without first persuading every manufacturer to redesign its devices.
Why connecting a device is not the end of the job
Here, MHS and Shifu already share some ground: both reduce the cost of device integration. But in our projects, a recurring difficulty is that the most time-consuming work starts after the data begins arriving.
The same register value, 32767, might mean full scale, invalid data or a sensor fault. A field called “speed” could be the controller’s setpoint or the motor’s measured speed. Similar names can hide very different meanings.
Protocol layer Can the data get through? For example, is the Modbus, OPC UA, serial or vendor SDK connection working?
Semantic layer What does the value mean? Does 32767 indicate full scale, an invalid reading or a sensor fault?
Behavioral layer What happens after a command is sent? How long should it take, what counts as success, and when should the equipment stop?
MHS already addresses protocol abstraction and some semantic descriptions. Validating, retaining and reusing device behavior knowledge requires supporting mechanisms.
MHS does not deal only with protocols. Natural-language labels, operating limits and real-time state feedback extend into the semantic layer. Agents can also adjust parameters based on feedback from real hardware. This matters: describing MHS as a simple protocol converter would be inaccurate.
Still, experience gained on site is easily lost. It may stay in a single conversation or become a script specific to one device. When firmware, load or maintenance conditions change, does that experience still apply, and who validates it? The current public materials do not fully explain this.
Genentech’s bubble problem looks a lot like real fieldwork
The Genentech case published by Anthropic is worth examining. It is not an everything-went-perfectly demo. It exposes where AI can still go wrong after the equipment is connected.
Genentech used MHS for a proof of concept involving a BCA protein concentration assay. Claude coordinated a liquid handler, a robotic arm and a microplate reader.
Initially, Claude used the same flow rate for water and a viscous BSA solution, which caused bubbles in the BSA and inaccurate pipetting. After several rounds of testing, it adjusted the water flow rate to roughly 140 µL/s and the BSA flow rate to roughly 10 µL/s. Genentech’s automation experts considered these parameters appropriate for that equipment configuration.
The subsequent error recovery was even more revealing. After the system reported a runtime error caused by bubbles, Claude kept retrying in the same well. The equipment executed the commands, but the bubbles multiplied. The problem was resolved only after lab staff instructed it to move to a clean well and reduce the number of mixing cycles.
A valid command can execute successfully and still be the wrong operation. The team later captured this lesson in a reusable Skill.
We find this failure more informative than a successful API call. MHS had done its part: the equipment was connected, state feedback was available and the agent could keep experimenting. What Claude lacked at that moment was causal knowledge about bubbles, viscosity, mixing methods and the condition of the well.
-
MHS interface What can this device read and do?
-
Physical AI Ontology System What is the device, what is it connected to, what state is it in, and how will an operation change it?
-
Operating skills What should be done now to complete the task at hand?
Edgenesis’s answer: the Physical AI Ontology System
This also explains why traditional digital twins alone are not enough. Many projects map equipment data onto a dashboard or build a 3D model and call it a digital twin. These are useful for monitoring. But to operate equipment itself, AI also needs to know what the equipment is, how it relates to surrounding objects and how its state will change.
At Edgenesis, we call this the Physical AI Ontology System. It organizes device capabilities, field semantics, relationships between devices, state changes, physical constraints and experience validated on real hardware into knowledge that AI can query and reason about. At a minimum, it should record:
-
The device’s identity and capabilities, and the units and meanings of its fields.
-
Its relationships with sensors, controllers, materials and the environment.
-
Its current state, the conditions required before a command can run, and how its state transitions work.
-
How long a normal response takes, and how firmware, configuration, maintenance and aging affect the result.
Take the pump again. Even with the same speed setpoint, actual flow depends on valve position, inlet pressure, fluid viscosity, filter blockage and equipment wear. An AI looking only at the API will struggle to explain these differences.
The same applies to an energy storage inverter. A system can issue a command to “discharge at 100 kW,” but whether the equipment can deliver depends on battery state of charge, cell temperature, BMS policies, inverter limits and grid conditions.
MHS gives agents a common language for operating equipment. The Physical AI Ontology System helps them understand what those objects are, how they relate to one another, and how their states will change after a command.
Back to the main question: how do Shifu and MHS work together?
We can now return to the opening question. MHS and Shifu do not have a simple hierarchical relationship, nor are they the same thing under different names. Both involve drivers and device abstraction, but they focus on different parts of the work.
MHS mainly addresses how agents discover, describe and operate hardware. Shifu is the operating system Edgenesis is building for physical AI: it uses AI to integrate devices, manages connections, state and device lifecycles at the edge, and bridges MHS with manufacturers’ proprietary interfaces.
In Shifu’s public design documentation, DeviceShifu is described as a “structural digital twin.” It packages southbound protocols and drivers together with northbound application interfaces in a Kubernetes Pod, and provides health monitoring, state caching and lifecycle management.
This is Edgenesis’s conceptual view of physical AI infrastructure, not an official Anthropic architecture diagram.
In a physical AI system that brings them together, Shifu handles device connectivity and operation at the edge, translating southbound proprietary protocols into a northbound MHS interface. The Physical AI Ontology System supplies agents with device semantics, object relationships, state changes and failure modes validated in the field.
This is the closed loop we are developing: Shifu uses AI to interpret device documentation, generate integration code and assist with hardware testing, while engineers confirm the results. Once validated, the drivers become part of Shifu and the device knowledge enters the Physical AI Ontology System. MHS provides a common representation for agents; Shifu connects the real-world devices that remain anything but uniform.
After a device is connected, its manuals, protocol definitions, drivers, state machines, historical data, fault records and corrections from field engineers should all feed into the same versioned body of knowledge.
AI can help read manuals, generate adapters and infer state machines. Whether its inferences are correct still has to be checked on real equipment. Discrepancies between documentation and actual behavior must be recorded too. Otherwise, the next team integrating the same model will repeat the same mistakes.
Why we see this as the next step
When we assess whether a physical AI system can work in practice, we usually look at four things:
-
Devices connect reliably, and the agent knows what it can read and write.
-
Field meanings have been checked, so setpoints are not mistaken for measurements and fault codes are not treated as ordinary data.
-
The system understands command preconditions, normal responses and common failure modes.
-
Corrections from the field can be saved, versioned and reused on the next device.
MHS focuses on the first point and covers some field meanings and operating limits. Shifu makes that first point work reliably in industrial settings. The Physical AI Ontology System addresses the remaining needs, capturing device semantics, relationships and field experience and updating them as firmware, configuration and device state change.
If AI repeats the same mistakes every time firmware, a filter or an end effector changes, connecting more devices will not help. We want that field experience to survive and actually be useful the next time someone encounters the same equipment model.
About Edgenesis
Edgenesis is developing a Physical AI Ontology System. Our open-source project Shifu provides the foundation for device integration and operation: it manages equipment from different vendors and protocols in a Kubernetes-native way, and uses AI to read manuals, generate drivers and assist with validation on real hardware. Once devices are connected, the ontology system records their semantics, object relationships, operating constraints and field experience, helping agents understand what they are operating and what will happen afterward.
Explore our products: Shifu, Shifu Agent and Shifu Dev.
