When AI Starts Operating Equipment: Enterprise Intelligence Moves into the Physical World

Anthropic begins with the connection between models and equipment. General-purpose AI can understand natural language, break down tasks, and invoke software tools, but equipment in laboratories and factories has its own programming interfaces, data formats, and control software. Even when that equipment can already be controlled by a computer, an agent does not automatically know what it can do, what state it is in, or how to operate it safely.

When multiple devices must work together on one task, these differences make integration even harder. Engineers typically have to learn each device interface, write a connector for every device, and translate operating requirements from manuals—as well as equipment knowledge held by on-site staff—into code. Anthropic noted in its MHS research preview that this kind of hardware integration in a laboratory or manufacturing environment often takes weeks or even months. The absence of a shared way for equipment to describe itself is the first barrier to general-purpose AI entering a physical environment.

MHS adds a standardized driver layer between the agent and the equipment. A driver can be understood as a “translator” connecting software and hardware: one side adapts to a device’s existing interface, while the other describes the device’s capabilities and operating boundaries to the agent in a consistent way.

Through an MHS device description, an agent can learn what a device can measure, which parameters it can adjust, and what safety restrictions the system will enforce. Information that is difficult to infer from code alone—such as the weight of a robot arm, the physical characteristics of a device, and operating precautions—can also be written into the description file as natural-language labels. Information previously scattered across paper manuals, personal computers, and engineers’ experience is thus converted into equipment knowledge that an agent can read and use.

This gives equipment the foundation to be “discovered” and “understood” by AI. When an agent encounters a device it has not used before, it can first read the device’s functions, state, and constraints, then decide which step of the current task it can perform. MHS is decoupled from any specific model. Claude was only one of the agents used in the first trials; other agents can connect to equipment through the same specification.

After understanding a device, an agent still needs to convert its judgment into instructions the device can execute. MHS reduces the basic operations of different hardware to common commands such as read and write. A read operation might retrieve temperature, position, or operating status; a write operation might set a temperature within the permitted range, move a robot arm, or adjust another parameter.

An agent can discover devices and invoke these commands through the Model Context Protocol (MCP), a command line, or an API. A complete action chain then takes shape:

The agent reads device state → forms a judgment based on the task → issues a command to the device → receives the new data generated by execution.

When several devices work together, the agent can also start the next device according to the completion status of the previous step, bringing previously independent instruments into a single workflow.

For long-running operations or actions that must be repeated quickly, MHS also allows the agent to write validated device commands into a code file so that the equipment can execute them continuously as a deterministic program. The model understands the objective, plans the steps, and handles change; routine actions are left to conventional programs. Flexible reasoning and deterministic control can therefore coexist in the same system.

MHS serves as the interface layer in a Physical AI system. By giving different devices a common way to describe themselves and receive commands, it lowers the engineering barrier to having AI discover, understand, and connect to equipment. In the first trials, Claude was already able to read device states, coordinate multiple instruments, adjust parameters in response to physical feedback, and convert validated operations into repeatable programs. General-purpose AI is thus beginning to move beyond invoking software tools toward understanding and operating real equipment.

MHS addresses how equipment connects to Claude. Two early pilot use cases conducted by Anthropic and its partners further show how that interface can be translated into actual equipment operations.

In Anthropic’s August 27 article “Previewing the Model Hardware Standard,” U.S. biotechnology company Genentech described a laboratory automation proof of concept. Researchers used MHS to connect liquid-handling equipment, a robot arm, and a plate reader, allowing Claude to coordinate a BCA protein assay that measures the total protein concentration in samples.

The experiment first asked Claude to follow a standard laboratory protocol for ordinary water and for a more viscous bovine serum albumin (BSA) sample. Claude initially selected the same generic flow rate for both liquids. At high pipetting speed, the viscous protein sample formed bubbles and the accuracy of liquid transfer deteriorated. The equipment had followed the instruction, but real-world conditions—including viscosity, pressure, and bubbles—caused the same instruction to produce different results.

The researchers then gave Claude an expert-defined range of flow rates and included expert-performed transfer results on the same plate as a reference. Claude set a flow rate and completed the transfer, called the plate reader to collect absorbance data, calculated the root mean square error between its own result and the expert benchmark, adjusted the parameter, and began the next trial.

