Vol. 1 · Edition 041Free · No paywall

Everyone Needs a Samwise

AI news · Synthesized · Opinionated · 🌿

Previous

Weeks
→

Now

Hours
device integration with Model Hardware Standard
Tools & Infra
By Sam Taylor with Samwise

On standardized primitives over MCP, autonomous round-the-clock experiments, and whether AI safety labs should be in the lab-automation business

There's now a standard for AI agents to operate lab robots. It's the infrastructure layer nobody was writing about.

Source lean on this story
▲ avg

Anti-AI

00

Skeptic

01

Neutral

00

Pro (practical)

03

Pro (hyped)

00

← Anti-AI · Pro-AI →

Device integration for lab automation has a dirty secret: every instrument speaks a different language. A liquid handler from Tecan doesn't talk to a microscope from Leica the way either of them talks to a robotic arm from Universal Robots. Getting an AI agent to orchestrate all three has historically meant building a custom translator layer for each pair. That's why sophisticated lab automation has been a specialist skill, not a default one. Weeks of integration work per device, minimum.

Anthropic and HHMI Janelia published a research preview on August 27 that tries to fix this. The Model Hardware Standard (MHS) is a shared specification defining how any AI agent communicates with any physical lab device — microscopes, liquid handlers, plate readers, robotic arms — via a common set of primitives exposed over Model Context Protocol. The claim: device integration drops from weeks to hours. Developers can apply for access now at modelhardwarestandard.com.

This is USB-C for AI-controlled lab equipment. Unsexy name, real problem being solved.

Source spread

Pros & cons

What's real:

  • The abstraction is the right one. Two primitives — "read" (get a sensor value, capture an image, retrieve state) and "write" (set temperature, start a centrifuge, dispense reagents) — cover the vast majority of lab automation tasks. Simple vocabulary over a standard channel. Claude Code already speaks MCP natively; this is a natural extension.
  • Partner breadth is genuine. Genentech is not a research vanity partner; they run industrial-scale bioassays. Danaher is a conglomerate that owns half the lab instruments in existence (Leica, SCIEX, Beckman Coulter, Cytiva, among others). If MHS has Danaher buy-in, the addressable device pool is enormous.
  • The "autonomous round-the-clock experiments with real-time parameter adjustment" framing isn't hype for this use case. Biology experiments have natural wait times — incubation, amplification, crystallization — that create scheduling complexity humans paper over with sleep schedules. AI agents don't have this problem. 24-hour continuous assays where the agent adjusts protocol parameters based on intermediate readings are now at least architecturally possible with MHS.
  • Open-source-bound after safety evaluations is the right policy. Locking lab-control drivers inside a proprietary platform would fragment the ecosystem immediately.

What deserves a side-eye:

  • "Research preview" means early. No GA date, no pricing model. Access is by application. The partner list is real but the production deployments aren't public yet.
  • Safety evaluations before open-sourcing is appropriate but vague. "Safety" in lab automation includes things like liquid handling errors, equipment crashes, and protocol mistakes that destroy expensive samples — not just the AI safety concerns Anthropic usually focuses on. The overlap between those safety regimes isn't spelled out yet.
  • MHS doesn't solve the software side of lab automation — LIMS integration, data provenance, regulatory compliance for GxP workflows. It solves device control. Those are complementary gaps; don't conflate them.
Lab device integration: before and after MHS
TaskWithout MHSWith MHS
Add a new device to an AI workflowWeeks of custom driver developmentHours (reuse shared MHS driver)
Cross-vendor device coordinationCustom translator layer per device pairStandard MCP primitives across all devices
Protocol for overnight experimentHuman scheduling or custom automation scriptAI agent with real-time parameter adjustment
Driver reuse across labsUsually not — proprietary or fragmentedPlanned: public driver registry

Samwise's take

What builders need to know

  • Access: Apply at modelhardwarestandard.com for research preview access. No GA timeline announced. Partners with existing relationships to the listed instrument vendors (Danaher, Tecan, QIAGEN) may get faster traction.
  • Integration model: MHS wraps devices in read/write primitives exposed over MCP, CLI, and code APIs. If you're already building on Claude's MCP stack, this is additive, not parallel.
  • Driver portability: Drivers developed for specific instruments are intended to be publicly reusable — the goal is a shared registry. Don't build private drivers without checking whether a public one exists first.
  • Natural-language metadata: Devices support plain-language metadata tags for documenting characteristics. This is useful for multi-agent experiments where you need to pass instrument context between agents without custom schema.
  • The open-source timing matters: Don't build production workflows on MHS drivers until they're public and auditable. Research preview access is for prototyping and feedback, not production deployments.

Further reading

🌿

Liked this? Get the weekly digest.

Free. Monday mornings. The week's stories, synthesized. Unsubscribe anytime.

Your take

How'd I do on this one?

What did I miss?

Tell Samwise (and Sam).

Disagree with the take? Spotted a fact I got wrong? Have context I should have included? Drop it here. Anonymous unless you leave an email.