Is it an AI scientist or a Potato?
Potato (yes, that’s its name), a startup building “Autonomous agents for science,” recently announced a $4.5M funding round. This is big sign of traction for an emerging category of software that is so new, it doesn’t even have a name yet. So I thought I’d take this as an opportunity to explore what this category is and how Potato compares to some of the other entrants.
This newsletter explores news and trends in life science software. If there's something you'd like to see me cover (even if it's self promotion) send me an email at scalingbiotech@substack.com. I can't promise I'll use every suggestion but I'll try.
Last week, I claimed that the best problem for a software company to solve is one where A) they directly save or make their users a lot of money and B) it’s hard for others to do the same thing (i.e. there’s a moat.) This week, we’re going to focus on (A), but with a subtle detail I glossed over last time:
If there’s an existing solution to the expensive problem then teams will only adopt your solution if it’s an order of magnitude better than that existing solution. Or at least, teams that aren’t friends and family, and maybe a trickle of folks who happen to stumble across your solution at the exact right moment…
The thing about expensive problems is that if they really are expensive, there will be a solution. It may be a disorganized jumble of excel sheets, email attachments and prayers, but it will exist. If no one cares enough to have solved the problem, then it isn’t an expensive problem.
So there are basically two ways you can find an opportunity to build a significantly better solution to an expensive problem: First, you can find an expensive problem that has emerged quickly and recently enough that the only solutions are excel sheets, email attachments and prayers. Or second, you can identify a new kind of technology that enables an order-of-magnitude-better solution that wasn’t possible before.
I actually think the first kind of opportunity is slightly easier to navigate from a purely commercial perspective. But the second kind is more fun. And thanks to the ongoing advances in LLMs, there are suddenly a lot of them.
In particular, one of the new capabilities that Potato and the other startups in this emerging category are leveraging is the ability for an LLM to extract details and structured data from a free-text description of a lab protocol.
Now there are a lot of things that one could potentially do with this capability, but what I’ve seen mostly falls into three buckets:
Parse published protocol descriptions from lots of related research papers to help the user decide how to design their own protocols.
Parse the user’s free-text protocols to help them capture and communicate what they did to others, for example for training new team members.
Parse the user’s free-text protocols and turn them into lab automation scripts, or at least make it easier for them to turn them into automation scripts.
Note that 3 is essentially a sub-case of 2, but it’s worth calling out separately for reasons you’ll see below.
All the companies that I know of in this category have started from bucket 1:
Potato built out 1 for both lab protocols and analysis protocols, as a foundation for a digital version of a human research assistant (RA). With this latest round of funding, they’ll begin adding more functionalities that a digital RA would need, including bucket 3.
Briefly Bio started with bucket 1, but they quickly discovered that the protocol descriptions in most research papers aren’t detailed enough for what they were planning. So they pivoted to bucket 2, where they could guide users to add more details. But then just recently, they pivoted again to focus on bucket 3.
Elicit is the only one I know of that seems to have stuck with bucket 1. Their selling point is that they help users write literature reviews. They also have a broader scope than just biotech research.
And then there’s Elnora, which started with 1, then pivoted to end-to-end drug discovery. Their new website mentions mining scientific literature as part of their process, which I expect is making use of what they built for bucket 1.
I think the path that Potato and Briefly have taken from bucket 1 to 3 is a natural evolution towards more expensive problems:
Bucket 1 addresses something that scientists do a lot of and it’s a natural application of LLMs. But most scientists actually like reviewing the literature. In fact, it’s a core part of their identity that they mostly don’t want to give up. Which is one of the reasons Potato positions itself as a digital RA, rather than a complete replacement for the scientist.
The one exception to this might be formal literature reviews. And I suspect Elicit will be more successful in contexts where these formal reviews are an externally imposed requirement. In biotech/pharma, where literature review tends to be a more informal activity, it’s just not a big problem.
Bucket 2 is really a collection of problems. All together, they add up to a problem that’s expensive in the long term. But a successful product really needs one big, expensive and urgent problem to drive adoption. And bucket 2 just doesn’t have that, except for the one that I separated out for bucket 3:
Translating manual protocols into automated protocols is an expensive problem. It takes large, experienced automation teams months to translate some assays. If you can cut down either the time or number of people needed, that’s an easy sell.
It’s also a really hard problem - both because of the level of detail that’s required in the protocol descriptions and the fundamental complexity of translating that to machine instructions.
But if there’s anything I’ve learned from working in this space: I’d rather have a hard expensive problem than an easy problem that no one cares about. Hard just means it’s that much easier to build a moat.
Thanks for reading Scaling Biotech! When I'm not writing this newsletter, I help Life Science SaaS companies build sales and marketing systems tuned to the specific needs of a complex industry.
If you're looking for ways to connect the dots between building great tools and getting them into the hands of users, click here to request a free gap analysis.
I really like the delineation between the three classes of problems. It's a clarifying framework.