All right. I am Will Serber. Um, and it
is my uh my great pleasure to be
introducing uh this section and giving
you a little bit of background uh before
turning it over to friends from OpenAI
and uh Pacific Northwest National Labs.
Um I uh you know the title of the talk
here designing, deploying and scaling
autonomous labs with OpenAI and PNL. Um
I'm the head of automation at GKO uh and
uh have been there for a handful of
years. Um there's a disclaimer of course
this is required. Um I've been uh I've
been in GKO for about three years going
backwards on this. Before that I was
head of automation at Zyrgen. Before
that I was a commercial photographer for
5 years. Uh not very helpful for my
current career. Before that I was an
astrophysicist for a while. Again not
the most helpful. Um but uh it's been
fun combining all these things as much
as I can into into one interesting
career. I've got a dog in the bottom
right hand corner named Soba. And uh
that's her looking very bored in our
workshop where we make racks.
So the mission of the company is to make
biology easier to engineer. And we've
got about 400 or so employees, a little
north of that. And we're expecting about
200 million in revenue this year just to
tell you a tiny bit about GKO. And we're
really focusing more and more on
automation.
So the talk is organized really uh there
are three fundamental segments to it.
Um, one just a uh description of our
belief that autonomous labs will
transform biotechnology.
Second, I'm going to tell you a little
bit about what we think those labs might
look like. And then third, just a super
quick word on kind of how we go to
market with that in practice.
Starting with the first. So, this is an
image uh you might have seen Jason uh
our CEO show off, but I do quite like
it. So this is an old ad for IBM in
which they were saying, you know, one of
their computers will place 150 engineers
with slide rules. So there's a couple
reasons I really like this. Uh one is um
you know, very clearly this is uh you
know, someone might look at this and
think like, oh my god, our jobs as
engineers are at risk as a result of
this technology. But we all know that
there's way way way more software
engineers today in the world uh than
there were back then. So that's the way
I feel about um automation in the lab
space too. And so it's nice to see this
uh fantastic example. The other thing
that's kind of interesting uh sort of
represented on this slide is that it's
these two things are not really
equivalent. The slide rule is extremely
flexible but not automated. You need a
human to run it. Uh it feels similar to
a pipet in that sense. And then in the
top lefthand corner you have the things
that IBM was selling which at the time
were not particularly general purpose
computers uh but they were heavily
automated and it was really the advent
of something in the top right hand
corner the you know the personal
computer that transformed the world and
is why we have billions of computers uh
in in the world today. Um so that high
automation, high flexibility is kind of
the the golden spot to be um where you
can really have a transformative effect
on the industry.
Continuing this analogy a little bit to
transportation. Um you can imagine uh
trains or subways being in the top
lefthand corner again uh where totally
automated but you have to go where the
rails are laid or a car in the bottom
right hand corner. And this is the way
the world has been for a long time. Like
you basically had these two choices. And
we're starting to see the emergence of
something in the top right hand corner.
Whimo being the best example where
within their constrained environment it
is both autonomous and flexible. And it
will be interesting to see how this
changes the world and the way that
cities are laid out and people lead
their lives. I suspect this will be a
you know quite a transformation as well
which is also why so much money pours
into that space.
In the lab space, we again have things
in these two corners. We have the lab
bench, extremely flexible, but not a lot
of automation, no automation. And then
you have the traditional work cells in
the top lefthand corner uh filling this
out. And to date, there's basically been
nothing in the top right hand corner.
And so really what GKO is going after is
that top right hand corner. We don't
view ourselves, even though we have lab
equipment. That's what we're selling. We
don't view ourselves as competing
fundamentally with the work cell per se.
It's competing as much with the bench as
the work cell. You know, we are uh very
much looking to transform the way that
people do science in the way that the
computer did or the way that perhaps
autonomous driving will.
So, this raises this question of okay,
how do you get there? How do you
actually build that?
Part two.
So, one of our key beliefs is that an
autonomous lab must allow for the same
work you do in a traditional lab. So,
you need to be able to do all those same
things. You can't be leaving out key
parts of the workflow.
There are, this is the wordiest slide. I
apologize for this one, but there are
basically six things that we think are
critical to replicate uh to get to that
top right hand corner. So, we think you
need reliable liquid handling that is
easily programmable. We called this one
out just because liquid handling is so
much at the core of so many different
workflows and so it feels like it worth
special mention. Number two, you need
reliable material transport to any
device. The reliable part is the hard
part there. Like lots of people have
robot arms, but they're not really
reliable enough to get to where we want.
Uh number three is parameterized control
of devices. You need, you know, a good
API. you need to be able to do many
things with the device and get kind of
full control over it. Uh fourth is you
need support for as many devices in a
single setup as you would have in a
traditional lab. And so we think, you
know, you don't want to have lots of
different work cells with humans walking
between them. Ideally, you don't want to
be missing pieces of equipment that are
on the bench in the idealized form of
this. Fortunately, there's, you know,
there's value to be, uh, to be gotten
along the path to this vision, but this
is the this is the ultimate vision. Um,
fifth, uh, support for parallel work.
So, if you imagine a traditional lab
with a bunch of grad students or RAS
running around in it, like they are
coordinating constantly to share
equipment and to make the use the best
use out of the the capital expenditure.
And so we believe that really to uh
achieve what we want to achieve in the
lab, you need to support tens to
hundreds of parallel protocol requests
from scientists and critically ones that
change daily. It's not the same, you
know, 10 protocols they're going to be
running over and over again. They're
going to want to push the frontiers of
what is possible and to be running
different uh protocols. And then lastly,
uh it should say an experience as easy
for scientists to use as the bench. So,
we think we really, really need to lower
the barrier to entry to using these
tools.
I'm going to tell you just a little bit
about our solution. If you're excited to
see more, you should come to our booth.
It's the big pink one uh in kind of the
middle of the the floor. Uh very
Valentine's Day themed. So, we've made
modular hardware and we've kind of
wrapped each instrument in hardware to
make it more reliable and more robust so
that it really behaves as well as
possible. and we put all the accessories
needed into this modular sort of Lego
building block. Um,
you can put multiple uh racks, we call
them reconfigurable automation carts
together and they plug together kind of
like Lego and they just work. And so
again, it's like this focus on
reliability and robustness.
You can start very small as in the top
lefthand corner with just a few racks.
So it's a small investment, begin
automating at that scale and then expand
over time in a kind of nice linear way
to add capacity or capability. Uh and
you can get to a very large system. I
don't want to steal too much of Todd's
thunder, but you know that system on the
the right is a 97 rack system purchased
by uh the Department of Energy by PNL.
Um and so this this technology really
scales from small to large.
And then the other part that we've
really invested a lot in is our
software. And there's a ton to be said
about this. Um, you know, we've tried to
make it super easy to use. Uh, by which
I mean writing protocols, launching
protocols, monitoring them, getting the
data off. But the one thing I wanted to
emphasize in this talk in this small
intro is just the interle of protocols.
And so we've uh, you know, we've got
distributed plate transport and then we
put a lot of time into our constraint
solver that is actually scheduling the
work. And so the cool thing here is the
different colors of the bars up there.
It's basically a little gant. The
different colors are different protocols
running on the same system at the same
time. So run by different people,
totally different workflows requiring
different instrumentation. And it
figures out how to schedule it and to
get the maximum utilization out of your
instruments.
So here is just a clear example where
that gant you can see there's a whole
bunch of colored blocks all in the same
vertical line which means multiple
things are moving simultaneously on the
system. So you've got multiple robots
transferring plates at the same time.
You can also uh have one rack in error
and the rest of the system keeps
running. So you get very high
availability. If there's a second
identical rack, it'll fail over
automatically.
And then this is the just the dark mode
version of that same uh sort of gant.
I'm sorry it's so dark here, but uh I
love this because this is a screenshot
of theuler in our system in Boston from
just a few days ago. And this is it it
running 35 simultaneous protocols from
different users. You know, there are
vendors out there that can run one or
two things at a time, but nobody is
approaching this level of concurrency.
And I really think that allows you to
make a core lab, an autonomous lab, uh
that is much more effective and
efficient than you can make with any
other technology.
Um this is our lab just down the street.
Uh if you want a tour of this, you can
come to our booth uh and we'll give you
a Uber coupon to just drive over there
and you can get a you can go there and
come back in about half an hour and get
a quick tour of our facility and then be
back at SLA in no time. Uh so again,
we'll pay for the Uber. Uh also on
Thursday, uh we're going to be doing
tours all day, so you can just show up
at any time. 25 Dry Dock Avenue is the
address. So please come on by. It's one
thing to go see our booth. It's another
thing to see the actual racks in the lab
doing real science.
So this is the fastest part, I promise.
We are commercializing this in two ways.
One is we are happy to build out
autonomous labs, you know, in your lab.
Um, and that looks like a traditional
automation sale or you can take
advantage of the same technology via our
CRO services. So, we will run protocols
for you if you want. Uh, there is a QR
code for my LinkedIn if you want to make
a connection. Uh, happy to connect with
more folks who are interested in this.
Um, again, our booth 823. Stop on by.
Um, that is uh my last slide and I will
leave it up for just another second as I
see people scanning the QR code and I
will now move on and then you'll have to
find me afterwards. Sorry. Um, so uh it
is my pleasure to pass things over to
Joy from OpenAI who's going to tell you
a little bit about uh some of the closed
loop science we've been doing together
on top of the platform I just described.
Joy,
>> you can use that or you can just use
arrows.
Okay.
>> All right. Um, so I'm really excited to
tell you more about um, this project
that we did with GKO over the last
sixish months where we basically gave
GPD5 um, control over GKO's rack system
and we were able to make more protein
um, in this case SFGF at a lower cost
than the previous human state-of-the-art
result.
Um, okay. So just a little bit of
background. I think this was not quite
as obvious six months ago as it is now.
But I generally think of AI in science
kind of as this um different stages of
capability. So initially we think of AI
as tools. Um and this is you know
commonly things like alpha fold bolts
like general um biology foundation
models and open also had our own paper
out a few months ago about GBT4B which
is actually just a very tiny model that
we fine-tuned to generate uh Yamanaka
factors um variance and this actually
showed that there was like a 50x
reprogramming efficiency. So this is
like a interesting project kind of in
the AI as tools regime. Um and then we
see kind of AI evolving as tool users.
So we start giving our models access to
internet, access to computers and we
generally see a huge capability jump in
this regime. Um and then the thing that
I really want to talk about um here is
kind of AI as co-scientists working
alongside humans. Um and then also in
some cases like in this project
designing experiments independently and
at the start of this project GPD5 had
actually just finished training at
OpenAI and we knew that it was very
knowledgeable. We knew that it was very
good at programming and math and physics
um but we haven't really tested it in
biology and part of this is because you
know biology requires wet lab to really
validate. So I think computational
validation of comput computational
results is not quite as interesting. And
so with GKO we had this opportunity to
really have the model design real
biology wildlife experiments and we can
actually run them in the rack system and
really kind of evaluate GPD5's
capability at doing real biology. Um so
the experiment that we settled on is
self-free protein synthesis. So I have a
few studies kind of talking about why
this is important. Apologies to those in
the audience who know way more about
this than I do. Um, but generally, you
know, protein production is pretty
foundational to pretty much everything
including medicine and research. But
generally, traditional methods are very
slow and complicated. So, you have to
introduce DNA encoding a new protein
into cells. Often you have to create a
stable cell line, scale production of
bioreactors, and this often takes on the
order of weeks to months. So, the
limitations here is that it's often slow
and inflexible. There's limited protein
types that you can make. So for example,
if you have a protein that's toxic to
bacteria, you can't really grow it in
bacteria. Um there's potential safety
risk involved is not quite portable
because you require zero facilities and
large bioreactors.
So cellfree protein synthesis kind of
turns this regime um inside out in some
ways where now instead of making
proteins in living cells, you actually
lice the cells. So all the protein
making machinery inside the cells is now
kind of free floating in this tube and
you can actually just spike in your DNA
construct encoding a protein of interest
and make it this way. Um and so this is
really good for kind of prototyping
large libraries of different protein
variants and just general high
throughput workflows. And so what this
can give us is you know faster dis uh
drug discovery personalized therapeutics
and we can get significant speedups
because now instead of having to make
these cell lines you can get proteins on
the order of hours or days. Um high
throughput you can make many things in
parallel. It's a lot more flexible and
safe because now you don't have this
kind of like um contamination concerns.
And the really nice thing here too is
that the setup itself is not super
complicated from a protocol perspective
because it's kind of at least from um
the models view, right? Like you add a
bunch of different volumes of reactants
into a tube and then that tube just
incubates. And so this is a good problem
for our models because it doesn't
require that much understanding of the
physicality of the experiment. It's
really just kind of thinking about
optimizing the volumes of reactants that
you're putting into the tube. So there's
um a nice kind of constraint on the
action space but there's still a lot of
NOS for the model to tune and explore.
Okay. So this is kind of the general
setup. Um on top we have GT5 that is
kind of doing the data analysis,
reasoning, generating hypothesis. It's
actually writing code to define the next
set of experiments. Um and I'll kind of
like walk through what the exper looks
like a few few slides out. Um but
essentially this is a pyantic object
that is like serialized into a JSON file
that we're sharing between the two labs
and then from the GKO side the physical
experiment is actually executed. So we
have the automated liquid handling, the
incubation, the fluoresence
measurements, um the standardization,
all of these things are happening there.
And then the metrics and the data and
any kind of metadata about things that
may have happened during the experiment
like for example there there's equipment
that eroded out on specific wells. All
of that data is then sent back to GPD5
and then we just kind of run this loop
over and over again. So over the last
six months we ran around 36,000
different reactions across 580 uh 34
well plates.
So um alongside the experiment designs
we also asked GPT5 to kind of write lab
notebooks and to document its kind of
biological reasoning throughout this
process. And part of this was because I
wanted to monitor the model to make sure
that it was actually doing something
sensible because one boring case you can
imagine is that the model just kind of
does a dumb grid search and submits that
as a play design that's not very
interesting. Um so this was actually an
excerpt from the first random lab
notebook that I opened. The part that is
bold um the NMP supplementation was in
situation.
This suggestion was actually the subject
of a recent paper that was told around
the time of our collaboration a mechan
lab and they had achieved a huge
reduction in the amount of cost per gram
of protein that they were able to get
from a self-free system. And so the
really interesting thing here is um this
bold line is actually one of the
critical insights that they had in this
paper but GD5 was not trained on this
paper because this paper had just come
out and also in the setting GPD5 didn't
have access to internet and so this is
actually just from knowledge that was
stored in the model weights and so this
was actually the initial sign of life to
me that the model had enough biology
knowledge in its model weights to
actually successfully do this
experiment.
Um something early on that we also had
to figure out too was um on almost every
roll out G5 was complaining about batch
effects and kind of just general
variability between replicates. So as we
all know biology is very noisy and so
for each experimental condition we were
testing we were doing them in
quadruplicates. So there were four wells
kind of in random positions on a 384
while play and G5D5 was just always
complaining about you know the same
experimental condition from playful play
is like not really um consistent and
then it's not consistent kind of within
plates and so there was actually a huge
amount of work from the GKO team to
reduce the coefficient of variation to
something that was much more usable and
then as said they were testing around
10,000 conditions per week.
Okay, so these were these are the
results um that we got out of the model.
The overall objective is to reduce the
cost per gram of protein that we're
making in this system. And we chose this
objective because I think just going for
tighter itself um is not that
interesting because you can imagine kind
of throwing all the most expensive
ingredients into a tube and that's not
really a scalable system. Um so here we
have the first round of experiments that
GBT designed. The horizontal axis is
amount of tighter that we were getting
out of these reactions in 3D 4 plates.
Um that's a grams per liter of protein
as measured by fluoresence. And on the
vertical axis we have the reaction cost
of each one of these reactions. And the
star here um is the soda 384 uh result
that came out of the dual lab. So this
is actually a really tiny um paper for
us because then we kind of had the uh
human gold standard to benchmark
against. And then in this setting GBD5
was just reasoning. It was given a
prompt about what self-free protein
synthesis roughly is. It was given the
pyantic model spec and we just told it
to write code to design 78 different
experiments for this like 384 while play
and we didn't really give it any inter
information and it didn't have access to
papers it didn't have access to internet
it were just kind of thinking in a
closed box and so these were the first
designs that I came up with. Um, I
remember at this point we were kind of
happy that it made protein at all
because I know that if you kind of gave
me, you know, put me in a closed room
and told me to write a reaction, I don't
think I would have gotten results this
good. Um, but that being said, you know,
kind of looking at the plot on the right
where we have um the minimum dollar
program that we can get. We're still, I
think, around um 14 x uh away from the
soda. So, there was still quite a bit of
room to go. Um, also on this stuff, we
noticed that the model was kind of
suggesting new reagents that we should
add. And so we actually had the model
rank all the reagents that it suggested
we should add to the pyentic reagent
list. Um, and then we ranked them and I
think we took around the first 25ish of
those reaction or sorry those reagents
and for the next step um, we gave it to
the model. So in general we basically
want to like move in the direction of
this blue arrow. We want to see this
kind of parto frontier move to the right
and downwards meaning that we're getting
more protein but also the reactions are
getting cheaper. So this is the next
step. Uh we see a decent amount of
improvement but it's not huge. We're
still many orders of magnitude away from
soda. And the difference here is um on
step two the model so as we were
designing these experiments the model
was able to use a new reagents. And so
we see that step three we get quite a
bit better but we are kind of hitting so
as you go to the left um we see that the
model is like kind of not able to go
down further in terms of like the cost
and we also want to move a little bit
further too in terms of tighter. And so
at this point we thought okay we know
that the model is able to make these
incremental improvements um just kind of
based on knowledge in this model weights
but this is not how a human scientist
will work. We would be able to read all
the previous literature. We will be able
to search the internet. We have access
to a computer to kind of like do
different kinds of data analysis. So we
thought let's just throw all these tools
at the model instead of kind of doing
this like artificial evaluation of like
how much internal knowledge a model has.
And so for the next step um this is with
full use and we see this huge jump. So
we actually immediately exceed the 384
wall soda um state-of-the-art. And so
now we actually kind of have to like
zoom in in this region. So for the next
part we're kind of switching from lo
scale now to linear scale to make things
a little bit easier to see. So the tools
here the model has access to a computer
and a browser. And we see kind of from
steps three to four the model gets
better. And then step five the model
gets even better. And so we can also
kind of see the progress um on the right
as well where we're kind of just like
getting much better with with each step.
Um so overall when we retested these
reactions in two ML tubes where now we
kind of have more oxygenation due to the
better geometry of two mel tubes uh we
see a 40% reduction in the total
reaction cost and then when you look at
the reagents alone it's actually 57%.
So it was a pretty um decent uh
achievement I think for the model where
from the beginning we weren't sure if we
could design even a single reaction. Um
the other interesting thing here too is
that because we were optimizing at this
384 well plate level um not sure how
easy these numbers are to see but you
can kind of see like the um RF opt which
is the result that came out of the dual
lab with the human gold standard um it's
actually much lower and tighter at the
384 well level than most of our
reactions and I think this is just
because the model is designing
experiments for this kind of like low
oxygenation condition in the 384 well
geometry.
Um, and here I'm just kind of like
showing you some concrete examples of
like what the code the model actually
saw looks like. I believe this is
actually open source. So you could also
browse this online on GitHub if you want
to. Um, but yeah, we basically just
constrained action space of the model so
it can focus on kind of the biochemistry
and not what's physically executable on
the racks. So it was just sending these
uh plate objects kind of back and forth
between GKO and OpenAI. And the play has
a list of sample objects. that has kind
of the results of the experiment. Um and
also you see there are things like
reagent flags of what um if like a
reagent is out of stock. Um also
metadata on you know different events
that might have occurred during the
execution of an experiment. Um and then
we also have validation for all the
different parts of the plates. And this
just you know make sure that for example
like a plate has the right number of
samples. It has a sufficient number of
replicates. And what this um gives us is
that oops uh we know that if a plate
passes all these validations then this
experiment is executable on the rack
system. So this gives us a really nice
way to kind of programmatically check
all the rollouts and the outputs are
coming from the model without you know
trying to run it on the rack and then
only later to realize that it was
broken.
Um let's see I have a few more of these
where yeah we're validating that the
reagents are available. We're validating
that a model can only add things in 25
nanol increments because this is a
limitation the physical limitation of
the rack system. um non-zero default
values is is interesting because I think
we added this after we noticed um there
was one plate where the model cheated
where it was trying to cram a lot of
reagents into a single reaction and it
was kind of running out of volume and so
what it did was that it um indicated a
negative volume from the reagents and
this way it was able to kind of add more
things in and so we made it stop doing
that by kind of adding this extra
pyantic check. So um we also had to do
some kind of ranking on the designs that
we're sending to GKO and this is because
not all plates that the model design
path of identical validation. So we were
generating kind of 2x the number of
target plates. So if we're targeting 128
would generate 256 plates and then this
will give us kind of a surplus of plates
and we had to rank them somehow instead
of um randomly sending them to go. So we
tried a different her uh heristics for
ranking. I don't think um any of them
was really super correlated to the
outcome, but I'll just kind of talk
about what we did. Anyway, um the first
one we did was kind of like this like
vibrating regime where we had GPD5 then
act as a PI and we told it here's an
experimental design from a postto in
your lab. Um the experimental design was
just the play object and the lab
notebook and you can kind of like grade
it on how good it is kind of going from
like a scale of like blind unguided
search to like a very good sound
scientifically rigorous experiment. Um
so that was a one way of ranking. The
other one was um this idea of kind of
like checking your work instead of the
final result because we don't know what
the final result is. So we kind of
looked at all the different actions the
model was taking on the computer as it
was designing the plate and then we had
a separate model come in look at its
work and say okay did it do kind of the
right things that make sense. So some of
these are pretty obvious. Did you add
like at least look at the raw files from
the experiments? Um did you look at the
reagent loss to think about batch
effects in the reagents? Um there's also
a time point field and experimental
results metadata. Did you look at that
that field? And this really guards
against kind of um designs from the
model where it's actually just like a
grid search and it's like not very not
thinking really hard. So this kind of
filters for the smart designs. Um and I
think the fact that this is not
correlated that well with the final
titers is just maybe sometimes in
science you do all the right things but
you don't get the wild results that you
hope for. Um and then finally 5 wrote
some interesting uh lab notebook
entries. I think these slides will be
online so maybe people can read them a
little bit later but it does like
consider a lot of biochemistry of these
reactions. Um I don't understand most of
these. They kind of like vaguely make
sense to me. So it thinks about core
ions and buffers um energy modules that
rivals glucose and MPS um different
co-actors that it was adding in. I think
we had some interesting high title
results with both spermadine addition
also catalace. So the model had this
theory that okay the catal is like good
for gen um consuming radical free
radicals but then also generating
additional oxygen at the liquid air
interface. unclear if that's a real
mechanism, but we did have a very good
um experimental condition come out of
this one. So yeah, um overall what we
learned was that I think by using the
pyic model to constrain the action space
of GPD5, it actually made very few
mistakes. So from the 36,000 different
experiments we did, it there were only
two bad plays. There was a negative
volume one that I talked about. Um, and
one that was kind of silly was a simple
math error where it was kind of
converting nanol liters to microl liters
incorrectly and so it basically
accidentally set all the other reagents
to zero and so we had a play that was
just like a sugar gradient. Um, and then
human oversight was still required for
kind of improving the protocols and
handling the reagents on off the rack
system. So we saw that system can design
and interpret experiments but we see
that lab work still requires kind of
these practical details and we do need
experienced operators and kind of
looking to the future we're really
excited to apply AI and more of these
lab in the loop optimization workflows.
Um and we really see kind of autonomous
labs as being complimentary to AI models
where the models can design the
experiments. Um but ultimately biology
really still requires testing iteration
kind of validation in the physical
world.
So yeah, that is all from me. Um, I
guess next up is Todd or are we taking
questions?
>> Oh, no, no, that's great. So I think uh
Todd will speak and then we'll do
questions at the end.
>> Okay.
Okay.
>> All right. Hello. I'm Todd Edwards.
Here we are. Uh, so I am with Emil,
which is the Environmental Molecular
Sciences Laboratory over at the Pacific
Northwest National Lab. Uh what I'm
going to talk to you about today is what
we are and kind of what we're trying to
achieve and the steps we're taking along
the way to get there. So EMS is a user
facility which is a a type of lab within
the department of energy office of
science where we don't do our own
research but we have scientists and
equipment and we partner with folks
around the country to take their samples
do whatever kind of analysis they need.
Then they get the data for a year and
then the data becomes public. So we're
able to build a large public repository
of interesting data that um hopefully is
all done consistently so that it can
contribute to larger projects. Uh you
can see we have functional systems
biology. This is traditional studying
microbes in culture. we have
environmental transformation and
interactions and this is looking at the
interactions between microbes and soil
or atmosphere plant roots. Uh so looking
at it in the context and that's for
building earth system models and we have
a computing group that helps build
models and use models in our research.
And so there's a a QR code here so you
can check us out, find out how you could
collaborate with us. Uh and then science
central is up at the top. That's where
you can get access to the data.
Now, because we have been very
traditionally working individually with
PIs, very small scale specific
experiments, but we have a vision where
we want to automate in order to improve
the rate at which we can generate data
and improve the consistency that we're
generating data. And but we're not doing
production, right? We're not doing the
traditional high throughput doing the
same few uh processes over and over. We
have to really tailor every time we work
with a new collaborator. Tailor the
experiments to what they need. Uh but we
still want to generate that high quality
consistent data. So we need modularity
in our platforms both in the hardware
and the software side. And then you know
as as things have grown autonomous
experimentation has cropped up and
proven to be a very efficient way to
build out the data that we need to make
the models or improve models over time.
Uh and again we have access to limbs
high performance computing data storage
so that we can generate the data analyze
it and make it open.
uh the challenge that we're specifically
trying to attack here at Emil is the the
notion of the genomes is is not enough
like if you understand the sequence of a
microbe that doesn't really tell you
enough to be able to predict how it's
going to behave. you need to study the
the phenotypes and so you need to study
the microbes under different conditions
and um in order to build models so that
you can predict this microbe this
genetic sequence under these conditions
how will it behave and that's relevant
for industry um this sin 3.0 know this
is an example we like to share. Uh
someone has created a microbe with a
minimal amount of genes and but still be
viable to grow and 30% of those genes
they don't know what they do. So it's a
very large problem and as in terms of
understanding what possible proteins
might be expressed and what proteins are
actually expressed and how they interact
and uh you know the problem is just
growing that the disparity between the
genomic sequences and the knowledge
about the genome is getting bigger and
bigger because uh more and more microbes
are being discovered and more sequences
are being produced. So our efforts have
been really to to try to catch up with
the ability to generate genomic data. We
want to be able to generate phenomic
data.
Now Emil like I said on the right hand
side is our traditional approach and
this is where we work with an individual
PI. We do a very targeted experiments
for them. Uh it's you know lower
throughput but it's really getting them
what they need. But because we're
generating it we're able to pull all the
data so it can be used for other folks.
What we want to do is do that on a much
larger scale uh with this automation
centric approach but we we don't want to
go directly from uh this traditional
approach to the the high throughput
you know forcing folks to do a narrow
set of experimental procedures
uh we want to jump from traditional
straight to a large scale R&D
uh let's see uh so this is our dream we
want to produce A we wanted we wanted to
commission a device that would be able
to do a very wide range of possible
experiments
uh at high throughput and with that
consistency and treat it like a
something like a James Webb telescope,
right? We want to make it able to do a
campaign of science, study a particular
thing and then once that campaign is
over and those folks have their data,
shift and pointed at something else and
study a whole new problem. So when we
when we set about this, we couldn't
really plan uh what what throughput we
needed or what experiments we needed. We
figured we focused more on the range of
capabilities that we wanted and kind of
a capacity that we wanted to be able to
do and then we went out and took bids
and came up with a solution which we we
are working with GKO uh to produce and
we call it a capability because M2PC is
both the equipment that's going to go in
the room but it's also this whole new
lab. So, we have a whole new building,
new support labs space, uh, and a big
automation space, plus this this rack
system. And you can see it's it may be
hard to see from the back, but we have
different pods, and each one is focused
on a different type of capability. So,
there's the ability to produce media, so
we can do a wide variety of plates. We
have a a cultivation section, we have
analytical tools, we have massspec, we
have sample prep, and then we have a
BSL2 section. And so this is all in the
design process right now. Still settling
on what we're going to actually get. But
the idea is that instead of now working
with individuals and doing experiments
on say a single massspec, we're going to
work with a campaign. So we'll get a
group of scientists together that are
all focused on the similar problem and
we'll plan out a series of experiments
and then run it on MTPC. And then while
that's running, we're planning the next
campaign. So when they get their data,
we can move on and start the second
campaign and so on and so on.
Uh but this is a you know this is the
goal. This is the dream. It's going to
take a few years. Uh so how do we get
there? So in the meantime, we've been
taking steps along the way to build out
all the infrastructure, all the uh
adjacent things that we need to
accomplish in order to get there. And
I'll walk you through that. Our first
one is automation. Like I said, we have
been a fairly traditional lab, not much
automation. and we wanted to kind of dip
our toes first. So we we did a similar
kind of commissioning process uh to
contract a a system to do what M2PC is
going to do but at a smaller scale and
in an anorobic environment. And so and
we also worked with Genko on this one
and instead of doing racks they built
what are called tiles which are very
similar to a rack but they're enclosed
in these anorobic pods. So we can do all
of the cultivation, the growth
experiments. We can do analysis with
HBLC and some other tools and produce
plates and do those kind of studies on
anorobic microbes while keeping them in
an anorobic conditions the whole way so
we don't have uh impacts of working in
oxygen or trying to get rid of oxygen.
Um, and this is also forcing us to
figure out how do we manage this kind of
level of throughput in the lab that
we're not used to. So, there's a lot of
consumables that have to go in and
reagents and there's a lot of waste
coming out and there's we need kind of a
new group of people to support it. Uh,
and so it's better to do this now
because we're going to need that when we
get to MTPC. We're gonna need even more.
We also have a a computing analytics and
modeling team, CAM. I mentioned them
before. They have a a section called
MIDAS, the modeling integration data
agents for science. And their goal is to
build AI agents that will help all along
the way. And this is this is kind of a
one typical experiment of how we how we
work. Users might come in and they go to
the JGI to get their sequencing. And
that sequence data can be used to create
models which are um not so useful when
they first come out because they're not
constrained. So they don't predict very
well. But we can do experiments doing
the phenomics to constrain those models
and improve them so they can do better
predictions. The goal eventually being
to build a digital phenome of the of the
microbe so that we can predict the the
outcome the functional parameters of the
microbes. And so we're building tools
now to help build those models, improve
those models with data. And then the
next step is to build models to build
agents to help design the experiments
that would be run on the systems so that
we can eventually get to that closed
loop autonomous experimentation where we
are using AI to efficiently plan
experiments to uh sample that whole
parameter space because the
u the growth conditions we saw in the
last talk there are many different
variables that you can adjust a person
trying to do that is not efficient
whereas AI can do that much more
efficiently. So we can get a model that
works.
Uh the next thing we're working on is to
standardize our workflows. So like I
said we we get all sorts of input. Uh
different people have different
workflows needs but from our standpoint
we need to standardize right? So we're
trying to come up with a way to
represent workflows, automated biology
workflows in a standard way so that we
have a definition of them so that we can
compare data that comes out of these
workflows apples to apples instead of
not being able to compare them. Right?
Because if your experiment is basically
the same as your experiment, but it's
different enough that you can't compare
your results unless you know exactly how
they are different. And as uh anyone has
tried to work with a biologist who has a
you know they ask for a cultivation and
then you have to start probing what are
all the details eventually you can sort
it out but there's a lot of work. So we
are building tools that will help us
onboard these workflows convert them
into our standard format and then you
convert that standard format into
instructions for our automation.
And then the last little bit, this is
where I've been more involved is is
trying to pull it all together. So we've
got the automation, we've got the
workflow, we got the the tools to design
experiments, but we hadn't put it all
together. And uh if you've done
interdisciplinary work, you know, it's
not easy. So we we decided to do a
minimum viable product to show this this
loop uh going all the way around and
then forcing the biologists and the
systems biologists and the automation
people and the coders, the modelers all
to work together and understand really
what the other teams need uh and sort
out those interfaces and we were able to
do that. So we have a an a tool that
orchestrates this all and it takes an
input file to uh that defines what the
experiment is. We have another tool that
designs the plates. Uh and then another
tool that turns that plate design into
pipe heading instructions. We used a TCA
fluent. Uh and we did a growth
experiment where we measured the OD
every hour and then took that raw data
got the growth rates and then did a
check. Do have we met our conditions to
exit? If we have it generates a report
if we haven't it takes that data and it
adds it in and plans the next round of
experiments.
And again this was only a proof of
concept. Um we call it Aurelia uh
because everyone was using MVP for other
things. So that is the autonomously
repeating experimentation leveraging
integrated AI.
Uh but here's the here's kind of the
short version. So we're using uraria
lipolytica which is a industrial
relevant yeast. uh and it grows on a
carbon source as well as a nitrogen
source. And the nitrogen can be
expensive. So the experiment we're doing
here is to try to grow on a cheap
nitrogen source, which it doesn't grow
very well. But if you have a little bit
of the expensive one, you can get it to
grow. So we're trying to figure out
what's the the ratio that gives us the
best growth while trying to minimize the
amount of the expensive one.
Now in A we have to do some manual work
to get the the cells in the right spots
so that we can do the growth experiment
consistently. Uh B it shows the plate
that was the plate map that was
designed. We have uh repeats we checked
the edge effects uh and then it came up
with these conditions and then we built
the plates, we grew them and C shows a
few of the um the different conditions
that we tested and you can see some are
more consistent than others. uh but it
the tool is doing the statistics under
the hood and using that to produce D
which is the the map of the two
different nitrogen sources and the the
darkness of the blue says how how fast
the growth the maximum growth rate and
you can see it didn't have enough
information there to keep going. So the
red dots are the the uh ratios that it
picked for the second round. And at the
end we got at the second round we you
can see there's kind of a plateau in the
lower left. And so because we were just
doing proof of concept uh we said it's
done found it it found its confidence
well enough to produce that uh to
produce the exit and it worked. But you
can see this obviously needs a lot of
improvement, right? didn't didn't look
at anything in the upper right. Uh we
could tighten this up. We can show more
about how the um how it decided to maybe
ignore that one dark spot up in the the
upper left. But fundamentally it works
and now we are working to improve this
tool and also to extend it. So this was
done with a fluent that had a plate
reader and a single incubator shaker.
Now we have AMP 2. We have access to a
larger and better incubator. we have
more analysis tools that we can rope
into this. Uh so the team is working to
expand it
but um overall we're getting there. Uh
and it's a process that we need to
accomplish by the time MTPC gets here.
So this is our our grand vision. Uh on
the upper upper side we've got the
green. This is onboarding workflows
getting into that standardized format.
The blue is the the platform. So
generating taking that standard format
and generating scripts that can run. And
by separating those two, we can
build these tools out in a modular way.
So folks who are focused on um the
onboarding tools, they don't have to
worry about also making it work with the
Fluent and with the AMP 2 and with every
other system. They can just get to the
standard format. And then we have
specialists that work with the
automation that can take from the
standard format and get it down to the
the the scripting level. We have our
science central where the data comes
out. And then MIDAS on the orange side
doing the the tools that interact with
the models to take the data, improve the
models, use the models to make
predictions, to plan experiments and do
that autonomous loop.
And the um
the the last piece I would say about
this is that this this model side can be
as as complex as it needs to be. So it
could be a simple design of experiment
tool uh or maybe we can incorporate open
AI and do a much more complex design but
that still doesn't have to worry about
how do we implement that design on our
automation. They can just focus on that
tool.
And so that's our vision. And uh I
realize now after watching Will I forgot
to put my contact information up here,
but you can find me at Hemsel uh Todd
Edwards. Find me on LinkedIn. I'm happy
to chat. Uh and then yeah, definitely if
you're a data person, check out Science
Central and make use of that data
because taxpayer money funded it. So
it's free. Thank you.
>> Let's thank Joy and Todd.
>> It's GKO.