Hardware MCP: A Hardware Standard for Self-Evolving Laboratories

This capability did not begin as a thought experiment. Over the past several years, our platform has enabled multiple foundation models to connect to and operate laboratory equipment through αLab Studio, using consistent device descriptions and invocation patterns. We have validated multi-device coordination and experimental iteration in real settings such as SE-Fab.

In an August 2025 interview, Dr. Meng Yang, CEO of Genoria, noted that over the next three to five years, AI for life science will focus on deeper integration between laboratory automation and AI. Natural-language interaction will simplify experimental design, allowing researchers to state a hypothesis while the system automatically generates and executes the experimental plan, and progressively builds hardware MCP and software MCP for life science.

Read the interview with Dr. Meng Yang, CEO of Genoria →

That is the long-term direction of Hardware MCP, αLab Studio, and SE-Fab: AI starts from a scientific objective, enters the physical laboratory, invokes instruments, executes experiments, and uses the results to drive the next iteration.

See it in action:

Physical AI entering a life-science laboratory does not start with making a model omnipotent. It starts by making every instrument understandable, callable, and able to respond continuously during an experiment.

01 / An Action That Appears Trivial

For a human technician, removing a seal takes about a second: look at the film, confirm that an edge is lifted, pinch it, and pull. The sequence is already encoded in the human world model through vision, touch, and background knowledge.

In an automated laboratory, “remove the seal” requires a dedicated machine, a 61-page manual, an RS-232 protocol, a dozen commands, three motors, a seal-detection sensor, and a safety interlock. Making it reliable requires a senior engineer to understand the state machine, handle asynchronous messages, decode three-slot error codes, calibrate sensor thresholds, and integrate the interlock.

That is only the problem of making the machine move. AI must also determine when the seal should be removed: whether the sample is ready, when downstream analysis needs it, and whether the seal type matches the current parameters. This context lives neither in the machine nor in an isolated device script. It lives in the complete experimental plan and workflow state.

The complexity of bringing AI into a physical laboratory is therefore not just teaching a model to operate equipment. Device knowledge, state, context, and experience must be understandable, accumulable, and transferable to AI. This is the problem Genoria is working to solve.

A person can complete an action through intuition. An agent needs interfaces, state, constraints, feedback, and experience to complete the same action reliably.

Two Engineering Perspectives

Hardware engineer: “I want to deliver a device with explicit capabilities, states, and safety boundaries without building a bespoke interface for every higher-level application.”

AI engineer: “I want to call a laboratory device the way I call a tool in Codex, rather than rereading a manual, writing a driver, and guessing the state for every instrument.”

When a software agent calls a tool, it generally needs to understand the tool’s capabilities, inputs, and outputs, not the underlying service, function, or machine. MCP and function calling hide those implementation details. Laboratory instruments need an analogous mechanism: the driver makes a device connectable and controllable, while a middle layer makes its capabilities, state, and safety boundaries legible to agents and coordinates it with other devices around an experimental objective.

The middle layer lets hardware engineers deliver understandable device capabilities and gives AI engineers a software-tool-like way to call hardware.

A single seal-removal machine exposes a fact that automation discussions often miss: the endpoint is not replacing a button press. It is converting a physical action into a machine capability that can be discovered, understood, verified, traced, and reused.

That is only one of the simplest device classes in a laboratory. Real life-science experiments coordinate liquid handling, robots, plate readers, imaging, temperature control, sequencing, and data analysis. Before an AI agent can truly enter the laboratory, it must reliably understand and control this hardware.

02 / From Device Control to a Self-Evolving Laboratory

The goal of AI for science is not merely an automated laboratory that executes fixed SOPs.

A more capable form is one in which a person states a scientific question or experimental objective, an agent designs the experiment, coordinates the laboratory equipment, analyzes the result, adjusts the strategy, and starts the next round. The laboratory no longer executes only steps written by a human; under constraints and supervision, it continuously explores, validates, and iterates.

This is what Physical AI means in the laboratory. AI is no longer confined to papers, code, and chat windows. It enters the physical world of samples, reagents, devices, environments, and experimental results.

Life-science laboratories both need and suit this capability because their experiments are multi-step, multi-device, strongly state-dependent, and uncertain. A simple objective can involve sample preparation, liquid transfer, temperature control, imaging, readout, quality control, and interpretation. A state change at any point can alter the next decision.

The five stages below change not the number of devices, but where control and intelligence sit in the experiment:

