Anthropic's announcement of 27 August 2026 opens a research preview of the Model Hardware Standard. MHS is a specification for describing a machine to an AI agent, so the agent can operate it. Anthropic's announcement says the description covers what the device can measure, what can be adjusted on it, and "what safety limits will be enforced". It works with any device that has a programmable interface, Anthropic says, and with any model, not only Anthropic's. The project site says access to the specification is by application during the preview, and that the standard will be open sourced afterwards. I tried to read it and found that application form where the document should be.

The pitch is integration time. Anthropic's case is that most lab and factory devices do not talk to each other, so a specialist builds a bespoke bridge for every pair, setting up a facility takes weeks or months, and MHS cuts that to hours or minutes. Elizabeth Kelly, Anthropic's head of beneficial deployments, told CNBC the company "built this for science to sort of show the promise of AI, but there's also huge benefits here for enterprise and for industry", and CNBC described the result as a USB-C cable for machines. Anthropic's Alek Kemeny told The Next Web that "what MCP did for software, MHS will do for the hardware world".

Seventeen years of lab device standards

Anthropic is not the first to reach for that comparison in this industry. The SiLA consortium dates its first laboratory device interface release to 2009 on its own standards page, and it is still asking vendors to implement the thing. That page describes the current version, SiLA 2, as running over HTTP/2 and using Protocol Buffers to serialise payload data, relying on the wire format specified by gRPC rather than inventing a transport of its own. The same page says version 1.1 added a connection method so instruments sitting on isolated lab networks can reach the cloud. As protocol design goes, none of that is primitive.

It also carries an admission. The consortium's own curated list of implementations states that "our ultimate goal at SiLA is to motivate companies, both software and hardware vendors, to integrate native SiLA support into their products". Motivating vendors is still the goal, seventeen years after the first release. The end state SiLA describes runs through the manufacturer, and the consortium is still asking for it.

Nor is SiLA the only thing a lab could use today. PyLabRobot's documentation describes it as a free, hardware-agnostic Python library that drives Hamilton STAR and Vantage liquid handlers, the Tecan Freedom EVO and the Opentrons OT-2 through a single interface on Windows, macOS or Linux. SiLA is a published standard and PyLabRobot is a library that makes no such claim, but both are public, both give a lab one interface across instruments from different makers, and both are older than MHS. PyLabRobot's paper carries an October 2023 date in the journal Device. So when the MHS announcement says that so far "there has been no standardized way" to integrate these devices, the sentence is carrying a qualifier it never states. What the SiLA consortium's own list still frames as an aim rather than a fact is native support inside vendors' products, and that is a fair indication of where the shortfall has been.

The part that is new is the writing

Since the specification cannot be inspected, what follows is a reading of the announcement rather than of the spec. On what Anthropic has described, the part it presents as new is not on the wire at all. MHS carries tags that let a person write down, in plain language, the machine characteristics that Anthropic says "may not be discernable from code alone". Its example is the weight of a robot arm, which matters for knowing how to move it safely. From those tags, Anthropic says, the driver generates a reference file covering what the device can measure, what can be adjusted and what limits apply. The tags can be filled in either by the user directly "or by chatting to an agent that interviews them about their hardware setup". Those are two artefacts, the tags and the file; I'll call the pair the description from here.

That is the bet, and it is sharper than the USB-C line suggests. The end state SiLA describes waits on the manufacturer shipping native support. MHS still needs a programmable interface on the device, so the machine's own software is still in the loop, but it allows the description to be written by someone other than the manufacturer. That moves the work away from persuading manufacturers, which is exactly where the SiLA consortium says its remaining task lies.

The case for the messy version

The strongest argument against my scepticism is that the mess is the feature, and Anthropic's partners make it well. Anthropic describes the status quo as information stored "in paper manuals, on a user's computer, or as tacit knowledge". Measured against that, rather than against an idealised SiLA-conformant instrument, a description an agent can query wins. Anthropic also reports that the lessons from one failed run were "codified into reusable liquid handling skills" for Claude. The artefact that improved there was the skill library, not the device description, and the two solve different problems. They are the same move, though. Knowledge that lived in somebody's head got written down where an agent could reach it.

