Lab Automation Lacks a Common Language — and It’s Holding Science Back

Lab automation in 2026 is predicted to outgrow conventional lab workflows. It reduces the need for skilled labor, reduces costs and ensure reproducability of results. However for all it’s touted benefits it still surprisingly lacks an open communication standard that instrument manufacturers can integrate into their tech. This means every robot, reader and analyzer in your lab speaks its own dialect, has its own data formats and integration is sold back to you as a service. We look below at why an industry heading toward $10 billion a year never had its Matter (home automation open standard) moment, why your data is trapped in vendor file formats, and why the manufacturers that embrace openness — not the ones defending their walled gardens — will define and occupy the next decade of the lab.

Consider what other industries managed: EV charging runs on OCPP, a free protocol now written into law in the US and UK, so any charge point can talk to any network. Home automation — an industry selling $30 light bulbs — got feirce competitors Amazon, Apple, Google and Samsung to sit at one table and ship Matter. Medical imaging did it back in 1993 with DICOM; before that, nobody but the manufacturer could decode a scanner’s images — sound familiar? Even the music industry solved this in 1983: two rival synthesizer makers built MIDI, gave it away, and forty years later it still runs every studio on earth.

And yet a high-throughput single-cell analysis lab running a million-dollar automated workflow in 2026 still glues instruments together with vendor middleware, custom drivers, and — increasingly — volunteer-maintained open-source code that had to be reverse-engineered because the manufacturer wouldn’t document its own protocol. For an industry whose entire purpose is accelerating science, that is not a technical failure. It is a choice. It is, frankly, a disgrace.

Every other industry solved this. Why can’t the laboratories?

The pattern elsewhere is remarkably consistent: an industry hits an interoperability wall, the biggest players or rather competitors grudgingly form a consortium, a royalty-free standard ships within a few years, and the market expands for everyone — because buyers stop hesitating when they stop fearing lock-in. MIDI took about a year from proposal to shipping product. USB went from working group to version 1.0 in under two years. Matter went from announcement (2019) to launch (2022) with the most cut-throat competitors in consumer tech co-writing the spec.

Now look at the lab’s open source attempts timeline. AnIML, the XML format meant to free analytical data, started at ASTM in 2003 and has never left draft status. SiLA, founded in 2008 expressly to standardize lab device communication, took until 2019 to ship SiLA 2 version 1.0 — and only a handful of instruments from a couple of manufacturers support it. OPC UA LADS, the newest and arguably most promising effort to standardize communication and data exchange between laboratory devices, released version 1.0 in December 2023 (3 years ago, with 2.0 not even mentioned anywhere), twenty years after the lab connectivity problem was first formally attacked, however only two dozen companies have signed up to integrate these standards. No prediction when any of these standards will achieve widespread adoption.

The one time lab vendors agreed — and what it bought us

Here’s the thing: the industry has proof that standards work, because it wrote one — once. In 1996 the Society for Biomolecular Screening began standardizing the humble microplate, and in 2004 ANSI ratified it. Every 96-, 384- and 1536-well plate on earth now shares one footprint: 127.76 mm × 85.48 mm. That single agreement is why any gripper can pick up any plate, why any liquid handler or a pipettte can feed any reader, why stackers, washers, sealers and incubators from rival vendors bolt together into one workcell at all. The ANSI/SLAS footprint is a proven foundation of every automated lab built since — and the strongest argument that a shared standard grows the market instead of shrinking anyone’s revenue.

The physical plate got a standard however the signals and the data never did. Twenty-two years later, that is exactly where the plumbing still leaks and will lead to bigger problems when robots and automation become more prevalent.

The standards that exist — and why none of them has won

It’s not that nobody tried. The lab world currently has at least four serious open-standard efforts running in parallel — which is part of the problem, because a fragmented standards landscape gives every vendor a reason to wait and see.

Some comapanies like AUTOMATA are building their own standards (open or not, that’s debatable) in the form of LINQ. The automation platform helps develop and simulate workflows – all in python.