The progression is from people operating tools, to people defining tasks, to people defining objectives, and finally to AI continuously posing, validating, and solving problems across dry and wet laboratories.

Genoria’s current technical exploration sits in the transition from AI-assisted laboratories to agentic laboratories. SE-Fab, our self-evolving laboratory system, is a primary direction for higher-order dry-wet loops and self-evolving experiments.

Between “AI can propose an experimental objective” and “AI can autonomously complete and iterate experiments” lies an unavoidable engineering problem: software AI must control physical hardware conveniently, reliably, and safely.

We therefore need a middle layer between the agent and device drivers. It translates experimental intent into executable actions, returns device state, sample state, and results to the agent, and carries permissions, constraints, exceptions, logs, and experience through one traceable chain.

The end state of a self-evolving laboratory is defined by AI asking the questions. Its starting point is giving AI a reliable path into the physical world. The middle layer is the infrastructure that connects the two.

Genoria already supports multiple foundation models in discovering and invoking laboratory equipment from Hardware MCP descriptions through αLab Studio.

At the single-device level, an agent can connect to liquid handlers, robotic arms, and other hardware while understanding capabilities, state, and constraints. At the system level, ProtoPilot provides experimental semantics and orchestration so agents can coordinate multiple devices, while SE-Fab uses execution results to adjust later experiments.

An agent is no longer limited to generating a device script. It enters the execution loop: understand the objective, generate instructions, invoke devices, receive state, analyze results, and decide what to do next.

03 / Why Connectivity Is Not Laboratory Autonomy

Earlier laboratory automation focused on three questions: how to control devices, how to connect them, and how to execute a fixed workflow automatically.

Protocols such as SiLA 2 and OPC UA/LADS let equipment from different vendors communicate, expose capabilities, and exchange state more consistently. Workflow engines and integration platforms let devices cooperate according to predefined processes. These are necessary steps from single-device automation to task automation and then to workflow automation.

When a laboratory becomes agentic and self-evolving, the problem changes.

The system must understand the experimental objective, continuously observe device, sample, and environmental state, revise the plan, and use results to choose the next action. The laboratory is no longer just completing commands. It is observing, judging, correcting, and learning during execution.

Traditional device integration is mostly one-way:

Software or scheduler
      ↓ sends commands
Device
      ↓ returns results
Software or scheduler

That is sufficient for many fixed tasks, but not for true laboratory autonomy. Higher-order autonomy needs a continuously running bidirectional environment:

Agent
 ↕ objectives, state, events, constraints, feedback
Experimental semantics and orchestration layer
 ↕
Device A ↔ Device B ↔ Device C

In this environment, the agent receives state, events, and exceptions instead of only sending commands. Devices share state, resources, and constraints around one objective instead of merely exchanging data. Experimental results feed the next plan instead of ending as one-off outputs.

An Agent Ready laboratory must at least answer:

• What role does this device play in the current experiment?
• What state are the samples, reagents, and consumables in?
• Are the preconditions for the next action satisfied?
• How do multiple devices coordinate around one objective?
• Is an exception a software problem, a device problem, or a physical experiment failure?
• How should the result change the next strategy?
• How can the experience from this experiment be reused by the next experiment and the next agent?

This is why a device being connected does not mean the laboratory can operate autonomously.

Anthropic’s Model Hardware Standard (MHS) is an important attempt in this direction. It gives physical devices a common agent-facing representation so they can expose capabilities, state, constraints, and safety information more consistently, making different devices easier for AI to integrate and orchestrate.

Hardware MCP follows a related direction and organizes device context for life-science laboratories. It describes not only what a device can do, but its current state, how it collaborates with other devices, and how execution results feed back into the experiment.

Behind this is our view of hardware standards: technology and industry each have a hurdle to clear. Technically, devices must be natively legible to agents. Operations should converge on a minimal read/write vocabulary, so learning it once is enough to operate every device. Devices should be automatically discoverable, without handwritten adapters for each integration. Knowledge scattered across manuals and engineers’ experience, including load ceilings and safety boundaries, should be delivered to the agent as part of the interface. Capabilities should be exposed through MCP, command-line interfaces, and code at the same time, making the cost of orchestrating many devices nearly the same as operating one.

