A Self‑Healing Lab?

On Labor Day, I snuck into our empty office to do an important milestone test on some of the software we've been developing over the last couple of years. I wanted to answer a key question: what is possible when agentic AI has not only access to control hardware, but also the real-time physical state of the lab, and on top of that, the full ability to rewrite (on the fly) the control software for that hardware?

So, I unleashed Vector (our autonomous mobile robot) under full AI control. I gave the AI real-time access to the room map, low-level access to the robot's internal systems, and real-time telemetry, including the live LiDAR feed, as well as access to all the video cameras covering the space. The instructions were simple:

The results blew me away. I watched the feed as the agent explored the robot's status and capabilities in real time. I watched as the AI pulled video frames from the camera system to ensure there was enough space to make maneuvers that would be safe to execute in tight spaces. I watched it dynamically update the robot code, adding new error-recovery strategies, fixing bugs, and improving performance.

Intelligence at Every Level

This journey started when we founded Lab Sync almost 3 years ago. The writing was already on the wall. The traditional tools and modalities of lab automation would not meet the coming needs. The entire lab automation stack needed to be reinvented. We needed to rebuild it with what we call Intelligence at Every Level. This story is an example of this playing out.

At the lowest level, intelligence working at the driver level to rewrite the code necessary to continue moving forward without bringing down the entire lab for an update. This is critical functionality for a self-driving lab, and I don't just mean automated closed-loop experimentation. If your lab is truly self-driving in the sense that it is dynamically building and running new protocols (not just varying input parameters), then that AI scientist needs an AI automation engineer along in the passenger seat to retrofit the car in real time. Otherwise, you are going to get stuck very quickly.

The Self-Healing Lab

I've been thinking about this as the self-healing lab. It is more than that, of course; it is the ability to evolve the lab's capabilities in real time, but I really like the self-healing concept. Everyone who has been involved in automation knows the complexity inherent in every system, and generally you can't make fundamental changes to how a system runs without surfacing new bugs or missing capabilities, no matter how long the system has been running. Running new assays will invariably require updates, tweaks, and bug fixes. Imagine if that happened automatically as issues are surfaced; they are solved, without the multi-week hassle of getting support from 3rd party vendors.

What This New Paradigm Needs

So what do we need for this new paradigm? Like I mentioned above, this takes a reinvention of every level of the lab automation stack. The previous encapsulations and abstractions that were helpful for humans are now major limiting factors. We need:

1. Intelligence at Every Level

   From sensors and instruments all the way to orchestration, and we need to be able to surface context, intent, capability, and control to agentic systems.

2. Fusion of the Real and Digital Domains

   The aggregation of events, context, structure, and state, both digital and physical, presumed and actual, in order to turn data into actionable insights with executive control and response.

3. Control and Diagnostic Wrappers

   For closed legacy 3rd party systems that can't be easily replaced with newer systems.

4. Wisdom, Safe-Use Policies, and Guardrails

   We are approaching dangerous territory here. That is a huge topic, and a whole blog post in and of itself would just scratch the surface.

On Standards, and on Access

A lot of people have been asking me how this relates to Anthropic's recently announced HMS (Hardware Model Standard). I don't have access to the preview yet, and while I'm excited to see what they've put together, I think they are solving yesterday's problem, and it very much follows what we've already built in our device layer.

I talked about this last year at an LRIG meeting. The need for a standard like this presumes a translation problem that LLMs have already helped solve. Access is all you need. I don't care if it is a low-level serial protocol or REST API, as long as I have access (to the instrument, the API, and other spec docs), I can control it and surface capabilities; no standard needed. Let's focus on opening up access! It is easier to convince an instrument manufacturer to provide access than to convince them to rewrite their control layer to follow yet another standard. And we can tackle opening up access as a community.

The real challenge that we are solving here is device control in concert with the state of the real world. This is the true challenge, not simply how to control a device on the happy path within a workcell. That has been solved. To give AI systems actionable decision-making capability, we need to know more than the device's state and capabilities. We need to know what has really happened to the sample, where it truly is in physical space, what it is composed of, what the environmental and containment conditions are, and so on, before we can determine what is safe to do and make an intelligent decision on how to automatically recover from an error. This is a bigger challenge than hardware control, and it is one of the many challenges Lab Sync is tackling. Come on, Anthropic, keep up! ☺