After successive trials, Claude determined that an appropriate flow rate for water was approximately 140 μL/s, with an RMSE of 0.016. For the more viscous protein sample, it reduced the flow rate to approximately 10 μL/s, with an RMSE of 0.181. Genentech’s laboratory automation experts considered both parameter sets reasonable for the experimental setup.

This trial demonstrates a key shift in Physical AI: the physical result produced by equipment can now feed directly into AI’s next action. Experts still define the experimental range and evaluation benchmark, while Claude uses MHS within that range to coordinate multiple instruments and find more suitable parameters through repeated operation. AI’s use of equipment thereby forms a closed feedback loop: “execute, read the result, compare the deviation, and adjust the action.”

In its August 27 article “QuEra Computing Uses AI to Automate a Critical Quantum Computer Subsystem, Enabling the Acceleration of Commercial-Grade Quantum Computing Deployments from QuEra,” U.S. quantum computing company QuEra Computing applied MHS to a more complex equipment-recovery task.

QuEra’s quantum computers use lasers held at precise frequencies to control atomic qubits. When a laser drifts away from its target frequency, the system must relock it. Common disturbances can already be handled automatically, but rare and complex failures still depend on expert judgment; manual recovery typically takes five to ten minutes.

QuEra had previously assigned four specialists to spend two to three weeks writing a recovery script, but the script could address only the failures anticipated by its developers. After MHS was connected, Claude used a dedicated test rig to propose recovery methods for different failure conditions, perform actions, read the results, and continue revising its approach. The process could run continuously, including overnight while the human team rested, covering hundreds of failure scenarios. Engineers set the operating range for the trial, reviewed every action, and determined what outcome would count as a successful recovery.

After multiple rounds of experimentation, Claude wrote the effective recovery methods into a conventional control program. During operation, this fully inspectable program runs the process, so Claude does not need to reason online every time the equipment fails. Across 700 timed trials covering seven failure categories, the program restored the system to its target state 695 times—a 99.3% success rate—without once reporting a failed recovery as successful. Most failures were resolved within six seconds; the most complex took approximately 10 to 14 seconds.

QuEra also pointed the system at a different laser wavelength. During one unattended overnight run, Claude found the corresponding parameters again; similar calibration had previously required weeks of on-site work.

QuEra’s trial further shows that equipment-operating experience acquired by Physical AI can be embedded in engineering programs. Claude performed the experimentation, calibration, and program generation, while the validated control logic was executed deterministically over the long term. Failure-handling methods that once had to be imagined and coded one by one by experts could instead emerge from a large volume of real feedback, leaving behind inspectable and reusable operating results.

Genentech demonstrates a parameter feedback loop during operation; QuEra preserves the experience formed through repeated calibration as a control program. Together, the two trials mark Anthropic’s current position: in controlled tasks, Claude can coordinate equipment, feed physical outcomes into subsequent actions, and turn validated methods into repeatable programs. General-purpose AI is moving beyond recognizing and invoking devices toward continuously completing tasks on the basis of physical feedback.

Through MHS, Claude can already coordinate equipment, read physical feedback, and adjust subsequent actions. This capability expands the range of work that enterprise AI can enter and raises a more practical question: does an enterprise need to introduce AI at the physical layer?

When enterprises mapped AI use cases in the past, they usually focused on documents, knowledge, data, and software processes. The output of these applications largely remained in the digital environment, with employees carrying out the subsequent action. Physical AI extends further into laboratory instruments, production equipment, logistics facilities, and field environments. AI-generated judgments directly change equipment actions and are then adjusted in response to real-world outcomes. Enterprises therefore need to revisit their use-case maps and determine whether their operations contain work for which such a feedback loop is worth establishing.

The value of Physical AI begins with problems on the ground. Enterprises can examine how equipment and people work together and look for tasks that recur, consume substantial time, and remain difficult to solve reliably with existing systems. Examples include processes that require employees to shuttle between multiple machines, parameter calibration and fault recovery that depend on a small number of experts, or operations whose outcomes vary with materials, equipment condition, and the environment and therefore require people to observe feedback and make repeated adjustments.