At the industry level, this redistributes authority over how device value is defined. A significant part of vendor lock-in comes from proprietary scheduling software rather than the mechanics themselves: once a workflow is built around that software, replacing a device means rebuilding the workflow. A standard loosens this binding and returns the basis of comparison to device performance and price, while devices that retain closed proprietary software layers will remain outside the automated laboratory. A good hardware standard changes more than device integration. It changes who has the power to define and price device value, returning choice from scheduling software to the laboratory.

Device connectivity answers whether devices can talk. Laboratory autonomy answers whether devices, agents, and experimental state can complete something together.

04 / Genoria’s Approach: From Command Forwarding to Experimental Collaboration

Hardware MCP does not replace existing device drivers or reinvent SiLA 2, OPC UA, ROS, or vendor SDKs.

Our technical proposition is a life-science-oriented middle layer between device drivers and AI agents. It connects different devices, protocols, and agents to one experimental objective.

In one sentence:

A driver makes a device controllable. Hardware MCP makes devices collaborate around an experimental objective.

The traditional middle layer focuses on command forwarding and workflow scheduling. We want to advance it into an experimental-loop layer that understands experiments, manages state, organizes devices, handles feedback, and accumulates experience.

1. Experimental Intent

   The system first understands the experimental objective rather than a device command, then turns intent into a task that machines can execute, check, and trace.

2. Capability Abstraction

   Devices from different vendors, interfaces, and integration patterns should expose a common capability model. Agents can discover and invoke those capabilities without directly understanding every protocol, SDK, state machine, or error code.

3. Bidirectional Device-Agent Communication

   An agent does not only send commands. It continuously receives device feedback, moving the system from calling tools to managing an experimental process.

4. Device Collaboration

   An experiment is not a sum of isolated actions. Devices must share sample, resource, spatial, dependency, and safety state around the same objective.

5. Dynamic Orchestration and Replanning

   Real experiments do not always follow the initial plan. The system must use live device exceptions, sample state, and QC results to revise later steps.

6. Experience Distillation and Skill Reuse

   Logs, exceptions, and human judgments should not disappear when a task ends. They should become reusable device knowledge and experimental skills.

7. Safety and Evidence Governance

   Physical safety cannot depend on a model remembering to be careful. Parameter limits, hard interlocks, permissions, approvals, simulation, escalation, operation logs, and experiment provenance must be part of the system design.

One paragraph, a team of agents, one interface, an entire laboratory. A scientist states an intent → AI agents (SE-Fab and the ProtoPilot harness) plan and execute → Hardware MCP drives every instrument through one unified layer → results flow back in real time for automatic optimization. From an idea to experimental results, this is a true end-to-end closed loop.

We are not making an agent control one device. We are making devices from different protocols and vendors collaborate around one experimental objective.

05 / Core Design: Types Are Skills, Instances Are Records

The architecture of Hardware MCP can be stated in one line: Agent → Hardware MCP → Instrument. The agent does not face the instrument directly. It faces a structured filesystem: HardwareType carries shareable model knowledge, while HardwareInstance carries the live record of one device.

Directory Tree

Hardware MCP/
├── HardwareType/                     # model library: shareable across agents
│   └── AlphaTool/
│       ├── type.md                   # model metadata + natural-language notes
│       ├── protocol.yaml             # transport and MCP / CLI / SDK bindings
│       ├── capabilities.yaml         # get/set capability map
│       ├── safety.yaml               # safety boundaries enforced by the driver
│       ├── references/               # manuals and interface documentation
│       └── simulation/               # driver simulation and validation
└── HardwareInstance/                 # environment-specific instance library
    └── AlphaTool-01/                 # example AlphaTool liquid handler
        ├── instance.md               # instance metadata; must reference a type
        ├── connection.yaml           # IP / port / serial connection
        ├── relations.yaml            # robot-only interaction topology
        ├── experience.md             # accumulated experience
        └── log/                      # instrument operation logs

The filesystem is the standard: readable by any editor, parseable by any agent framework, and versionable with git.

Type, the model class: shareable and reusable across agents; stable while the model remains stable.

Instance, the object record: environment-specific, linked to a type, and responsible for experience and logs.

Five HardwareType Files

Five HardwareInstance Files

Hardware MCP principle: safety boundaries are declared at the type layer, enforced at the driver layer, and independent of the model. A model may be wrong or misled, but it cannot bypass hard_limits through dialogue.

06 / Interaction Flow: Seven Steps for an Agent to Learn an Instrument

Hardware MCP formalizes how a human technician becomes familiar with an instrument into seven steps. Steps 3 and 7 are absent from static standards and form the interface to the self-evolving loop.