Why hasn’t any of these become universal lab’s lanugage as Matter became a home’s universal language? Three reasons, and only one of them is technical. Firstly, labs are genuinely heterogeneous — a liquid handler, a mass spec and a −80 freezer have less in common than two EV chargers do. Second, the standards themselves competed: SiLA vs. OPC UA, ADF vs. AnIML, each with its own consortium, membership fees and politics. But third — and decisively — the biggest vendors had no commercial incentive to make their instruments easy to leave or even enforce new skills onto resaerchers who have become accustomed to their software. An instrument that only works properly inside the vendor’s software environment sells software licenses, service contracts and, eventually, the next instrument from the same catalog. Interoperability was never a missing feature, rather it is perceived as a threat to the business model. The idea persumably killed at every inter company meeting.

Your data, their format: the quiet scandal of proprietary files

The same thinking that kept instruments from talking to each other ensured that the results — your science, generated on your samples, on hardware you paid for — lands formats you cannot read without the vendor’s software. Chromatography and mass spectrometry are the worst offenders: nearly every major vendor writes its own undocumented binary format, and much of what the open-source world knows about them comes from reverse engineering, not documentation.

Think about what this means in practice. Converting your own mass spec data to the open mzML format usually still requires the vendor’s own reader libraries, which run only on Windows. The maintainers of chromConverter, an open-source chromatography converter, state plainly that most of the formats they support are not publicly documented. And the community answer — Benchling’s open-source allotropy library, ProteoWizard’s msConvert — amounts to unpaid engineers doing archaeology on file formats that the vendors could simply publish tomorrow, at near-zero cost. The data-trapping is not a side effect. For decades it was a product strategy: the format is the moat, and the paid analysis software is the toll bridge.

“Has an API” is not the same as “is open”

As pressure mounts, vendors have discovered the word “API.” Datasheets now advertise programmatic access the way they once advertised touchscreens. Progress? Yes — an API is far better than none. But the team at Veon Scientific, the UK maker of the i.prep 2 liquid handler, made a sharp argument in a recent essay that deserves a wider audience: an API is a feature, while openness is an architecture — and bolting the first onto a closed system does not produce the second.

Their distinction is worth internalizing. Many instruments today expose an API that is really a remote control for the vendor’s own application: your code talks to the vendor software, and the vendor software still owns the workflow, the state and the execution. You haven’t opened the instrument; you’ve made the monolith remotely controllable but not understandable. A genuinely open instrument puts the API at the device level — every capability the hardware has, exposed directly — so a scheduler, a LIMS, a Python script or an AI agent can drive it without impersonating a human clicking through a GUI.

Openness, in this framing, is a bundle of practical questions, not a philosophy. Can the instrument be controlled by something other than the vendor’s application? Do you get its real capabilities, or only permission to trigger methods the vendor software already knows? Can external code see the instrument’s state, get meaningful errors, and recover it after a fault? Can another machine physically load it, or does the enclosure assume human hands? And the question procurement heads should tattoo on their forearm: do we have to keep paying a software license to use capabilities baked into hardware you already own? Veon’s own conclusion — after admitting they built the classic GUI-first system themselves the first time around — is that you cannot build openness onto a closed instrument; you have to design for not being in control of how customers use it. Legacy platforms carry what they call architectural gravity: twenty years of installed systems, validated methods and customer workflows built inside a vendor environment make truly opening up genuinely hard. That earns some sympathy, but it doesn’t earn a pass.

Who is actually fixing it

The most energetic force for interoperability right now isn’t a consortium — it’s open source. PyLabRobot, which grew out of Kevin Esvelt’s Sculpting Evolution group at the MIT Media Lab and is described in a peer-reviewed Device paper, is a hardware-agnostic Python framework that drives liquid handlers and peripherals from different manufacturers — Hamilton STAR and Vantage, Tecan EVO, Opentrons OT-2, plus plate readers, pumps, scales and heater-shakers — through one common interface. In other words: exactly the abstraction layer the industry should have standardized, built instead by researchers and volunteers, much of it by reverse-engineering firmware protocols the vendors never published. The community has even produced the first way to run Hamilton’s Microlab Prep without touching its built-in screen. The effort is admirable — and a little damning. As the Veon team put it: manufacturers should look at how hard these volunteers work to make instruments usable outside vendor software, and feel uncomfortable and ashamed of what they have done.