The two cases above reflect different on-site bottlenecks. Genentech needed to repeatedly adjust operating parameters for liquids with different physical properties; QuEra needed specialists to handle laser faults that could not be exhaustively anticipated. What they share is the need for a continuously operating feedback chain: equipment performs an action, the physical environment produces an outcome, the system reads that outcome, and then decides the next action. Issuing a single command to a device is not enough to solve this kind of problem.

An enterprise can therefore begin by asking whether the site contains a high-frequency or high-cost feedback process, and whether that process is constraining production efficiency, experiment speed, equipment availability, or the way specialists allocate their time. If the task occurs infrequently and its impact is limited, Physical AI offers little immediate deployment value. When a small group of experts must repeatedly observe, judge, and adjust, however, the enterprise has a stronger reason to assess whether AI can participate.

After identifying an on-site problem, the enterprise still needs to compare Physical AI with conventional automation. Tasks with stable inputs, explicit rules, and fixed actions can generally run over the long term through industrial control systems, specialized algorithms, or prewritten programs. These tools have clear execution logic. There is no need to redesign a task that the enterprise can already perform reliably merely to adopt a new AI concept.

General-purpose AI can add capabilities when device types and interfaces keep changing; on-site feedback includes images, curves, text, and exception information; or a method can be developed only through repeated experimentation. It can understand different forms of feedback, coordinate multiple devices, and test and revise approaches within expert-defined boundaries. The core question is whether existing automation already covers variation in the task, and whether general-purpose AI can handle on-site judgments that are currently difficult to encode.

This distinction can be summarized as follows:

The two approaches can also operate within the same system. General-purpose AI can interpret complex feedback, search for parameters, and generate control logic, while conventional programs handle high-frequency, deterministic actions that require stable execution. QuEra’s approach illustrates this division of labor. For complex laser failures that existing automation could not handle, Claude repeatedly tried different actions on a dedicated test rig, adjusted its approach according to whether the laser returned to its target frequency, and then wrote the validated recovery steps into an inspectable conventional control program. When the same kinds of laser drift or locking failures later occur, the deterministic program performs the recovery; Claude does not need to reason online every time. Enterprises can therefore place general-purpose AI in the stages that most need judgment and calibration, while preserving the advantage of mature automation in stable execution.

After making the first two judgments, enterprises can add equipment and on-site tasks to their existing AI use-case maps. This article proposes a concise Physical AI use-case card that records four items:

• The on-site task to be completed and the person responsible for it
• The equipment involved in the task and the feedback that can be read
• The bottlenecks facing people and conventional automation
• The time, quality, equipment utilization, or expert effort the enterprise hopes to improve

This use-case card helps distinguish technology momentum from an enterprise’s own needs. On-site work with clear business value, recurring demand, well-defined task boundaries, and measurable outcomes can be prioritized for the candidate list. Use cases with real value but unclear feedback data or task scope are better suited to further observation and clarification. Work that mature automation already performs reliably can remain on the existing solution.

Companies with extensive physical operations—such as manufacturing, R&D laboratories, logistics, infrastructure, and specialized medical services—are more likely to find use cases worth evaluating. Tasks that continually consume expert time, require cross-device coordination, or depend on real-time feedback and adjustment deserve particular attention. For businesses with few physical operations, knowledge processing, software workflows, and digital agents remain more direct arenas for AI. After this screening, management should have a map of candidate use cases with explicit problems and expected value, providing a basis for assessing specific deployment conditions.

Finding a use case worth evaluating only shows that the enterprise may need Physical AI. Once AI-generated judgments begin to change equipment actions, management must also confirm that the system can remain under control. In most digital applications, an employee may still catch an incorrect answer before it is acted upon; in a physical environment, one erroneous equipment action can waste materials, damage machinery, interrupt production, or even compromise site safety.

Before a pilot begins, the enterprise must therefore define what AI may read, what it may change, how far its actions may go, and who will stop and take over the system when an exception occurs. Moving Physical AI into real operations requires equipment action boundaries, human accountability, and production validation mechanisms to be established together.

In a software environment, AI permissions usually specify which data may be read, which systems may be invoked, or which outputs may be submitted. In a physical environment, permissions extend to concrete actions such as starting and stopping equipment, selecting motion paths, and changing liquid flow rate, temperature, pressure, or laser frequency. Reading equipment status, proposing a parameter, and directly changing that parameter have very different consequences on the ground and need to be authorized separately.

