More Thoughts on AI in Lab Automation

I have a lot of thoughts about how AI can be used in lab automation. I thought this was an opportune time since SLAS just passed and the Ginkgo cloud lab demo has a lot of people thinking about automation.

Since I have always taken a very programmatic approach to lab automation, it has been pretty seamless for me to start using AI in my work. This has given me a lot of experience that I hope will be useful for others who haven’t used it as much, or who have, but just not specifically for programming lab instruments.

One development is that it is now very easy to create almost any type of higher-level application that you can imagine. Any orchestration tool, scheduler, script creation tool, or LIMS system that is primarily a UI interacting with databases can be built by someone with no coding experience in a relatively short amount of time. It will always be extremely worthwhile and necessary to understand the mechanics of the systems one is deploying, but the barrier to entry for building a functional prototype is basically zero. I’d encourage anyone in the field to start trying this out themselves.

Another development is that it is now very easy to translate intent into physical real-world actions. You can prompt an agent to “create a set of reaction mixtures of xyz reagents with this range of concentrations across these plates” and with the right interface and context that can happen without writing a line of code. The interface and context that allows this to happen usefully and predictably is going to take a lot of design work, but we can broadly say that an interface that provides a high degree of scripting flexibility and atomic control and a context that describes the state of the system as precisely as possible will be key. I don’t think the main utility of translating intent to action in this way will be in wholesale generation of production-ready protocols, but in letting engineers iteratively refine details at a high velocity, as I describe further down.

I think it is very much worth considering how we can build systems and practices that allow us to make the best of these new developments without them backfiring or just pushing us in a suboptimal direction. There are a few specific areas that I expect will provide a lot of value.

Fine-grained simulation and testing tools will be increasingly useful - anything that can help us predict what will happen when we run code before we actually run it live will be very helpful for increasing development speed. The existing simulation tools we have are okay, but they don’t fully capture all of the information we already have about what a robot is doing. The biggest blind spot right now is so obvious that no one even thinks about it: none of the existing simulation tools show you exactly where the pipette tip goes. Across the entire industry of liquid-handling robots with proprietary simulators, literally none of them have that feature to my knowledge (although FluentControl is close). We can catch so many more errors if we just had that specific information. An error that is caught in simulation can save hours of time or hundreds of dollars in reagents, and we can catch far more of these than we do now with better tools.

A more modular approach to physical testing can massively speed up development while giving us greater certainty when deploying complex processes. Being able to carefully optimize failure-prone steps like off-deck gripper movements or pipetting difficult reagents in isolation, and then composing these steps into larger pipelines, is a much more efficient testing process than “running a dry run” and then “running a water run”. This is where being able to easily translate intent into physical action has a huge pay-off. If a difficult liquid-handling step takes 20 iterations to optimize, the difference in time it takes to modify and run each iteration has an enormously compounding impact on development speed. Multiply that across a complicated production pipeline and you can save weeks by making each individual test faster.

Above all, better digital integration and accessibility is the single biggest and most achievable unlock needed to leverage AI in lab automation. Standardized and machine readable file types will allow us to better model our systems in software, which directly assists in the creation of simulation and testing infrastructure. It will also help a lot with scalability and reproducibility if all of the data encoding the configuration of a system is interpretable by software. We don’t have to reinvent the wheel or all agree on one standard, but proprietary byte-encoded formats are used for a lot of files that would be far better off encoded in JSON. For example, Hamilton’s deck layout files implicitly describe the spatial positioning and geometry of all of the objects on the robot deck during a protocol with a very high resolution, yet this data is not natively accessible by any other program besides Hamilton’s own proprietary software. Converting these formats to something like JSON would not exactly be trivial, but is still ultimately just a matter of representing information that we already have about the system in a better way.

The capabilities of software are a lot higher now than even a year ago, and creating an environment that will allow us to maximally leverage these new capabilities should help us move faster while also increasing the amount of rigor and care we take in deploying processes.