Encouragingly, cracks in the wall are appearing. Veon says it will build and maintain the i.prep 2’s PyLabRobot integration itself — the manufacturers keeping its own hardware honest under a community abstraction, rather than leaving volunteers to do archaeology. Hamilton is now actively promoting an API for the Microlab Prep, pitching workflows “beyond the UI” — you don’t market that unless customers are demanding it. Opentrons built its business on an open Python API from day one and dragged list prices down for the whole segment . On the data side, Benchling open-sourced its ASM converter library, and the LADS group is running hackathons with Agilent, Shimadzu and Waters in the room. None of this is a common standard yet.

AI agents are about to make closed instruments look absurd

For twenty years, the cost of closedness was borne quietly by researchers scouring through technical manuals. What changes now is who — or what — is trying to drive the instruments. AI co-scientists are generating validated hypotheses at an unprecedented speed, agent frameworks are stacking up scientific skills, and companies from Lila Sciences to Medra are wiring models directly to robots. Cloud labs already take experiment requests through an API and hand back data; the logical endpoint is a one-person company running a full discovery loop.

An AI agent cannot click through a vendor GUI — and pretending to (screen-scraping, button-pushing macros) is a support nightmare nobody will validate. Agents need what every other integration always needed, only non-negotiably: capabilities, state and errors exposed programmatically. When the software around the instrument can be generated in hours instead of quarters, the question flips from “does the vendor’s application support my workflow?” to “does the instrument expose enough for me to build it myself?” Instruments that can’t answer yes will simply be designed out of the next generation of labs — the self-driving-lab literature already names protocol fragmentation as the single biggest brake on the field.

What buyers should do about it (and what vendors should fear)

Standards consortia move at the speed of their slowest member. Procurement moves markets in a quarter or if we are being pessimistic, in years. If openness shows up in tenders as a scored requirement, it will show up in products within two product cycles — that is precisely how OCPP conquered EV charging, and how Matter got muilti-trillion-dollar rivals into one working group. Until then, the practical defense is to buy as if lock-in were a line-item cost, because it is.

FAQ

Is there an open standard for lab automation?

Not one in general use. SiLA 2 (device communication, v1.0 in 2019) and OPC UA LADS (v1.0 in December 2023) are open standards, but most instruments still ship without native support for either. For results data, Allotrope’s ASM is gaining ground while AnIML remains a draft after 23 years. The only truly universal lab non-automation related standard is the ANSI/SLAS microplate footprint, ratified in 2004.

What is the difference between SiLA 2 and OPC UA LADS?

Both standardize instrument communication and are increasingly viewed as complementary rather than competing. SiLA 2 is a lab-native, gRPC-based standard from the SiLA Consortium focused on device features and control. LADS is a companion specification of the industrial OPC UA framework, backed by the OPC Foundation, SPECTARIS and VDMA with sponsorship from Agilent, Shimadzu and Waters, and inherits mature industrial tooling for monitoring and integration.

What is PyLabRobot?

PyLabRobot is an open-source, hardware-agnostic Python framework — MIT-licensed and described in the journal Device — that provides one programming interface across liquid handlers and lab peripherals from different manufacturers, including Hamilton, Tecan and Opentrons machines. Because most vendors never published their protocols, many of its device backends were built by a few code literate researchers reverse engineering; a few forward-looking manufacturers are now starting to maintain their own integrations.

Why do lab instruments use proprietary data formats?

Partly history, mostly business model: an undocumented format keeps analysis, review and reprocessing inside the vendor’s paid software ecosystem. Open formats exist — mzML for mass spectrometry, Allotrope ASM for a growing range of techniques — but instruments rarely write them natively, so labs depend on converters like ProteoWizard, chromConverter and Benchling’s allotropy, many of which rely on reverse-engineered readers.

Keep reading on Labcritics

Our Lab Automation & Liquid Handling Buyer’s Guide turns this argument into purchase criteria. Browse 4,000 instruments across 848 manufacturers in the Labcritics product database, compare automation-friendly software in the Tools directory, or see how labs are stitching stacks together today — from semi-automated pipetting to fully robotic cloud labs and low-cost LIMS/ELN setups.