Why Good Automation Needs a Great Protocol
The process of automating science
Quick note: If you’re going to Boston for SLAS2024 come visit Briefly Bio at booth 780 and talk to us about the role protocols play in automation.
Automating scientific workflows can sometimes feel like pushing a boulder up a hill. Just when you think you’ve got a handle on the workflow – that you’ve got all the parameters dialled in, another requirement appears out of nowhere, and the boulder rolls back down. As the iterations stack up, timelines extend, and patience from all sides starts to wear thin...
In science, many things feel out of our control. That makes it even more important to have a firm handle on the things we can control. So, let’s break down the process by which a lot of automation happens. If we understand that and the sources of the inefficiencies, we can try to figure out ways to improve it.
The process
There are at least two people involved in the work. The person who developed the scientific process and the person who’s tasked with automating it. Below is a typical way it can happen:
Sharing the workflow: A developing scientist sends our automation engineer a link to a document describing the workflow.
These documents come in various shapes and sizes – wordy paragraphs, bullet lists, flow charts… whichever format has been most useful for the developing scientist.Reviewing it: The engineer reads it through, focusing particularly on the protocol, jotting down obvious questions: What is missing? What is unclear? Wtf is p4480?
Shadowing the scientist: The engineer might then shadow the scientist in the lab, focusing on understanding the protocol end-to-end, while disentangling any further ambiguities.
Planning the big changes: With the workflow mapped, the engineer can start piecing things together and asking bigger questions. Will an automated solution require changes that affect the science?
A typical example could be changing from a centrifugation-based kit to using magnetic beads that can be manipulated on a liquid handler.Developing and iterating: With a grasp on the process, they’ll start actually developing the automation.
As they do, more granular, automation-specific questions surface. How should the buffers be stored during a run? How long can this plate be left on the deck?
This process is iterative, digging through how everything works and getting to grips with all the scientific constraints.
It’s all in the interface
Our main problem with this process is assumed knowledge. Automation engineers work with scientists with a diversity of backgrounds. One day it’s a molecular biologist, the next it’s a cell biologist. This means that everyone has different levels of understanding in their head that the other is not aware of, and all that information will be necessary to develop successful automation.
For example most cell biologists know that spinning down mammalian cells should be done gently. In their protocol, they might simply write “Spin down the culture”. An automation engineer (don’t look at me!), having only worked with bacteria in the past, may assume that the same speed can be used for all types of cells.
By the same token, details that can be critical in getting a process automated won’t be obvious to the scientist. A scientist might assume that the centrifuge on the automated workcell spins just as fast as their manual benchtop one, when in fact, the automated ‘fuge is really only fit to clear samples of bubbles, and has no hope of pelleting cell debris.
Getting on the same page
When handing over a workflow then, we need to unfold as many of these hidden assumptions as we can. Unfortunately, both sides don’t know what they don’t know, and explaining every single detail risks us getting lost in the weeds.
If there's time, shadowing in the lab is a great way of building up a solid understanding and a chance to ask practical questions. It doesn’t stop there, so below are some other things that I found helpful and that we now added to Briefly.
Standardising protocols
A consistent format makes it easier for both sides to get a grasp of what exactly is happening in the lab. It makes it clear the types of information that should be shared, and takes the mental load off figuring out where that information will be.
Getting everyone to write things up the same way requires time and effort, which can be a tough sell, especially to a scientist who has more experiments to run.
To tackle this, we developed a clean, consistent format, and use LLMs to take care of translating unstructured text into this format.
Collaborate on a shared artefact
Rather than having countless meetings and swapping documents back and forth, it’s more efficient to align over the same document, adding questions, comments, and execution notes that both the scientist and engineer can review and agree upon up front.
All protocols in Briefly can be shared directly with a colleague, and you can collaborate with them directly in real time.
Ask a third party to check for gaps and ambiguities
Some TechBio companies employ folks who bridge the gap between disciplines, like wet lab and dry lab, or bio and automation.
What about using our friend AI as a helper that sits between the scientist and engineer? Have it point out gaps, or spot potential pitfalls. Think of it like a generalist that knows enough to check our work.
Here’s a few examples using the AI copilot in our Experiment Builder.
Ask it to look for missing parameters, leaving the values blank for the scientist to fill out.
Ask it to look for potential mistakes that crept into the protocol and to add these as notes to review. I overdid my heat shock slightly? Oops, hehe.
Ask it to add notes that may be helpful to an automation engineer. It spots some important liquid handling constraints when washing cells.
These suggestions are made in the shared protocol itself. Both sides can act on any suggestions that are useful, and discard those that aren’t.
These are some things we have come up with so far to help the transition to automation. I really believe the work we do on the protocol early on sets us up for success in getting any automation over the line. If you have any general tips or perhaps ideas on how Briefly can do more for automators, I’d love to chat!