Q&A with Artificial and Radix Bio
AMA style interview with Co-Founder and CPO, Nikhita Singh, and Founder and CEO, Dhash Shrivathsa
This is reposted from a Q&A we did in February 2022. Check out our Slack for more.
We had the opportunity to interview, Nikhita Singh, Co-Founder and CPO of Artificial, and Dhash Shrivathsa, Founder and CEO of Radix Bio. Below we discuss current challenges with automation in the lab and how their companies plan on solving them!
Dhash: Hype for @nikhita and my q&a at 5 pm today. And would you look at that. It’s that time. Wrap up your beers, folks, we’re cooking drugs tonight in this q&a
Question #1:
Nicholas:
How did you personally get into automation?
What are the biggest challenges in automation right now? what is the biggest automation?
Automation feels like a field where you need to come to the table with a full solution. how did your company approach this when you first started out?
What is your biggest differentiator from what else is out there?
What trends do you see in the automation space?
Nikhita: Hi everyone, i’m nikhita :wave::skin-tone-4:. currently, i am co-founder and cpo at artificial, building automation infrastructure and tools for biotech labs. formerly at the mit media lab, palantir and uc berkeley autolab. looking forward to the q&a!
Dhash: My name is dhasharath , founder of radix.bio (ycs18) building operating systems and compilers for biology labs so we can finally understand where all the money goes. my background is in distributed systems, software research, and this is the extension of my work at mit
Nikita, i’m sure you have nuanced takes. Why don’t you take the first one and we’ll go from there.
Nikhita: Sure! i can start off with how i got into automation/robots. I used to think i would be a scientist and worked in immunology labs. i met a surgical robotics prof and became super interested in the robotics space and never really left. i think the part that always excited me was how you can make robots/automation that are super rigid and approachable to humans that are constantly changing things around!
Anonymous: Curious - what did you study in school? was it hard to break into the space?
Nikhita: I did industrial engineering & operations for undergrad which had some robotic elements. and then human-robot interaction in grad school at mit.
i think it took some time to break into the lab world. but thankfully had great teammates, and people are surprisingly willing to respond if you send them a cold email.
Anonymous: Cool! did you already have a bio background? i'm just so interested in all the serendipitous ways ppl find themselves where they are
Nikhita: I did not! i used to trade babysitting for a postdoc to teach me biology and let me do some of their experiments back in the day.... a long time ago. so it was a bit of a circuitous path back to science.
Anonymous: Haha yea that's super cool!
Question #2
Nikhita:
re: biggest challenges in the lab
i think a lot of it comes down to:
• data models are incomplete so you end up with a lot of piecemeal infrastructures
• lots of steps are still super manual -- i see paper sops and post its everywhere all the time!
• you need automation engineers who need to know how to wrangle the specific hamilton or Tecan liquid handler
• a lot of the technology tools (cloud-edge connectivity, remote access, etc.) haven't been made accessible to labs in the way they could be unless you have large in-house teams and many more!
Dhash: I came to robotics through infrastructure and storage automation, entirely through software. see, hardware is cool and all, i played with legos a lot as a child and did the first robotics competition, but anyone that has competed over robots knows, the hardware is dumb, it’s the software that matters. they’ll bump into themselves all day long, just like our competition has been for years. biology is no exception and is in a lot of ways, extremely regressive.
Question #3:
Nikhita:
re: "automation feels like a field where you need to come to the table with a full solution. how did your company approach this when you first started out?"
Sure! definitely true that folks always want a complete solution. for us, it was about finding some whitespace that was a core differentiator -- for us, it was the human-in-the-loop elements for sure. and then growing from there. what about you guys dhash?
Anonymous: I haven't spent any time really in a lab - can you describe how you can have the lab be both automated and still have humans in the loop i'm having a hard time picturing it?
Nikhita: Ya totally - let me send a picture, always better. we have user guidance tools that show someone what they need to do for a manual step to get the automated system ready for a run.
Anonymous: Thanks this is helpful! what does installation look like? is each one custom?
Nikhita: It's not! we have a bunch of standardized adaptors for local schedulers and we've built a bunch of applications that can be used to quickly get up and running:
• *labs* lets you drag and drop a digital twin of the lab using our equipment library of models from vendors like thermo, hamilton, tecan, etc.
• *assistants* lets you use our markdown language to put together a digital guide for all those paper sops
so it's pretty fast and our team usually helps customers get up and running pretty quickly depending on the complexity of the workflow.
Anonymous: Wow! that's super cool
Dhash: I have no idea what people are talking about when they say automation solutions. they always seem to spend a lot of money for a very inflexible single purpose tools. automation to me means rapid reprogramability and flexibility. automation in biotech seems to always forget the human element, except in academia where automation means grad students. the biggest challenge is biologists thinking that they know how to do automation and insourcing it, developing the same software again and again instead of factoring out common complexity like lims systems, schedulers, and such
Question #4:
Anonymous: Would you say your biggest "competition" then is in-house solutions?
Dhash: Maybe? i think it’s culture, build vs buy, and a general lack of problem framing and a desire to figure it out oneself. to quote one of our customers “we spent $20m and 10 years building this at my last company. we thought it would be easy. it was not, i’m never doing that shit again”. if only all customers knew this pain
Nikhita: Totally. i think flexibility doesn't really exist in most automation platforms at the moment. this was a big pain point we realized and honed in on early on. by building out dev tools and no-code editors for scientists and automation engineers so they can maintain flexibility.
i think that pattern holds true of a lot of robotics problems too -- not just in life science. i've seen so many robotics startups build the same stack over and over vs. leveraging external tools.
Question #5:
Nicholas: I've heard that “no code tools take you 80% of the way there, but then someone will always have to write code” — do you find that to be true?
Nikhita: Haha you touched on one of my favorite topics!
i like to call it "hierarchies of interaction". i think no-code (in my optimistic opinion), totally gets you 80%-90% of the way there. and honestly, that is great for 80-90% of use cases also.
so then there is the reality of the remaining use cases where it is not sufficient. and i think of this like enabling hierarchies of interaction for the various users. a scientist should be able to take it all the way through with no code most of the time. but then it is important to support the more advanced use cases, that an automation or software engineer may want to be a part of, by providing apis and tools for customization.
tldr - yes, but i think you can design for it if you are thoughtful from the beginning :slightly_smiling_face:
Dhash: Automation is actually a very granular field, and we’ve seen customers interested in just small chunks of our solution, choosing to license specific device drivers, schedulers, log collectors, dashboards, and storage/cloud infrastructure. there are customers that use not even our automation software, but rather our tooling to scrape logs off robots and such (which is where i’ve run into artificial before) to build error reporting and internal tools. automation is really broad, so getting started in it means that like eating an elephant, you have to take it one bite at a time
Nikhita: I also think there isn't really a one-size fits all approach. early on, i heard the quote "if you've seen one lab, you've seen one lab". there is a lot of differences in needs and heterogeneity of processes. so i think having a bunch of different applications/components that folks can leverage based on their specific need is important, rather than taking a single wholesale solution.
Dhash: Oh yeah, human-in-the-loop stuff is definitely a key differentiator, along with rapid reprogrammability and things like a fast scheduler and pipette tip allocation/robot path planning. our language doesn’t have the concept of pipette tips, since we can automatically figure out when to cycle tips and how many tip boxes would be required. time-to-automation is a really important metric for us, and not specifying things is always faster than writing it out
Roya: Depends on if you can create a need/value in the market for one particular application/workflow though in my opinion. like take akoya biosciences as ‘the spatial biology company’
Question #6:
Dhash: The other thing that has been huge is letting our customers share ip and workflows. when you can just import stuff, sharing protocols becomes very easy
Nicholas: If i may ask a silly question — has anyone tried to pitch you on web3 for this part?
Jacob: @dhash @nikhita sharing protocols caught my attention… have you been following what we’re up to in #collab-bioprotocols? there’s a community working on free & open protocol representation for improving exchange, and i wonder if that’s a good potential point of pre-competitive collaboration for you folks too?
Dhash: No
Jacob: @dhash is that “no you haven’t been following, but may be interested” or “no, we don’t want to collaborate”? :slightly_smiling_face:
Dhash: I’m pretty sure some of my engineers would quit on the spot if they saw that i have asked them to work with that. i’m not that stupid
Jacob: I’m interested in what leads you to say: “i’m not that stupid.” clearly you are seeing something that you believe is problematic about that effort while the folks engaged in the project are seeing something different. i’d be interested to hear more about your perspective since there might be important lessons that could be used to improve the effort.
Nikhita: @jacob just checked this out! @david (my co-founder) and i spend a lot of time nerding out about this. we've also been working on a python workflow representation at artificial to define manual/automated steps in a lab.
would love to learn more if you're open to a chat! at the very least, always good to meet other humans in the space! (nikhita@artificial.com)
David: Hi @jacob -- i like what i see poking around at #collab-bioprotocols and the general spirit of a standard protocol representation at a deeper level than say protocols.io. i think this discussion really demonstrates the breadth and challenge of the "tech transfer" barrier between how a scientist may want to describe a protocol and how one would want to formalize the protocol for automated execution.
i also like earlier more narrow conceptual work done here on common protocols by bill thies at ms research and some efforts like auto protocol, which has the right spirit as well.
really, anyone creating apis or tools that interact with the lab, will in essence be creating some viewpoint or model on protocol representations. scientists often describe their protocols with loose syntax leading to massive issues with reproducibility on the bench. automation adds in the domain of the instruments and robots and we view building the bridge from science to automation as a major but worthy challenge.
Jacob: @david @nikhita right on the same wavelength with you folks: a key goal with the work on paml is to establish an interlingua that can connect between these different representations, which also requires addressing a number of their shortcomings. folks working on both auto protocol and aquarium helped to design the representation, and it draws on both of them in its design. i’ll get in touch via email…
Dhash: Not a single thing is correct about rdf. That’s why i said you were wrong. Seeing a whole new crop of biotech companies using our stuff to license their ip. As far as greater trends, there’s so much money flowing into the space and biologists understand they need software, but only in recent years has it felt like they’re waking up to the fact that they can buy things from software vendors and the software guys may even know a thing or two about how to help out. much more cross-pollination of ideas and technology than the past. a greater focus on usability rather than the solutions offered by existing vendors like biosero and hamilton as well, as wall street is chomping at the bit to reduce r&d spend but the scientists still want to get work done — can’t do that unless you can find order of magnitude efficiency gains through intelligent software
But yup, i think that is all of the prepared questions, though nikita i think is still typing. feel free to ask any questions you have!
Question #7:
Nikhita:
re: as for what trends do you see in the automation space?
• i've seen more and more investment in automation in the lab
• folks having multiple different vendor solutions in a single lab
• there isn't really a "stack overflow" for lab automation - so there’s a lot of need for tools standardization and defining the "toolbox" of the future automation engineer (kinda like what phone app development went through)
• more focus on usability to improve human error, make automation approachable to scientists, and train operators
• and definitely a strong need to have the flexibility of tools. so much of precision medicine/cell therapy has lot size = 1 processes where things need to be fluid and change (unlike hts workflows from before). this demands a different software toolset than what currently exists
Question #8:
Nicholas: How (at what level) does your scheduling software interact with that of integrated systems (cellario, retisoft genera, etc)?
Nikhita: Great question! we have a bunch of adaptors that plug into all those local schedulers. we can monitor and show the state of each instrument to the user, collect logs/errors, provide basic control, and coordinate all the human steps around it (e.g., loading the high-res system and setting up cellario for a run).
Dhash: We usually replace them since ours is just faster and integrates much tighter with robots. there are some customers using ours for design space exploration like what piece of equipment should i spend my marginal dollar on to minimize end-to-end workflow time, which isn’t really a thing those schedulers do. our scheduler updates in real-time, which is reaaaally important when you leave the domain of fully automated setups.
We build adapters for drivers, but not schedulers, since ours is quite a bit more expressive wrt timing constraints, we can’t boil our logic into theirs.
We also generally have cost models so that we can answer questions of how long will this take and timing models around how long it takes to move around a lab that are crucial to our performance, we’re often considering thousands of schedules and dynamically switching between them as time evolves. cellario is just not fast enough for several of our customers taking days to schedule 100k fluid protocols. We’re usually seconds
Question #9:
Nicholas: How do you think about levels of abstraction in your codebase? are there things that you think should be industry-wide?
Dhash: So we have a couple, the first is an isa, where each class of driver is normalized to a specific instruction set (all pipetting robots asp, mov, and disp). there’s levels below that, specifically peephole optimizers that run in the context of this isa and handle lowering to multi-channel pipettes, tip allocation and such, and there’s a layer below that consists of a cloud to roll out drivers, establish networking, and fingerprint computers so we know what hardware they have attached. in the middle, there’s also performance characterization of each individual driver so we can track expected runtime/cost, track failures, and ship/attribute log lines to sub-protocols.
The cloud also contains storage abstractions to the drivers don’t attempt to send 20tb over the wire if they don’t need to. instead it moves the compute to the data, which is often much much lighter.
Above our isa we have a virtual machine where things like memory allocation and intermediate instructions like moving tip boxes and synchronization code between drivers that are being handed off to/from happen. it also implements garbage collection, process memory isolation, and thread direction. it’s where our scheduler comes into play, and the updates are automatically fed to lims.
Above that, we have a programming language. that’s pretty much it, then it’s all frontend gui’s
One would hope at least the isa’s would be industry-wide, but i have very little faith that different vendors can agree on a standard that isn’t ass
Nikhita: I think the connectivity layer to instruments should be industry-wide. i really think this bottlenecks a lot of adoption of automation because every vendor/software builder has their own connectivity library and not all of them have open apis.
for us, we want to be the "orchestrator" level and coordinate the instruments, people, materials and data that run through a lab's day-to-day operations. to do that, we basically have:
• *front-end applications* for making digital twins, guides for operators, and creating workflows
• *a workflow orchestration language* (based in python) where the workflow is described (complete with manual and automated work)
• *a compiler* that turns this into a workflow program that can be allocated to people or machines
• *a scheduler* that then turns it into a series of actions that be completed in the lab
• and *an executor* that actually kicks off the runs on devices/local schedulers and guides people through loading/unloading/manual steps that need to happen
Dhash: Due to how our thing works, we actually have 3 schedulers (ui, full-fat/fuzzer , and compute) and 3 compilers (top, vm, peephole)
Question #10:
Nicholas: Have you seen the scale of experiments increasing across the industry? not just within your clients, but among new clients?
Yohann: What do you think about sila or other standards in the field to facilitate automation to software communication?
Dhash: Meh? the big guys are getting bigger but i’m also seeing the barrier to entry come down quite a bit. some folks have experiments so big they have whole train layouts these days, but train scheduling is actually a pita so a lot of them are running under capacity since they can’t figure out train scheduling nicely
I’ve spoken quite a bit with the sila guys and when i find a customer that is actually using their stuff i will let you know. it’s a valiant effort but just isn’t enough
Nikhita: Definitely! i think the scale is increasing on many dimensions:
• amount of data
• number of runs
• and the number and type of processes that are being automated
that said, i think a lot of processes are still very manual and not optimized to be scheduled appropriately so automated systems are still often "expensive paperweights" that are underutilized.
Ditto on what dhash said on the sila front. very on board with vision / goals, but i think the adoption is lagging.
Dhash: The data problem is just insane though, some of our customers are pulling petabytes it’s scary. we partnered with protocol labs and ipfs just because we needed a place to put all the data that would take advantage of existing infrastructure and not just sit bottlenecked by the upload pipe
Data so thicc you can’t really upload it fast enough is why we built an s3 competitor
It’s especially spooky when you’re running geo-distributed. some of our customers have data teams in switzerland and rooms full of sequencers in boston and yup, it’s a hard problem
Question #11:
Yohann: What do you think vendors of instruments should do to make it easier to automate?
in my experience, dealing with binary proprietary format and no easy way to export automatically the data to readable format has been a barrier to automate some workflows.
Dhash: Yeah, docs that aren’t lies. we recently (after developing 40+ drivers) had the very first one where the manual wasn’t actually wrong. honestly a couple vendors have just been like “we have no idea how to write software can you handle this for us” and that’s a pretty good setup. they also seem to hate open source, so getting ci testing up and running actually just has us ripping hard drives out of machines to get something working in ci.
Nikhita: So we've been spending a bunch of efforts on the vendor relationship side for exactly this reason. i think vendors need:
• open, documented apis
• standardized data output formats
• "automation friendly equipment" - plate nests, easy reachability for a robot etc.
This would go a long way to making it easier to automate
Dhash: Also, we keep talented binary reverse engineers on staff just for this. can’t hide from ghidra
Nikhita: The reality is every vendor wants a "closed ecosystem" but i've yet to see a lab that has equipment from only one vendor. That said, they've been pretty nice to us for getting access to models/manuals etc. and collaborating on getting their equipment into our lab editor equipment library (for making digital twins), so hoping that helps!
Dhash: And when you’re dealing with fancy shit like mass specs, lcms systems, and protein synthesizers it really helps to build your own stuff.
The vendors just don’t plan for that kind of thing. they’re all opaque c# dll’s and there is no choice but to reverse engineer stuff
Nikhita: Thanks for joining guys! appreciate the thoughtful questions :slightly_smiling_face: feel free to ping me at nikhita@artificial.com. always happy to chat lab automation / robots etc.:dna::robot_face:
Dhash: Yup! same here dhash@radix.bio
Nicholas: Thank you both!! super interesting to hear how much alignment there is