Genentech's contribution to the announcement is the evidence. Its researchers ran the BCA protein assay, a standard procedure for measuring total protein concentration in a sample, across a liquid handler, a robotic arm and a plate reader, with Claude orchestrating all three. Genentech's write-up says that when Claude was asked to tune the flow rate for liquids that behave differently under pressure, it ran trial transfers, read the plates and settled on roughly 140 µL/s for water and 10 µL/s for viscous bovine serum albumin, with root mean square errors of 0.016 and 0.181 against a reference transfer. Genentech says its automation experts confirmed both figures were reasonable for that setup, and that Claude recovered on its own from tip pickup failures and fluid detection errors, "a capability that current scientific instruments mostly lack". In the same announcement, Zihao Song, a PhD student in the University of Washington's Baker and Pinglay labs, describes using MHS to build three things: a dashboard for monitoring instruments remotely, collision-free plate handoffs between a robot arm and a liquid handler, and an agent that supervises a qPCR run. That last one watches the curve showing how much of a target DNA sequence has been copied as the sample cycles through heating and cooling, and halts the run at the right moment.

What the demo also shows

The same write-up contains the limit, stated plainly, which is to Anthropic's credit. The optimisation loop was not open-ended. Genentech's account says it gave Claude an expert-defined range of flow rates to explore, and a ground-truth transfer performed by a human expert in the same plate to score itself against. Both inputs came from people who knew the problem well enough to bound the search and supply a benchmark.

Then there are the bubbles. Genentech reports that when viscous protein solutions foamed and threw hardware errors, Claude's instinct was to retry in the same well with different parameters, which agitated the fluid and produced more bubbles. Its scientists had to tell the model that the error code meant physical bubbles, and that the fix was a clean well and fewer mixing cycles. Anthropic's own summary of the episode is blunt: models "still struggle with physical, chemical, and biological constraints, particularly when troubleshooting errors that call for real-world physical intuition".

Set that against the authoring model and the shape of the risk gets clear. A description is only as good as what its author knew to write down. The bubbles show what it costs when the relevant fact is not in front of the model, and the fix there came from Genentech's own experts. My worry about the interview format is narrower than it sounds. An agent questioning a busy scientist collects answers to the questions it thinks to ask, and I would expect those questions to be shaped by the machines that came before.

When the file meets the Machinery Regulation

One reason to care about who writes the description is regulatory, and it has a date. Regulation (EU) 2023/1230 replaces the Machinery Directive, and its Article 54 reads: "It shall apply from 14 January 2027." Recital 19 of the same regulation says that software performing a safety function and placed independently on the market should be considered a safety component. Annex I, Part A lists, at item 5, "Safety components with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions". Article 25(2) says that where a product falls in Annex I, Part A, the manufacturer must apply EU type-examination followed by conformity to type, or full quality assurance, or unit verification, and the regulation routes each of those three through a notified body. Article 25(3), which covers Annex I, Part B, does allow internal production control on its own. Part A does not get that option.

Whether an MHS reference file falls inside those definitions is unsettled, and I would not pretend otherwise. It turns on what the file is placed on the market as, by whom and for what purpose, and I could not find a published test of any of it. Annex I's wording is about components that ensure a safety function and change their own behaviour through machine learning, and classification turns on what a thing's intended safety function is and how it reaches the market. On that reading a description file taken alone need not qualify, and an agent tuning a flow rate between runs need not either. The open question is whether a file that states which limits will be enforced, sitting underneath an agent that adapts, gets assessed as one system or two. Somebody's lawyer will end up answering that. Anthropic says it is working with preview partners to "build safety evaluations and develop best practices" before open sourcing.

Anthropic says the description can be authored by the user, or by an agent interviewing the user. That is the property that allows a lab to adopt MHS without the instrument makers writing anything, and it is the same property that can leave the document telling an agent what limits apply in the hands of someone who did not build the machine.

The bet

What I will be watching is authorship. If the descriptions come from the people who built the machines, the manufacturers have finally turned up and the USB comparison has a chance. If they keep coming from the people who bought them, MHS is good plumbing for Claude with a specification attached.

The test is mine rather than the regulation's: has any instrument manufacturer published an MHS description for a device it sells, with the stated limits warranted by that manufacturer, by 14 January 2027? I am borrowing that date from Article 54 as a deadline, not claiming the regulation forces the result. I'll be wrong about where the friction sits if one does. That would be vendor-authored device support arriving through a door the SiLA consortium has been knocking on since its 2009 release. My expectation is that the descriptions in circulation on that date are still written by end users, and by agents interviewing them, and that the integration time saved gets paid back the first time a limit nobody thought to write down turns out to have mattered.

There is a smaller test available sooner. Anthropic's MCP announcement of 25 November 2024 opens with the words "Today, we're open-sourcing the Model Context Protocol". MHS has an application form instead. I would expect the conventions settled in that room this year to be the ones the open version starts from, which is a reason to care who is in it.