Two of the seven steps deserve separate emphasis. Step 3, LOAD: Before connecting to the physical instrument, the agent reads its instance.md and experience.md, much like a mentor telling a new employee before their first shift, “This instrument needs preheating in winter, and the left channel drifts slightly.” Step 7, DISTILL: After the operation, the agent proposes writing conclusions from exceptions and troubleshooting back to the experience library, and a human confirms the entry. These two steps turn “learning an instrument” from a one-time action into a continuous process. They are the entry point to the self-evolving loop in the next section.

Difference from static standards: In traditional device standards, integration is the endpoint. Feature definitions and information models are written at deployment and then remain unchanged. Hardware MCP explicitly adds LOAD (reading experience) and DISTILL (writing experience) to the workflow, making device knowledge a first-class citizen within the process rather than a note outside it.

07 / First-Principles Design: Self-Evolution as a Living Standard

Most standards solve the problem of connection. Hardware MCP also has to solve growth. A hardware standard for the agent era cannot passively describe devices; it must learn from every use so device knowledge accumulates like the experience of a human technician.

The Self-Evolving Loop

log/ is the raw material of self-evolution. The driver automatically records the parameters, results, and duration of every operation as JSON Lines, while errors are archived separately. These records are the device’s memory neurons: complete, objective, and persistent. experience.md is the distilled product of self-evolution. It is appendable and updateable, and each entry follows five parts: observation, investigation, conclusion, recommendation, and source. When a technician discovers that a temperature-control module cannot reach its theoretical 37°C target in winter, that experience is recorded. When an agent identifies a recurring low-volume drift pattern in channel 3 from the logs, it proposes a new experience entry, which is added after human confirmation.

This mechanism has a more widely recognized name: the dry-wet loop. On the dry side, models propose hypotheses, design experiments, and generate protocols and code. On the wet side, automated equipment executes those protocols, records results, and exposes failures. Real data then flows back to the model and drives a more accurate next design. ProtoPilot’s private deployment has already taken a concrete step along this path: AI-generated protocols or existing protocols uploaded by users are first parsed and validated on the device, then released after human confirmation. During execution, the system continuously reports the active instruction, elapsed time, and exception information, while preserving a traceable and replayable task record. Hardware MCP’s log/ and experience.md are the device-side carriers of this loop. Without them, every wet-side failure remains noise instead of becoming a signal that strengthens the next dry-side iteration.

Three Qualitative Changes

First, the more a device is used, the better the agent understands it. The first temperature-control deviation may take thirty minutes to investigate. The second time, one look at the experience record can reveal that preheating is required.

Second, experience transfers across agents. Agent B does not need to repeat the failures encountered by Agent A because the knowledge belongs to the device record, not to an agent’s private memory.

Third, experience can improve the model library. When several instances show the same pattern, the reviewed rule can move up into HardwareType. The instance layer learns as an individual; the type layer evolves as a population.

08 / Deployment Paths: Making Every Instrument Agent Ready

Even a strong standard must deal with existing instruments. We define three tiers so devices from any era and with any interface can enter the Hardware MCP ecosystem and its self-evolving loop.

TIER 1 · Native Agent Ready Devices

Liquid-handling workstations such as PrepALL, AlphaTool, and Opentrons, the αCube BioXpert bioinformatics AI inference appliance, and the αBrain companion brain can ship with a complete HardwareType package: capabilities, safety boundaries, and a simulator. The private-deployed companion brain validates protocols on the device, requires human confirmation, and records tasks that can be paused, resumed, or stopped.

Experience completeness: 100%. This is the upper bound and an answer to what an instrument should look like.

TIER 2 · Platform-Generated Devices

For equipment with interface documentation but no agent layer, the platform parses manuals and interface specifications to generate a HardwareType draft with protocol bindings, capability catalogs, and safety boundaries. Engineers review and confirm it. Integration time moves from days toward hours.

Experience completeness: 70%. A one-off integration project becomes a reusable platform capability.

TIER 3 · GUI Agent and Robot Fallback

For legacy instruments equipped with nothing more than buttons and a screen, a GUI agent can “read the display and press the controls” like a person, while autonomously directing a robot to physically open and close doors and load samples. Operation logs are still written to log/, and experience is still distilled into experience.md. Ideally, from an agent’s perspective, a centrifuge manufactured in 1998 should look no different from a modern native device.

Experience completeness: 35% · Full coverage of installed equipment.