The preceding section explained how MHS unifies equipment descriptions and invocation. For production control, it also offers a way to express action constraints: equipment can declare what it can measure and adjust, while parameter ranges, safety interlocks, and emergency-stop conditions are written into the interface. AI then operates the equipment within those constraints. The specific parameters must still be set by people who understand the equipment, process, and site safety; the interface ensures those limits actually govern system operation.

Each candidate use case therefore needs an equipment capability and action-boundary checklist that specifies the states AI may read, the actions it may perform, upper and lower parameter limits, prohibited operations, and the conditions that require a stop. This checklist turns equipment knowledge held by on-site personnel into control conditions the system can enforce.

Equipment boundaries can constrain AI’s range of action, but whether a task is complete, whether a result is acceptable, and how an exception is handled must still be assigned to specific people. Before a task begins, the enterprise needs to determine who approves AI’s access to equipment, who defines success and failure, who reviews operating anomalies, and who has the authority to pause the system and take control of the equipment. Accountability must map to formal roles and named personnel; it cannot disappear outside the system simply because equipment operation has been automated.

The way AI participates in operation should also be part of the approval. Stages that require interpreting complex feedback, testing parameters, or handling new conditions can allow AI to make ongoing judgments within defined limits. Actions that have been validated, are stable, and need to be repeated at high speed can be converted into deterministic programs. In this way, the enterprise can control the scope of the model’s online involvement while allowing mature programs to continue providing stable execution.

Enterprises can use this foundation to create a human–machine responsibility matrix, placing AI, conventional programs, equipment operators, business owners, and safety personnel back into the same workflow and specifying each party’s authority, decision responsibility, and takeover conditions. The actions assigned to AI then have clear boundaries, while ultimate operating accountability remains within the organization.

Physical AI trials usually begin in controlled environments. One successful equipment run proves only technical possibility under one set of conditions; entering real operations requires coverage of normal states, common variations, and critical failures. The enterprise must examine not only whether the system completes the task, but also whether it can recognize failure and enter a predefined recovery, stop, or human-takeover process after an exception.

Evaluation metrics need to correspond directly to on-site risks and business outcomes. In addition to task success rate, enterprises can record false declarations of success, fault-recovery time, the number of human interventions, and out-of-bounds actions. With physical equipment, a system that incorrectly declares a task complete may allow an abnormal condition to continue into the next process step. Failure detection and stop capabilities therefore need to be validated as well.

Every run should also leave a traceable record: which states AI read, what commands it issued, what outcomes the equipment returned, where people intervened, and how the system ultimately recovered or stopped. These records help locate faults and allow experience gained during trials to continue updating equipment limits, operating procedures, and human response methods.

Drawing on the cases above, this article organizes these requirements into a “Physical AI Controlled-Operation Checklist.” It places equipment boundaries, human accountability, and operating evidence on one page, corresponding respectively to an equipment capability and action-boundary checklist, a human–machine responsibility matrix, and acceptance metrics and operating records:

The industry signals emerging around Physical AI indicate that the work enterprise AI can perform is extending from processing digital objects to operating physical equipment. MHS provides a cross-device connection method, while the Genentech and QuEra trials show that general-purpose AI can already adjust actions in response to real-world feedback and write validated experience into programs.

Enterprises can begin by determining whether their sites face problems involving continuous feedback, dependence on experts, or cross-device coordination; then compare conventional automation with Physical AI; and finally control deployment through equipment boundaries, human accountability, and operating evidence. Companies with extensive physical operations can begin mapping and validating candidate use cases. Those whose work currently centers on digital processes can continue monitoring the evolution of interface standards and industry cases. Physical AI remains at an early stage, but the direction of enterprise AI—moving beyond the screen and into the real environment—already deserves a place in management’s long-term judgment.

Anthropic still describes MHS as a limited research preview and plans to open-source it later. This list therefore does not treat MHS as an open-source component that is already available. Instead, it identifies candidate projects for in-house development, hybrid delivery, or proofs of concept according to the main capability layers of a Physical AI system. They are provided only as technical selection references and do not constitute a recommended configuration.

• AI agent and tool interface: official Model Context Protocol SDKs. These SDKs can package device drivers, data-reading functions, and control functions as tools callable by AI agents, linking equipment capabilities to upper-layer models.
• Robot communication and task interface: ROS 2. ROS 2 connects sensors, robot nodes, and control programs, and uses topics, services, and actions to carry continuous data, immediate requests, and long-running tasks that require feedback.
• Industrial equipment and OT-system connectivity: open62541. This open-source implementation of OPC UA can read industrial equipment states, exchange control information, and connect PLCs and manufacturing equipment with upper-layer applications.
• 2D and 3D environment perception: OpenCV and Open3D. OpenCV is suited to image processing, object recognition, and machine vision; Open3D is suited to point clouds, 3D reconstruction, and spatial geometry. Together they can help equipment understand its on-site environment.
• Motion planning and equipment control: MoveIt 2 and ros2_control. MoveIt 2 covers robot-arm motion planning, collision avoidance, kinematics, and manipulation tasks; ros2_control handles real-time reads and writes between controllers and hardware interfaces.
• Physics simulation and safety validation: Gazebo and MuJoCo. Before real equipment is put into operation, both can simulate dynamics, contact, sensors, and control strategies to validate action logic, exception scenarios, and safety boundaries.
• Robot data, training, and deployment: LeRobot. It provides real-world robot datasets, pretrained models, and training tools, and connects multiple types of robot hardware through a relatively unified interface. Anthropic also lists Hugging Face among the early MHS adopters; Hugging Face is adding MHS support to LeRobot.
• Operating records and observability: MCAP and OpenTelemetry. MCAP is suited to storing timestamped robot messages, sensor data, and action records. OpenTelemetry can collect traces, metrics, and logs, helping teams link AI judgments, control commands, and equipment outcomes.

These projects provide technical modules that can be combined. Enterprises still need to add drivers and protocol adapters for specific equipment, and incorporate safety interlocks, access control, human takeover, operational monitoring, and production-readiness acceptance into the complete system. During formal selection, they should also verify the licenses of each project and its dependencies for the versions actually adopted.

This article cited or consulted the following public articles and cases, which provide further information on Physical AI industry trends, technical mechanisms, and real-world applications:

• Anthropic, a U.S. artificial intelligence company, “Previewing the Model Hardware Standard,” August 27, 2026. The article explains how MHS works, the first participating organizations, its safety boundaries, and the plan to open-source it.
• QuEra, a U.S. quantum computing company, “QuEra Computing Uses AI to Automate a Critical Quantum Computer Subsystem, Enabling the Acceleration of Commercial-Grade Quantum Computing Deployments from QuEra,” August 27, 2026. The case explains how Claude developed laser-recovery logic on a test rig and then embedded it in an inspectable conventional control program.
• EY Japan, a global professional services organization, “Entering Physical AI: AI’s Next Growth Frontier for Creating Sustainable Industry and Social Impact,” August 4, 2026. The article maps the growth potential of Physical AI across manufacturing, logistics, infrastructure, healthcare, and safety.
• Roland Berger, a global strategy consultancy, “Physical AI: The Next Competitive Advantage for Manufacturers,” August 18, 2026. The article divides Physical AI into four categories—intelligent robots, autonomous mobile equipment, AI-enabled discrete automation, and intelligent manufacturing operations management—and discusses alignment among use cases, IT/OT architecture, and operating models.
• Roland Berger, a global strategy consultancy, “Four Conditions for Japanese Companies to Move Physical AI Beyond the PoC,” August 31, 2026. Drawing on a survey of Japanese companies, the article describes the maturity of Physical AI as it moves from experimentation into real production and identifies the principal conditions for doing so.
• HII, a U.S. military shipbuilder, “HII Signs Performance-based Production Agreements with Path Robotics and GrayMatter Robotics,” August 6, 2026. The agreement shows how an enterprise can structure long-term Physical AI investment around technology readiness, manufacturing readiness, and performance milestones.
• Bedrock Robotics, a U.S. construction robotics company, “Bedrock Robotics Launches First Fully Autonomous Excavator Deployments on Critical U.S. Infrastructure Projects,” August 17, 2026. The case shows autonomous equipment entering real customer sites for clearly bounded construction tasks at water treatment facilities and large earthworks projects.