I won’t be able to answer that question this week, and in fact it’s probably not exactly the right question. Instead, I’m going to explore what this looked like for QSAR, one of the earliest digital technologies in drug discovery. Then I’ll discuss why this approach is limiting and how the advent of vibe coding might begin to change that calculus.

Before we start, I want to clarify what I mean by inside vs outside the industry. I’m not going to argue about who counts as a scientist and who doesn’t. Instead, I’m talking about about the role they’re in and whether their primary responsibility is to help bring drugs to market or to develop new software/tools/models. The same person could be inside or outside, depending on their job.

QSAR

QSAR is the idea of embedding molecules in a vector space by defining features from their molecular structures, then training ML models on the vector space. The earliest QSAR algorithms used one-dimensional regression models, but the same approach is used today with much more complex models and embeddings.

The idea was developed by Corwin Hansch, a professor at Pomona College, in 1962. By the end of the decade, Eli Lilly had a team of chemists, mostly hired from academic computational chemistry labs, writing internal algorithms on the first transistor-based mainframes at a time when punch cards were just being phased out.

Thanks to reorgs (which I forgot to put on my list last week), Lilly pulled back on this in the early 70s, allowing Merck and a small company called Smith Klein & French (later acquired by GSK) to take the lead. By the 1980s, QSAR was a common, if not standard, method across pharma.

From inside or outside?

The chemists who developed these tools were trying to make the existing process of small molecule optimization more efficient: Given an initial hit, they could design 100 small modifications that might make it better or worse. Previously, they would need to synthesize and test them all in vitro. With QSAR, they could digitally predict which ones were most likely to work, and only synthesize those.

So QSAR was built around an immediate need, improving an existing step in the drug discovery process, by the people who were responsible for that step, writing the code themselves. The benefit of this was that there was no question about whether or how the scientists would use these new tools. It was just a question of whether the models would work, which they did (at least eventually).

However, there are also two major limitations to this development model, compared to building new tools from the outside.

The Pi-shaped person

The first bottleneck is finding scientists who deeply understand both the science and machine learning/software engineering/etc. These people exist, but not so many of them, and they can’t go as deep on either side as someone who specializes in one or the other.

Vibe coding could provide at least a partial answer to this. For now at least, we still need humans who understand software engineering to build the production-grade systems, making sure the coding agents follow secure practices and don’t do anything stupid. But vibe coding allows scientists to build prototypes of their ideas that engineering teams can then incorporate into production-grade systems. So it could allow more scientists to help develop their own novel tools without needing deep engineering skills.

Optimize or Disrupt?

The more existential limitation is that if new digital tools can only improve and optimize existing processes then we’ll miss opportunities to make larger changes to the drug discovery process that new technologies theoretically enable.

Someone whose job is to envision and build the next generation of digital tools is more likely to think in terms of those broader changes than someone who is thinking about how they can hand off a candidate to the next step faster. On the other hand, the scientist pushing drug candidates along the pipeline will have a more realistic perspective of what’s possible. So maybe we’re back to needing those hybrid scientist/engineers who can understand the full potential of the new technology.

I don’t know what the answer is, but I feel like this is at least getting closer to the right question. Stay tuned as I keep pulling on this thread, and other nearby ones.

Thanks for reading! My company, Merelogic, helps biopharma teams apply the rigor they demand inside the lab to how they integrate AI and other digital tools into the drug discovery process. You can learn more at merelogic.net.

** But first, a quick update on the AI-for-biotech course I’m working on with Scriptome.ai: The course has been approved by the Massachusetts Workforce Development Training Fund, which means your can get your tuition reimbursed if you work for a Massachusetts company with fewer than 100 employees. You can find details on the course page. **

It ended up being a fairly long list, so I split it into five categories to make it easier to see how they fit together. They all probably contribute at least a little to the situation, but as I dig in more, I’m hoping to get a better sense of which ones are the most significant.

Also, I reserve the right to update this list as I dig deeper. In fact, if you notice anything I missed or have any other suggestions, feel free to leave a comment, reply to this email, send me a email separate email (jesse@merelogic.net) or reach out in whatever other way you can find.

Here’s the list:

Category 1: Our perception is off

1. The grass is always greener: Tech adoption is hard in every industry. Maybe it isn’t any harder in biology, and our expectations are just too high…

2. Would we even know?: Clinical timelines are so long and sample sizes so small, it’s possible some teams have already figured this out but we never noticed or haven’t noticed yet.

Category 2: It’s the science

3. More exceptions than rules: Is biology just fundamentally too complex to accurately model, even with billions of parameters?

4. Constrained by data: Maybe the cost and nature of how we’re able to collect biological data prevents models from meaningfully generalizing.

5. Out of sample: Biopharma innovation happens at the boundaries of knowledge but ML models are mostly good at generalizing within the bounds of their training data. Are we expecting them to extrapolate beyond their limits?

6. The reproducibility crisis: It’s well known that some (maybe a lot of) biology papers have unreliable results. Do public the datasets that are regularly used to train models have too much noise masquerading as data?

Category 3: It’s the culture

7. Gatekeeping: Biologists over-estimate how specialized and complex biology is, so they’re reluctant to give models a chance. I mean, not *all* biologists, but at least a few… Is it too many?

8. The wrong data: Until recently at least, most data was collected from experiments focused on specific, narrow questions that made the data hard to incorporate into more general training datasets. Have we just not created enough training datasets?

9. Too many silos: Maybe the political, compartmental nature of pharma companies, and even many biotech startups, has prevented the kind of collaboration required for more fundamental changes…

10. Alien worlds: The data scientists and AI/ML engineers who build the models just think fundamentally differently than the biologists they need to work with. Are there just not enough experts who understand both worlds?

11. Red tape: Do the procurement processes and the long buying cycles of large pharmas kill all the innovative companies before they can make a difference?

12. Regulatory burden: Maybe regulatory demands make real innovation too difficult, if not impossible…

Category 4: It’s the economics

13. Boom and bust: VCs want companies to become profitable on a much shorter timeline than the 10-15 year clinical cycle allows. Are they giving up too soon, or forcing companies to try and meet unrealistic timelines?

14. The pipeline trap: Many innovative platform companies have been pushed into developing their own pipelines, which introduces unrelated risks like picking targets that become commercially unviable when the market shifts. Has this killed too many companies with otherwise solid technology?

15. Good enough: Existing tools and approaches are still good enough to get drugs to market, and they’re safer than betting on something new. Maybe pharma leaders are too often picking good enough over innovative-but-risky new options.

16. Assets over innovation: Biotech investors value individual assets over innovative platforms. By reducing investments in innovation from the science side, are they forcing digital/platform companies to work with tech investors who can’t advise them from an insider’s perspective?

Category 5: It’s the technology

17. Legacy systems: Most big pharma companies rely on a foundation of legacy infrastructure, full of technical debt. Is the technical friction this creates for new tools just too much?

18. Black box: Many of the new models are black-box in nature while most biologists consider the causal interpretation as important or more important than the actual prediction. Maybe causality and interpretability are the issue.

19. Alignment: Many of the predictions that these models make aren’t closely aligned with the existing stages of the drug discovery process. Are we going to need to fundamentally change the drug discovery process to start using these tools?

20. Interfaces: Connecting these models to the data and to each other often requires significant technical know-how and often isn’t aligned with how scientists think. Do we need better interfaces?

That’s my preliminary list. Did I miss anything?

Thanks for reading! My company, Merelogic, helps biopharma teams apply the rigor they demand inside the lab to how they handle data outside the lab. You can learn more at merelogic.net.

The Deal

Relation’s website links to a number of articles about the partnership, though most are behind paywalls. As usual for this kind of announcement, details are limited, but we can work out the general shape of the deal.

Relation will use the $110M to generate data measuring gene expression under different cell perturbations. They’ll use the data to help train an internal model called MORGAN that they announced at the same time as this partnership. It’s unclear if GSK will have direct access to this model or if they’ll only get indirect access through their ongoing partnered drug programs with Relation.

Regardless, GSK will also get the data itself to train their own models. So this makes the deal more of a data co-development partnership: GSK covers the cost, Relation generates the data, both companies get to use the data. Relation doesn’t offer the data or the model as an externally available product, so the data is effectively proprietary and exclusive. (At least for now - it’s unclear what happens if Relation ever wants to use the MORGAN model for a partnership with a GSK competitor…)

GSK’s Strategy

This is an interesting addition to GSK’s ongoing efforts related to virtual cell/perturbation models. In addition to the NOETIK deal from January, GSK has also stated publicly that they’re building their own perturbation models internally, suggesting that it’s trying to build internal capabilities alongside these partnerships.

As far as I can tell, this makes GSK the most active large-pharma player when it comes to virtual cell/perturbation models for early discovery (as opposed to clinical virtual patient models). I don’t know if the rest are waiting to see how effective these models prove in the long run (which may be years off) or if they just haven’t been as public about their internal development efforts. But either way, GSK seems to be making a big bet.

As I’ve stated previously, I think there’s a lot of potential for virtual cell models to fundamentally change drug discovery and address the clinical information bottleneck, though it’s far from guaranteed. So I see this as a high-risk, high-reward bet. I sincerely hope it pays off.

Thanks for reading! My company, Merelogic, helps biopharma teams implement tools and practices to build a solid data foundation for whatever comes next. You can learn more at merelogic.net.

Two markets

The first thing we need to recognize is that Isomorphic didn’t deprive other biotech startups of the $2B they recently raised, since that money wouldn’t have gone to biotech startups otherwise. If not for Isomorphic, those investors would’ve given it to AI-enabled toasters or digital pet companions or some other questionable AI-driven hype. Meanwhile, the investors who typically invest in biotechs might’ve been willing to invest in Isomorphic, but probably at a much lower valuation.

I’m making a simplifying assumption that we can cleanly separate investors into biotech investors and pure tech investors. This isn’t true, but if we run with that for a second and add in the assumption that tech investors are open to higher valuations for AI companies than biotech investors are for the same company when viewed as a biotech, then this means that any company that can pass as an AI company can get a valuation that essentially locks out biotech investors.

So the two distinct categories of investors create two distinct categories of startups and two separate but adjacent investing markets that share a long border.

Now, what happens when one of them is a giant bubble? Let’s start by reviewing the mechanics of bubbles.

The mechanics of bubbles

A bubble forms when investors think that a resource is going to be worth a lot more than what it currently costs to build it, so they pump money into building the thing. It could be houses or internet companies or data centers or foundation models. As more investors pile in and the numbers get bigger, it reinforces the belief that the resource is going to be worth even more.

The problem is that once the amount invested becomes more than the resource is actually worth, someone is going to lose money. The first investors who notice and react can usually get most of their money back. After that, the longer investors wait, the more they lose. So once the sentiment starts to shift, it kicks off a race to get your money out. That’s why bubbles pop instead of slowly deflating.

That sucks for investors, and it can be even worse for companies who make long-term plans based on the assumption that they’ll be able to raise more money, then find out they can’t. But there can be a silver lining for everyone else…

What bubbles leave behind

The thing people often forget is that bubbles often leave behind the resource that the investors paid all that money to build. Sure, it’s worth less than the investors thought it would be. Sure, some of the companies who built it are long gone, along with some of the investors. But the thing they built is still there.

After the housing crash of 2008, there were a bunch of houses that might not have been built otherwise. Some were McMansions that no one wanted to live in, but they were there. The dot com crash of 2001 left the infrastructure that made today’s internet possible.

Whether or not AI is currently in a bubble depends on what the actual value turns out to be. But even if it isn’t a bubble yet, it certainly looks like it will make it there eventually.

The two questions for biotech are: 1) will the AI bubble popping impact the sentiment around biotech, causing biotech investing to crash as well? And 2) what will the AI bubble leave behind that biotech can benefit from?

I won’t speculate about the first one, but I will about the second one.

Models and data

The data centers that an AI bubble will leave behind are a mixed bag, with tremendous environmental implications, but also the possibility of much lower compute costs once supply surpasses demand. That applies across all industries.

The one that’s more interesting for biotech specifically is the bio foundation models that will be built and trained, along with the data that trained them and, perhaps more importantly, the knowledge of how to train and use them.

If Isomorphic becomes a trillion dollar company, its investors will look like geniuses. If not, the company may cease to exist. But we’ll still have the open source OpenFold model based on everything Isomorphic learned building its internal model. And we’ll still have the open source boltz model and a bunch of other models that learned from this as well. And sure, maybe even that won’t turn out to be worth $2B. But it’s better than AI-enabled toasters and digital pet companions. And thanks to those tech investors, it won’t have cost the biotech community a single penny.

Thanks for reading! My company, Merelogic, helps biopharma teams implement tools and practices to build a solid data foundation for whatever comes next. You can learn more at merelogic.net.

Understanding these categories is important because early discovery research isn’t covered by GXP. Being free of GXP gives teams the flexibility to try new things and move fast, unencumbered by strict rules about to handle their data, but ignoring the principles entirely means working without a safety net. It means your team doesn’t get the security and reproducibility that GXP is meant to ensure.

So in practice, it’s up to you to decide what level of risk you’re willing to accept in return for speed and flexibility. Framing the risks within a hierarchy can help you add the right guardrails to avoid the risks that could bring your programs to a screeching halt, not just adding hurdles because it’s the “right” way to do things.

Acute to Chronic

Here’s how I’m currently defining the categories, though I may revisit this in the future (I’ll probably at least rename them):

1. Acute, Avoidable Risks: These are risks of events with immediate negative impacts that can be avoided if you take the right measures in advance. They’re mostly types of mistakes like errors in manual data processing, picking the wrong version of a file or sharing sensitive information with partners such as CROs. They can typically be addressed by simplifying or automating manual processes, as well as adding audit trails so you can catch the mistakes earlier. If these mistakes go uncaught, your team could spend months chasing ghost results, or worse.

2. Readiness Risks: These are risks of being caught unprepared for inevitable events, whether that means being unable to minimize the impact of negative events or being unable to take advantage of positive ones. These include risks that make it harder to quickly analyze new data or verify results that seem significant, as well as being able to recover from potentially cataclysmic events like losing the one person who knows where all the data is. The cost of being unprepared may be lower than the cost of acute, avoidable risks, but they come at a time when you can least afford them.

3. Overhead Risks: These are issues that slowly build up over time and scale, such as small delays at each stage in a process leading to significantly longer timelines across a program, or a team that doesn’t trust its data demanding more and more validation assays until they can barely make decisions. These risks are often subtle, making it harder to estimate or identify their cost and impact. They can often be addressed with relatively small changes but those changes need to be applied consistently, which makes them much harder to address.

The Hierarchy

What’s nice about these categories is that addressing each one creates a foundation for dealing with the next. Addressing the acute, avoidable risks frees up time and cognitive load to start thinking about readiness risks. Then once you’re confident that you’re team will be ready for whatever comes its way, you can start thinking about addressing the more subtle overhead risks to optimize how the team works.

This is not to say that you have to address each category before you can move on to the next. Just like you can address multiple layers in Maslow’s hierarchy at the same time, you may decide to prioritize risks from these categories in any order. The point is that understanding this hierarchy can help you decide which risks you need to address first, which ones can wait, and which ones are a reasonable price for flexibility.

Thanks for reading! My company, Merelogic, helps biopharma teams implement tools and practices to build a solid data foundation for whatever comes next. You can learn more at merelogic.net and request a free Data Risk Review.

**But first: I’ve been offering free Data Risk Reviews to early discovery biopharma teams that want to build a strong data foundation for whatever comes next. If having trustworthy data matters to you, click the link to learn more.**

Teams and Timelines

The story starts when Google’s DeepMind released AlphaFold2 in November 2020. They released the model’s weights and the code for running inference as open source on GitHub, but kept the code for training the model private. This meant that while anyone could use the open source code to generate predictions, they couldn’t train their own version of the model or fine tine the weights using proprietary data.

To address this limitation, the OpenFold foundation was founded in early 2022 as a non-profit backed by both academic and industry/pharma partners. Their goal was to build a fully open source implementation of AlphaFold2, called OpenFold2. Since then, they have built a consortium that includes large pharma companies such as Bristol Myers Squibb, Novo Nordisk, Bayer, Roche, and UCB.

After DeepMind released AlphaFold3 in May 2024, the OpenFold foundation began work on OpenFold3, again with the goal of replicating the model with a fully open source implementation. (I’ll describe the technical differences between AlphaFold 2 and 3 in the next section.)

Shortly after that, in November 2024, a group of researchers at MIT released Boltz-1, a fully open source model that took the main ideas from AlphaFold3, but made changes designed to improve its performance. Then in June 2025, they released Boltz-2, a model that added capabilities that weren’t available in AlphaFold3. (More on that below too.)

In January 2026, the developers of the Boltz model founded a public benefit corporation called Boltz, headquartered in London. This allowed them to raise money from VCs while continuing to maintain the fully open source Boltz models.

Introducing diffusion models

To understand the technical differences between OpenFold and Boltz, we need to start with the differences between AlphaFold 2 and 3. Both models start with a transformer model where tokens represent amino acids to infer spatial and physical relationships between all pairs of amino acids in a protein. Where they differ is how they translate this into a protein structure:

AlphaFold2 uses a deterministic algorithm that translates the pairwise relationships into the final positions of the amino acids. AlphaFold3 uses a diffusion model to predict the locations of individual atoms from the token embeddings. This is similar to how image generation models predict the colors of individual pixels in an image based on the token embeddings of a sentence describing the desired picture. The sequence of amino acids is the sentence. The individual atoms are the pixels.

Roughly, the diffusion model creates embedding vectors for the individual atoms in the same latent space as the amino acid tokens are embedded by the transformer, then applies an attention algorithm to update the atom embeddings based on the embeddings of both the amino acids and the other atoms. This is similar to how a transformer re-embeds tokens, as described in my post about transformers. The model uses the final atom embeddings to predict their positions.

AlphaFold3 also made some changes to the transformer algorithm that put less emphasis on reference structures (MSAs) for inferring the relationships between amino acids, but that’s kind of in the weeds. The important change is the diffusion model.

Boltz and OpenFold

The goal of OpenFold3 is to replicate AlphaFold3 as closely as possible, so there are no major atchitectural differences between OpenFold3 and AlphaFold3. Boltz, however, is intended to improve on AlphaFold, so they made some specific changes to the architecture.

Most of these changes are too technical to go into here, but an important one is how the model interprets the outputs of the diffusion algorithm: In AlphaFold3 and OpenFold3, the predicted positions of the atoms are compared to the coordinates of the reference structure for a fixed position and rotation of the overall protein. However, that rotation and position don’t actually matter to the answer; it’s only the relative positions of the atoms that we care about. So before Boltz-1 compares the predicted positions of the atoms to the reference, it first applies a translation and rotation to the whole structure that gets the atoms as close as possible to the reference positions. That way, if the model predicts the right structure but with the wrong rotation, it still counts it as right. OpenFold3 would count it as wrong.

Because of this change and the other architectural differences, Boltz has performed slightly better than OpenFold3 on certain benchmarks, though the results aren’t completely conclusive.

The bigger difference came with Boltz-2, which introduced the ability to predict binding affinity between small molecules and a target protein. OpenFold3 can only. predict co-folding between the two, i.e. it can predict a stable position of a small molecule and a protein in close proximity. But it doesn’t predict the likelihood of the molecule getting into that position, or how strongly it will bind once there.

This means that Boltz-2 can be used directly for virtual binder screening. OpenFold3 can be part of a virtual binder screen, but only if you couple it with a model that predicts binding affinity of the predicted positions. Though as I argued recently, this isn’t that valuable on it’s own, and both models are probably cheating a little.

So which one is better?

Between OpenFold3 and Boltz-2, there isn’t a clear winner. The difference in accuracy will probably depend on the type of protein(s) you’re looking at, and in many cases may not be big enough to actually matter. The bigger differences are going to be related to what’s involved in actually getting them up and running.

OpenFold is focused on supporting large pharmas like the ones who fund their foundation. So that means providing enterprise support that can work with a large IT organization. Boltz is much more focused on smaller startups, and has worked to make their model as lightweight and cost effective as possible so anyone can get it up and running.

Which one you should use depends on a host of different factors from accuracy to application to ease of use, far too many to go into here. Luckily, since they’re both open source, you can try both and decide for yourself which one is the best fit.

Thanks for reading! My company, Merelogic, helps biopharma teams implement tools and practices to build a solid data foundation for whatever comes next. You can learn more at merelogic.net or by requesting a free Data Risk Review.

In this post, I’ll explain why I think we need this new role and what I think it should look like.

No one cares about data hygiene. Should they?

For the rest of this post, I’m going to use the term “data hygiene” to mean all the work that goes into ensuring that the data a team needs is in the right place at the right time, in a form that they can use and trust. This includes things like data infrastructure, architecture, quality, management, curation, engineering, informatics, etc. It’s not a great term, but it sums up what all these other terms are getting at.

The big problem with the way we talk about data hygiene (whatever name we use) is that it makes it really easy for biopharma leaders to conclude that it’s low priority or unnecessary. Because of this, most companies either under-invest in it or put it off for later (which turns into never).

There are two different ways to interpret this: Either we’re presenting things accurately and it is, in fact, low priority, optional work OR we’re not presenting things right. I think it’s the second one, which means that one of the most impactful things we can do to help the industry is make a better case for data hygiene.

The problem, as I see it, is that we often frame data hygiene in terms of the long-term benefits and principled approaches to doing things the right way. If you look at job titles, we have engineers and architects building cities of data that are designed to last into the future. We have curators and stewards preparing to hand data off to the next generation of analysts.

Biopharma leaders don’t care about the next generation of analysts. They care about the next milestone. They care about eminent risks and immediate value. They care about keeping their current fires under control long enough to make it across the finish line without starting too many new ones.

If data hygiene doesn’t help them do that then who can blame them for ignoring it?

Eminent risks and immediate value

There are real, significant, immediate risks to under-investing in data hygiene. Small errors like pasting data into the wrong cell in a spreadsheet or using the wrong version of a file can lead teams down months-long wild goose chases trying to validate spurious results. But regardless of how well we present these risks, the bigger problem is connecting the dots of how data hygiene addresses them.

The problem is that the work of data hygiene is often presented as an abstract layer of automation and control, separated from the day-to-day work of scientific teams they support. And in practice, in the places where the teams do come in contact with this infrastructure, it’s often under-used or used incorrectly because they don’t understand how it fits their needs and their workflows.

The goal of introducing the data concierge role is to reframe the work I lumped under “data hygiene” around immediate value and risk prevention by providing a tangible way to ensure teams use the available tools to do better work while minimizing risk.

Enter the Data Concierge

A data concierge is a person responsible for maintaining a biopharma team’s data standards and conventions, helping the team navigate them and coordinating efforts to add automation and supporting tools (though not in that order).

It isn’t a job title, necessarily, but rather a role that an FTE can take on as part of their responsibilities, or that can be outsourced to a fractional contractor.

They’re responsible for things like:

• Answering questions from team members about where to find data and where to put data. (An LLM or MCP server can probably answer most of these questions, but the concierge is responsible for keeping its configuration up to date and stepping in when the LLM gets confused or a user wants to talk to a human.)

• Managing the process of defining new conventions when the team runs into new use cases. (The decisions should be made by team members, but the concierge coordinates the process and acts as referee when necessary.)

• Documenting the conventions in a way that can be handed off to a new concierge at any time. (This same documentation could probably be used to power the LLM/MCP, but more importantly it means things won’t crumble if and when the person in the role of concierge moves on.)

• Monitoring the data in the different systems to ensure teams are following conventions and to identify the best places to add automation or new tools.

• Sketching out new data architecture and infrastructure and how it fits into the team’s workflows, then coordinating the implementation and rollout.

Note that I listed these responsibilities from immediate, user-facing value to longer-term, more abstract value. I did that on purpose: We want to start with the things that are a clear win, making life easier for the team while addressing risks, then move towards the more abstract things that are necessary to support that immediate value.

Hold on, “concierge” sounds expensive…

One obvious risk with this framing is that “data concierge” sounds like a luxury service. Cash-strapped biotechs with quickly shrinking runway will think this is a frivolous nice-to-have that they can’t afford.

And I’m OK with that because they probably can’t afford a data architect either.

The thing is, even folks who can’t afford to stay at the kind of hotel that has a concierge know why the concierge is there and why they wish they had one.

Tesla started by selling expensive sports cars to show that electric cars can compete with gas-powered cars, then slowly made them less expensive until they became a mass market staple. There are obviously a few differences between Tesla and what I’m proposing, but I believe the same strategy can work: Start with something that feels like a luxury and is clearly worth it if you can afford it, then turn it into a luxury that everyone can afford.

In other words, we need to stop under-selling data hygiene (by any name).

But it’s worth it!

For teams that understand the value of investing a little but up front to avoid expensive mistakes that could cost many times more, investing in a data concierge should be an obvious decision for the teams that can afford it. That’s why companies pay for insurance and a bunch of other things.

And biotechs that aren’t within a few months of eminent death can afford this too. (Granted, that’s a shrinking group, but it’s not empty.)

If you’ve read this far and think this is an idea worth exploring, I’d love to hear what you think. You can reach me at jesse@merelogic.net.

Thanks for reading! My company, Merelogic, helps biopharma teams implement tools and practices that ensure they can rely on their data, driving more confident decisions and building a solid foundation for whatever comes next. You can learn more at merelogic.net or by requesting a free Data Risk Review.

(A lot of this also probably applies to Chai Discovery’s recent $400M raise which was announced between when I wrote this post and when it went out.)

First, the cynical take

I want to keep this post positive, but just to get it out of the way, I feel like I should address what I suspect most biopharma insiders were thinking when they saw this announcement:

The investors in this round, all of whom where tech investors and sovereign wealth funds, probably saw the succession of multi-billion-dollar contracts that Isomorphic signed with big pharma as serious validation. But it’s not unheard of for pharma execs to drop a $30M up-front payment for the prestige of working with a big name spinout from Google/DeepMind, confident that by the time the project is quietly canceled in a few years, they will have moved on to their next role.

From that perspective, the $2B investment seems like a bad idea. But it’s also possible that in 5-10 years, Isomorphic will be worth hundreds of billions and these investors will all look like geniuses.

The rest of this post is going to explore the question of what it would take for that second scenario to happen.

Is binding a big deal?

I’m going to make the assumption that a large part of what Isomorphic has planned involves using AlphaFold to do binding prediction, i.e. predicting whether a drug candidate like a small molecule or a protein will bind or otherwise interact with different target proteins, including proteins without a known/experimentally verified structure. I’m sure they’re working on other models too, but Isomorphic was built around AlphaFold, so that’s what I’m going to focus on.

Binding is what determines most of what a drug candidate does in your body. So in theory, if you can determine how it binds to every protein in your system, you should be able to predict fairly accurately what the drug will or won’t do.

However, in practice, most drug discovery teams only measure binding with at most one target protein in a large-scale screen. After that, they do functional assays, genomics, etc. on the hits to understand the downstream impacts of everything else the molecule binds too. That initial binding assay is one of the least expensive parts of the process, even when you do it across millions of potential drugs.

So if you were to tell the lead scientists on a drug discovery program that you can replace that one binding experiment with a (potentially less accurate) digital model, their response would be “I’m good with the large-scale screen, thanks.” And if you tell them that you can predict whether their drug candidate binds to any protein in the genome, their response would be “What do you expect me to do with that?”

Drop-in Replacements

OK, that’s probably not how they would respond. Scientists tend to have plenty of ideas about how they could use new kinds of information to answer interesting questions. But when it comes time to actually use those answers, they mostly don’t because they don’t have a specific step in their existing process where that information answers the specific question they need answered.

And sure, Isomorphic could use the binding predictions to infer the likely outcomes of all the functional assays, genomics, etc. that answer the questions specific questions that scientists need to answer at specific steps in their process. But those models would probably be less accurate than models trained directly on the outcomes, let alone doing the actual experiments.

And even if they could predict these things faster, cheaper and more accurately than the existing lab experiments, these steps aren’t very slow or expensive compared to the later stages, particularly clinical trials. So they still wouldn’t be solving a multi-billion dollar problem.

The clinical information bottleneck

On the other hand, they could probably use all these binding predictions to infer a whole bunch of other things that most biologists have never even dreamed of knowing, maybe with the help of a virtual cell model.

More importantly, this information could probably rule out drug candidates that would fail in clinical trials but that existing experiments can’t rule out. Lowering clinical failure rates even a little would actually justify a $2B funding round in ways that no amount of improving the existing early discovery process ever will.

However, for biologists to use that information in practice, they would need to change their overall process so that the questions that these new models answer are the specific questions that they need answered at specific times in the new process. In other words, they would need to modify the process to create the gaps that they can drop the models into.

Evolving Drug Discovery

So to make its investors look like geniuses, Isomorphic can’t just build better models and hand them to scientists. They’ll need to define how the drug discovery process will need to evolve to accommodate these tools, then somehow orchestrate the change management, with partners or their internal teams, to make it happen.

Otherwise, Isomorphic will become just another cautionary tale of misguided techies who over-estimated how well they understood pharma.

Thanks for reading! I help biopharma teams evolve their processes to extend the rigor they demand inside the lab to how they handle data and leverage AI outside the lab. If this is something you’re trying to figure out, visit merelogic.net to learn more.

1. They released a platform called Claude Science that, from what I can tell, is mostly the existing Claude UI with some pre-installed MCP servers.

2. To dogfood this product, they’re starting an internal effort to try and identify drug candidates for rare and/or orphaned diseases.

While their goal is clearly to drive adoption of Claude in pharma and biotech, I think this is much more likely to backfire and actually push these teams off of Claude. And this week, I want to explain why.

Is Claude Science a big deal?

My first impression when I read about Claude Science itself was mostly “meh”. Sure, they have built-in integrations with many of the hottest AI-for-biopharma vendors and they provide a single place where you can access them all centrally, but like… that’s not actually that new.

In the last few weeks, I’ve been writing about how all these companies are already building their own MCP servers that you can hook up to Claude or any other LLM. These integrations usually just take a few clicks to configure, so it’s unclear exactly what they’re providing that you couldn’t get elsewhere.

Sure, it will be easier for big enterprises to use a pre-packaged solution from an established vendor, but even there, there are existing solutions like Sigmatic (formerly Helix AI). And this slight advantage will be overwhelmed by the negatives associated with the second announcement and a broader tide that’s working against commercial LLM builders like Anthropic and OpenAI.

The tide is going out for token-based pricing

In the last few months, even the most die-hard AI boosters have started to notice that tokens are getting expensive. I won’t recount all the stories about obscenely high Anthropic and OpenAI bills, because I’m sure you’ve heard them.

At the same time, there’s more chatter, though maybe not quite as loud yet, about open weight models that are almost as good, or just as good, as the commercial models. Anyone can download these and run them locally on their own Cloud instances. With unlimited tokens for the cost of the compute, some early adopters are reporting costs as low as 1/100th what they were paying for tokens.

Obviously, there’s a lot more friction involved in hosting your own LLMs, but there are open source libraries that can handle most of it, and the economics are increasingly making it worth that hassle. (If you want me to write a post about self-hosting a Claude clone, let me know…)

The problem for Claude Science is that the whole point of it is to make you use Anthropic’s models instead of hosting your own, so part of the business model is that it needs to be more expensive.

Competing with your AI provider

So, that was a problem for Anthropic even before last week’s announcements, perhaps an existential one. But on top of that, Anthropic has now made an announcement that its life science customers will read as “We are going to start competing with you, using what we learn from you using our product, and possibly holding back the best features for internal teams.”

Now, this is NOT what they meant to say. In fact, I think the whole point of focusing on rare and orphaned diseases, which usually aren’t commercially viable, was to seem less threatening.

They claim that the reason they’re doing this is to get first hand experience that they can use to improve the product. And I actually wouldn’t be surprised if they’re being honest, just because it would be crazy to think that an internal version of Claude Science would give them a material advantage over companies who deeply understand the other 98% of the drug discovery and development pipeline.

But it kind of doesn’t matter. Because just the risk that Anthropic might be secretly planning to do a spin-off like Isomorphic Labs for AlphaFold, or that they might change their minds to do this in the future, will make most life science customers reluctant to let Anthropic touch their data.

But things change fast these days…

I always promise not to make predictions about the future, and I always seem to break that promise, or at least come pretty close to it. And who knows - the landscape is changing faster than anyone can keep up, and the dynamics will probably shift again before this has any lasting impact. But I’m going to be vary curious to see how this play out.

Thanks for reading! I help biopharma teams evolve their processes to extend the rigor they demand inside the lab to how they handle data and leverage AI outside the lab. If this is something you’re trying to figure out, visit merelogic.net to learn more.

Model Interpretability

As AI/ML models get more complicated, it gets harder to tell how/why they came up with the predictions they did. With a linear model, you can look at which input features contributed the most to the final sum. With a multi-layer neural network, those input features get diced, folded, mixed and blended to the point where that’s no longer possible. For a transformer-based model where each token is generated by an algorithm involving multiple neural networks, it’s not even in the same universe as possible.

The idea of model interpretability is to introduce another algorithm that interprets the weights, outputs, etc. from a complex model to try and explain “why” it made the predictions that it did. There are a lot of different approaches to this, but they all introduce a fundamental risk: Whenever you try to reconstruct why something happened after the fact, it’s hard to tell if you’re learning something useful or just coming up with a good sounding story.

Code Smells

In software engineering, there’s this idea that you’ll sometimes see a pattern that isn’t necessarily bad on its own, but is rather a sign that something else is wrong. It’s awkward or unusual enough that if that’s the only way to solve a problem, there’s probably something bigger, and perhaps harder to identify, that’s the real problem. This is called a “code smell.”

I’m starting to think model interpretability is a code smell, at least in certain situations: It isn’t inherently bad, but it suggests there’s something missing from the information that you’re getting directly from the model. And if this is the case, the risk is that an interpretability layer will just trick you into thinking that it’s providing that information, without actually telling you what you need to know.

The Problem isn’t interpretability

So what if we stopped framing the problem as missing interpretability and instead posed it as a problem of trying to use these models for a purpose, or a process step, that they aren’t suited for.

We see a similar phenomenon with phenotypic screening, where drug candidates are initially identified by their impact on an in vitro assay, rather than directly observing which protein target(s) they bind to. Since the classical drug discovery process starts from identifying drug candidates that bind to a specific protein, it would be natural to want the phenotypic screening results to come with an interpretability tool that identifies the exact protein(s) causing the phenotypic result… but they don’t.

In fact, figuring out the protein target(s) that drugs from phenotypic screens bind to is incredibly difficult, complex and expensive. But that hasn’t stopped plenty of startups and pharma labs from using phenotypic screening. They just have to adjust their process to use the information that they do get from the phenotypic screens. And sometimes that means not knowing the binding protein(s).

Rethinking Processes

To be clear, I am not saying that we should trust the predictions/outputs of foundation models without any further scrutiny or validation. I mean, it should go without saying that any predictions will need to be verified in the lab many times over before any drug makes it to the clinic. But that validation is expensive and time consuming, so we also need a way to validate predictions digitally before we validate them in the lab.

What I’m saying instead is that we shouldn’t try to treat bio foundation models, or any other kind of model, as drop-in replacements for existing pieces of the drug discovery process and fill the gaps with (the illusion of) interpretability. Instead, we should evaluate the kind of information the models are providing and the level of confidence it provides, then rethink the processes around the model to accommodate that level of risk.

I don’t know exactly what that looks like, but I’m confident we can draw from examples like phenotypic screening to figure it out.

Thanks for reading! I help biopharma teams evolve their processes to extend the rigor they demand inside the lab to how they handle data and leverage AI outside the lab. If this is something you’re trying to figure out, visit merelogic.net to learn more.

I’ll also explain why this has led me to start offering a service I call a Data Habits Assessment that evaluates how your team actually handles data (not just how they’re supposed to) and what you can do to help them adopt better habits using the tools you already have. I’m planning to offer this for free to a handful teams while I’m validating the approach. Send an email to data-ops@merelogic.net if you’re interested.

Bio Foundation Models and the Clinical Information Bottleneck

I started this series of posts from the hypothesis that the main cause of the high failure rates for clinical trials, which drive up the cost of drug development, is something I call the clinical information bottleneck. The reason I’m so excited about bio foundation models is they they have a tangible (though not immediate) potential to address this bottleneck by integrating clinical data into early stage discovery.

So that got me writing about how bio foundation models work and how they can fit together at different scales. I’ll get back to that topic soon, but the more I dug into it, the more I kept coming back to the fact that the models are only good as the data they’re trained on.

And the problem, I realized, is that most biopharma teams don’t trust their data.

When you can’t trust your data…

A major blocker, in my experience, to teams trusting their data is that most bench teams have starkly different standards for the level of rigor they demand inside the lab compared to how they handle data outside the lab. In the lab, it’s carefully designed protocols with systems dedicated to documenting and tracking the work (ELNs and LIMS). Outside the lab, it’s manually copying and pasting numbers between spreadsheets saved in arbitrary folders on your laptop.

Sure, there are more fundamental and unavoidable issues with biology data, but any gap in trust means more second guessing results, more extra validation assays, more chasing down dead ends, and generally more looking over your shoulder.

Every crack in the foundation makes you less willing to experiment and explore, and this is a big crack.

MCP servers and AI workflows

The reason bench scientists don’t enforce the same level of rigor outside the lab is that properly handling data has always required a level of technical complexity that is well outside the comfort zone of most bench scientists. At the same time, assay protocols and experiment designs change faster than any informatics/engineering team can keep up. So bench scientists do what they have to, like copying and pasting numbers between spreadsheets.

AI platforms connected to the right tools via MCP servers have potential to address this by allowing bench scientists to handle the technical complexity with the level of flexibility that early discovery workflows require.

I wrote about what this might look like last week.

Data Operations and Habits

But even as the tools get better and become more readily available, there’s still the problem of getting everyone on the team to use them consistently, in a way that allows you to trust your data. And the introduction of new technology like MCP servers only makes this more complicated, at least in the short run,

In most teams, there isn’t an individual who’s officially responsible for training the team on data workflows, gathering feedback on what is or isn’t working, implementing follow-up mechanisms, etc.

My goal with the Data Operations Plans and the Data Habits Assessment is to help teams fill that gap.

Most teams overlook this problem. The lucky ones have someone who thinks about it and tries to fix it, even though it isn’t their job. But I think the industry needs to be more deliberate about addressing it. If you you want to be more deliberate about your own data operations and habits, send me an email at data-ops@merelogic.net .

For decades, the dream in data engineering/informatics circles has been to integrate all the different tools and software that a team uses into a single system that seamlessly and automatically transfers data across systems, replacing manual copy/paste spreadsheet analysis with reliable processes that leave an audit trail. REST APIs were supposed to make this possible, but in practice, integrations always turned out to be too complex and time consuming to make sense outside of larger teams/organizations with highly standardized processes. Most API integrations were just too brittle for the kind of exploratory work that defines early discovery.

Two weeks ago, I wrote about how MCP servers present an opportunity to fix all this by turning the LLM platform (such as Claude Code or one the growing number of alternatives) into a messaging bus that coordinates between all these different tools with significantly more flexibility at a negligible technical cost. Then last week, I posted about some of the issues that could arise from using unreliable, hallucinatory LLMs to handle data that drives incredibly expensive decisions.

After thinking about it for another week, I’ve started forming an idea about how we could address this, and turn the software that exists for biology today into an ecosystem of LLM-connected tools that safely enable the dream. My hypothesis is that the LLM platform in this future can’t be a messaging bus exactly. It has to become an orchestrator that coordinates direct, deterministic interactions between the other components.

In the rest of this post, I want to explain what I mean by this.

The Vision

Imagine, if you will, your experiment has just completed and the data from the last instrument has been written to whatever system it goes into. You type into your LLM a brief description of the analysis you want done, or the question you want to answer and set it off:

First, it uses an MCP connection to your ELN to find the details of how the experiment was done. Then it uses another MCP integration to find the readout data that was just written. It uses a third MCP server to kick off the primary analysis that will boil the gigabytes of data down to a single table. Then it uses a fourth MCP connection to the knowledge graph to look up contextual information about the genes and proteins involved in the experiment. A call to a fifth MCP server merges everything into a form that’s ready for final interpretation.

In practice, this would probably be multiple prompts, with a big gap in the middle while primary analysis is running, but the steps would be the same. The important part is how the LLM coordinates between the different systems via their MCP connections.

Now, you could absolutely automate this kind of workflow without an LLM, using just REST APIs (assuming the systems all have reasonable APIs, which is sometimes true.) However, to make it happen, someone with a very specific set of technical skills would need to predict more or less exactly what the workflow would look like, then spend a few days, if not weeks or months getting it to work. Even if you have someone with that particular set of skills on your team, that’s significantly more work than… typing a vague description of what you want into an LLM and waiting a few minutes.

The Problem

The problem that I started exploring last week is that if all these systems only talk to the LLM through their MCP servers, then all the data that passes between the systems has to be encoded then decoded by the LLM. That’s a problem for a lot of reasons: It’s expensive (how many tokens is your 20GB fastq file?) and slow, and it pretty much guarantees that you’ll have errors.

So the hub-and-spoke model in which the LLM is the messaging bus isn’t going to work. Data should only pass between and through deterministic systems that keep audit trails, etc. LLMs can generate things like code and parameters, sure, but only things that a human could reasonably review.

Instead of pure hub-and-spoke, we need direct, deterministic connections between the spokes, orchestrated by the LLM. And that probably means old fashioned APIs.

APIs Revisited

So sure, it sounds like we’re back to where we started - we still need to connect all our systems to each other with deterministic APIs. But what makes REST APIs brittle is that they’re designed to work with users who can’t translate what they want into technical terms. When an engineer has to do that translation in advance, you’re stuck with whatever they thought the users would need at the beginning.

In other words, the brittle nature of a REST APIs is a requirement of the context in which they’ve always been used, not a technical limitation of deterministic APIs. In a context where users can do that technical translation on the fly, APIs can be designed to be flexible. In fact, flexible API standards such as GraphQL have existed for years, but never had widespread adoption because of this translation issue.

Today, LLMs can do the technical translation for users almost instantly.

Hub and Spokes and APIs

So, here’s what I’m proposing: MCP servers will very soon give us lots of spokes that can be connected to whatever LLM hub you want. Almost every bio software company I’ve talked to in the last few weeks is building one, or has already built one. The rest have it on their roadmap.

Each of these individual spokes can decide on its own how it will communicate with the hub. The companies I’ve talked to are scrambling to figure that out, and that’s fine because LLMs are generally able to work with whatever they need to.

What’s missing is a way for the hub to tell the spokes how to interact with each other: Tell the workflow runner to pull the sample sheet from the ELN. Tell the visualization tool to pull the contextual information from the knowledge graph. And so on.

Doing this for a single pair of systems probably isn’t too bad. But if this dream is going to be a reality for everyone in biopharma, we need to be able to do it for every pair of systems (or close to every.)

In other words, we need the industry to agree to some kind of standard for what these appropriately flexible APIs between them should be, and how the LLMs should communicate instructions for using those connections. (GraphQL is one option, but not the only one.)

On Standards and Adoption

Getting industries to adopt standards like this has always been incredibly difficult and many (most?) attempts at it have failed.

They fail for many reasons, from politics and perverse incentives to the technical cost of adoption. But often, they fail because the customers who could put the most pressure on developers just don’t see the potential value. If no one’s asking for it, why would software developers do it?

This is probably the biggest reason there was never (as far as I know) an attempt to build an interoperability standard for REST APIs in early discovery biopharma: integrations were always so high-cost and low-value that no one ever asked for it.

In this case, however, there’s a real chance that the cost will be low enough and the value clear enough that customers will start asking for this kind of standardization. There will still be the politics, and potentially the perverse incentives, but user demand can do a lot to overcome those.

Either way, that’s a topic for the future. I think I’ve accomplished my goal of explaining why LLMs should become orchestrators instead of messaging busses.

If you have opinions about this and want to talk about what might be involved in making getting the industry to define and adopt a standard like this, I’d love to hear from you - leave a comment or send me an email at jesse@merelogic.net.

Thanks for reading! I help biopharma teams evolve their processes to extend the rigor they demand inside the lab to how they handle data and leverage AI outside the lab. If this is something you’re trying to figure out, visit merelogic.net to learn more.

In this post, I want to explore what we can learn from software engineering, where the community has found safe and effective ways to use LLMs.

Biopharma MCP Tasks

Based on how I’ve seen MCP servers being used in other industries, it seems natural that biopharma teams will want to use them for tasks that are often covered in a Data Operations Plan, such as:

• Reformatting raw data from instrument readouts into a form that’s ready for analysis or interpretation

• Inserting that data into other databases or tools for further analysis/interpretation

• Mapping and standardizing gene names and other entities to standard vocabularies/ontologies

• Looking up auxiliary/contextual information from external sources and combining it with experimental data.

Today, many biopharma teams do the first two of these manually with spreadsheets, and from what I’ve seen, most don’t do the second two at all. But they would like to have them done. And this seems to be consistent with broader industry: AI mostly isn’t replacing people, at least not in highly skilled jobs, so much as doing things that either people have always wanted done, but it was never quite worth the work it would take, or things that people had to do, but really didn’t like doing.

Of course, that doesn’t work if you can’t trust the results.

Verifiable results

One of the reasons that software engineers have been able to use LLMs to write code is that there are easy ways to tell whether or not it did the job correctly. Compilers, linters and unit tests are all designed to tell you (or the LLM) if the code was written correctly. So the LLM can write code that’s 98% correct, check for errors, fix whatever mistakes it made, and repeat.

Of course, this is also how human coders work, which is why compilers, linters and unit tests existed long before LLMs. In fact, human coders are a lot less than 98% accurate, even the really good ones. What makes them better than LLMs (even the next model that OpenAI or Anthropic swears is going to be too dangerous to release) is that they know where to look for errors, how much test coverage is good enough, what’s the right amount of technical debt, etc.

In other words, what makes software engineering “safe” is that the LLMs have mechanisms to verify that they did the right thing and human experts have ways to verify that these mechanisms are sufficient. (Maybe these mechanisms are the difference between vibe coding and AI-enabled software engineering...)

Unverifiable results

The problem with the tasks I listed above is that there aren’t separate mechanisms to verify they were done correctly. Or, at least, there aren’t established, easy to implement, mechanisms for this.

And yet, most biopharma teams are fine having humans do them manually, without any verifications. Humans who are known to make mistakes. And in fact, anyone who’s been in this business for more than a few years has at least one story of a value pasted into the wrong cell in a spreadsheet, an analysis run on the wrong file, etc. proving to be a very expensive mistake.

This makes using AI for data processing and analysis more like self driving cars than Claude Code. But unlike with self driving cars, where we have to rely on the computers eventually being safer than humans, biopharma has options for creating verification mechanisms. We just haven’t invested as much as we should in them, whether it’s LLMs or humans whose work is being verified. (Which gets back to Data Operations Plans...)

More code-like, less car-like

If you give a scientist a spreadsheet of raw data and a spreadsheet that an LLM has generated from it in a new format, the scientist will not be able to tell you if the LLM did it correctly. But if the LLM generates a mapping from one format to the other and applies the mapping using a deterministic algorithm, a (properly trained) scientist should be able to look at the mapping config and tell if it was correct. The LLM could even generate small test datasets to apply the transformation to, for the user can verify.

Tools for deterministically mapping between data formats have existed for a long time, but adoption has been fairly low in biopharma because defining these mappings is often more work than just copying and pasting columns in Excel. However, using an LLM to generate the mapping is even easier, and less error prone, and leaves more of an audit trail and… The point is that LLMs could actually make these kinds of tasks MORE accurate by making it easier to the tools that we should’ve been using all along.

This was the idea behind Sphinx, for example, before it was acquired by Benchling, which is now presumably implementing a lot of these ideas. And similar capabilities have been added to tools like Kaleidoscope, SciSpot, Sapio and plenty of others.

It will be interesting to see how they make these capabilities available through the MCP servers that they’re no doubt building or have already built. (And I’m partnering with Nishant Jha from Nitro Bio to help companies like this figure it out... jesse@merelogic.net if you want to chat about it.)

However this evolves, I think we’ll see better options in the coming years for enabling biopharma teams to safely and confidently handle data, so they can better trust the results, and waste less time trying to verify results that were actually just a copy/paste error.

Thanks for reading! I help biopharma teams evolve their processes to extend the rigor they demand inside the lab to how they handle data and leverage AI outside the lab. If this is something you’re trying to figure out, visit merelogic.net to learn more.

Within the next few years, every software/SaaS for bio will be expected to have an MCP server, and the quality of that MCP will be an increasingly important factor in buying decisions. So to help software-for-bio companies be ready, I’ve started partnering with Nishant Jha from Nitro Bio to help developers design MCP servers that enable their users’ most important workflows, while minimizing the risk of hallucinations and other reliabilty issues.

To help kick off this partnership, this week’s post will explain what MCP servers are and speculate about what MCP adoption might look like for the future of biopharma. If you want to chat with Nishant and me about an MCP server you’re building (or want to build), send me an email at jesse@merelogic.net.

I’m also building an MCP server for the Biopharma AI Landscape and looking for beta testers. Send me an email if you want to give it a try.

Tools and Tool Calls

Modern LLM-based AI systems use a mechanism called tool calls to extend the capabilities of the system. For example, LLMs are notoriously bad at doing math or following precise algorithms, but giving them the ability to call a Python interpreter means they just need to write the code, something that they are good at.

To use a tool, the LLM generates parameters, for example the code to run. The system that manages the LLM reads the parameters from the LLM’s response, uses them to run the appropriate tool, then passes the results into the next call to the LLM, along with a transcript of what the LLM has done so far. The LLM can then make more tool calls based on the results, and repeat the cycle until it decides it’s done.

LLM-based systems have had built-in tool calls for a while, to do things like searching the web. The MCP protocol allows users to give their LLM additional tools by connecting it with MCP servers. It’s a similar idea to a how REST APIs allow programs to interact with each other, but with a protocol built for how LLMs “think” about and use tools.

The AI-powered Messaging Bus

On it’s face, the main benefit of MCP servers is that they can make your LLM smarter by adding functionality. But the pattern I’m seeing more often (mostly outside biopharma) is that they’re allowing the LLM to become a sort of messaging bus between MCP servers - pulling information from one service and using it to update another.

For example, imagine if Claude could read an entry from your ELN, standardize the gene names based on a gene ontology, find the readout in your file system, then kick off an analysis run based on the protocol in the ELN.

That’s the kind of thing that you could theoretically do with a few REST APIs and a whole lot of code, but in practice both the APIs and the code end up being too brittle. There are so many different use cases you would need to support, it just isn’t worth writing scripts for every corner case (even with vibe coding).

Well, it turns out LLMs are quite flexible and can handle completely novel use cases with just a few carefully worded instructions.

Sure, coordinating an ELN with a bioinformatics workflow is more complicated than copying text from Notion to Slack, but LLMs are getting better at correctly handling increasingly complex tasks. Similar workflows in other domains are possible today, and it’s only a matter of time before they become possible, if not the standard, in biopharma. But the tools will need to be designed to minimize the kinds of mistakes that LLMs are prone to make.

Local and External MCPs

There are two ways that you can attach an MCP server to an LLM system: locally or externally.

A local MCP server runs on the same machine that the LLM system is running on. For example, if you’re using Claude Code (which runs on your own computer) and you configure it with a local MCP server, it will start the server for you and send it requests using your computer’s networking systems in such a way that all messages stay on your computer. With this approach, you don’t have to worry about security or privacy. In fact, you don’t even need to have a password on the MCP server. Local servers can also read and write files on your computer.

An external MCP server runs somewhere else on the internet. Your LLM system connects to it through the actual network rather than just pretending to make network calls like local servers. This means you don’t have to install anything on your computer and you can connect to external resources (like Notion or Slack or your ELN), but you have to deal with authentication, security, privacy, etc.

There’s also a third, sort of hybrid option, which is a local server that wraps an external REST API. The LLM system makes internal calls to your local server, which then makes actual network calls to an external REST API, then reformats the results before passing them back to the LLM.

There are already quite a few open source MCP servers for bio that use that last option. For example, BioMCP and OpenPharma run locally and provide access to different data sources, mostly by calling external REST APIs. There are fewer that are purely local, such as ChatSpatial which enables your LLM to run spatial omics analysis tools on your computer.

Purely external MCP servers are more likely to be developed by existing software/SaaS companies as a new way for users to access their software. Outside biotech, companies like Slack and Notion have already built this. Inside biotech, there are at least a few companies who have built their own MCP server, but most are still in beta.

It’s technically possible to build your own hybrid MCP server around your current ELN or any other software/SaaS. But you’ll be limited by the functionality of their REST API (which is a serious limitation for a lot of software for biopharma) and you might end up throwing it away if they eventually create their own MCP.

So in the long run, the best outcome would be for existing software/SaaS companies to build their own, official MCP servers. But given how slowly the industry has adopted REST APIs, I’m a more than a little worried.

Hype vs Reality

I know it can be hard to tell AI hype from reality, but this isn’t some vague promise, predicated on ChatGPT becoming sentient in the next six months. MCP servers allow the LLMs that we already have today to solve real problems that we’ve had for decades, namely connecting all the different pieces of software that should work together, but don’t.

If you’re making software today, this is something you should be paying attention to. And if you want to talk to Nishant and me about how to stay ahead of it, send me an email at jesse@merelogic.net.

The second half of this post will explore why it will take so long to tell if we’ve fixed drug discovery, but first it’s worth stating why this is important:

We’re currently in the midst of a new wave of tech folks entering biopharma, expecting to quickly demonstrate how amazing their technology is. (I entered the field in the previous wave, which ended with the post-pandemic biotech winter around 2022.) This new wave, driven by LLM-powered AI, is potentially much bigger (at least in dollar terms) but it’s still unlikely to last long enough to see outcomes that are decades away.

The frustrating thing is that it’s possible someone already figured out how to fix drug discovery in the last wave, or the wave before that, and we haven’t noticed yet. Or more likely, they ran out of funding and scrapped the approach, so we’ll never know.

It’s unclear to me what’s stopping the same thing from happening this time.

Error Bars

The reason it takes so long to tell if you’ve made a difference is that the only improvement in drug development that really matters would be increasing clinical success rates. You don’t have to increase them by much, even. Just raising the current rate of 10% to a still-measly 20% would cut the cost of drug discovery in half.

However, to definitively say that you’ve done this, you would need to run enough clinical trials to know that you didn’t just get lucky. Whatever kind of error bars you use, that’s a lot of drugs that need to go through clinical trials, each taking 10-15 years from early discovery. Even if many of those trials are happening in parallel, this would take decades.

And sure, we could focus on other metrics like the cost and time of the parts of drug discovery that happen before clinical trials. But those metrics don’t work the way you might think. Because the vast majority of the time and money it takes to bring a drug to market is spent during and after the clinic, reducing the cost of the first, relatively cheap part doesn’t end up mattering that much.

In fact, if you speed up early discovery by introducing a novel and experimental (read: risky) approach, there’s a decent chance you’re just trading that early time and money for a lower success rate that will increase the cost overall. Any reasonable pharma executive would rather spend twice as much time and money on earlier discovery if it would guarantee them a better chance of success in the clinic.

So, are we doomed?

I don’t know what the answer to this problem is. Luckily, there are a lot of smart investors, founders, etc. who understand this better than I do, and are working to fix drug discovery with their eyes wide open. Of course, there are also plenty of people with unreasonable amounts of money, or access to VCs with that money, who don’t know what they don’t know, but are investing anyway.

Every time a wave of tech folks enter biotech and learn these lessons the hard way (I was one of them, not too long ago), I think it shifts the field towards the right balance of tech exuberance and bio reality. The question is whether we’ll ever find a balance that will give the field the patience to see if it’s working.

Thanks for reading! I help biopharma teams design, implement and maintain Data Operations Plans that extend the care and consistency they enforce inside the lab to how they handle data outside the lab. To learn more, send me an email at jesse@merelogic.net.

There are two directions to it, which I’ll discuss in turn:

1. Information from the discovery/pre-clinical phase of a drug program is not very predictive of what will happen in the clinical phase.

2. Information from the clinical phases of past drug programs is generally not very relevant to the discovery/pre-clinical phase of new drug programs.

These two sides of the bottleneck are clearly related, since early discovery would probably be more predictive if it could take better advantage of past clinical trial results. And, in fact, the way to solve the first direction is probably to solve the second direction. But let’s first look at each one individually.

The Pre-clinical → Clinical Direction

This is the more important one, since the main driver of clinical costs is high failure rates. Only around 1 in 10 drug candidates makes it through clinical trials, which means that to get one drug to market, a pharma company would expect to have to run clinical trials on 10 candidates. That means the cost of a successful clinical trial is effectively ten times the cost of running any single trial. If you could even just make it a 1 out of 9, you’d effectively reduce the cost by 10%. Make it 1 in 5 and you’ve cut the cost in half.

In other words, lower failure rates will lower costs faster than pretty much anything you can do to make individual trials cheaper.

It’s also important to note that early discovery/preclinical work is much less expensive than clinical. So if there were more experiments that teams could run in vitro or even in vivo to improve their clinical success rate, they would absolutely be doing that already.

In other words, this is a fundamental limitation of the tools we have available for early discovery, not a matter of bad decision making.

The Clinical → Pre-Clinical Direction

The nature of pre-clinical (in vitro and in vivo) vs clinical data is the ultimate quality vs quantity trade-off.

In early discovery, you can quickly and inexpensively (at least relative to clinical trials) generate data on millions of drug candidates. That’s orders of magnitude more drugs than have been through clinical trials in the entire history of modern drug discovery.

If you narrow it down to clinical trial data on the disease you’re working on, you might have a few dozen related clinical trials, if you’re lucky. Then narrow it to the target you’re looking at and you might still have a few if it isn’t a novel target. But then, thanks to the patent system you probably don’t want to screen structures or sequences anywhere close to this small handful of remaining data points.

So even if you do have relevant clinical trial data (which you often don’t) and you could train a reasonable model on that small handful of data points (which you probably can’t), all the points that you would want predictions about would be so far from the training data that predictions would be completely untrustworthy.

Of course, there’s also data from patient samples collected during treatment rather than from clinical trials. This data can be useful for learning about human biology in general, but it generally can’t be applied directly to predicting clinical success of novel drug candidates.

Foundation Models to the Rescue?

So the situation is really really bad. But I don’t think it’s hopeless.

To understand why, I want to further break down the pre-clinical → clinical direction into two pieces. In other words, there are two reasons why in vitro assays are not predictive of clinical outcomes:

1. Cells in in vitro assays react fundamentally differently from how they react in the body, so there is a fundamental limit on what can be extrapolated from them.

2. We just don’t know (yet) how to interpret all the information that could in principle be extrapolated into clinically relevant data.

We can’t do anything about the first one, but it’s probably less of an issue than you might think. Even if cells react differently in vitro, there’s still information in how they react. You just have to know what to look for.

On the other hand, if you look at how we collect, analyze and interpret data today, it’s clear that part two is a big factor. Most analysis looks for relatively simple signals based on a simplified, mechanistic understanding of the in vitro biology.

However, computational biologists have been introducing AI/ML models that replace these intermediate mechanistic goals with learned phenotypes/etc. and they usually find signal that wasn’t visible before.

Today, we’re seeing increasingly powerful bio foundation models that can integrate multiple kinds of data, potentially including readouts from in vitro, in vivo and in human samples to extract even more subtle signals. And I think we’ll see more of these data sources becoming assays that are deliberately designed to maximize the clinically relevant signal that a foundation model or a purpose-built AI/ML model can extract. (Addressing both factors at once.)

This is why I’m optimistic that AI will be able to open up the clinical information bottleneck. It won’t be easy, and it won’t happen quickly. But I think it’s possible, and that there’s a much clearer path to get there than there was even a few years ago.

Thanks for reading! I help biopharma teams adopt consistent, reliable data handling practices so they can trust every conclusion. Check out merelogic.net to learn more.

In this post, I’ll describe what this model does, explain what it has to do with the clinical information bottleneck, then give a high-level overview of how the model works.

Paired assays

NOETIK’s new model understands two types of data:

1. Routinely collected histology sample images that use a staining method called H&E (Hematoxylin and Eosin). You take a biopsy sample, put a thin slice of it onto a slide, stain it, then run it through a digital microscope to get an image. It’s quick and relatively inexpensive, and basically any patient with a solid tumor in the last few decades has gotten at least one of them.

2. Spatial transcriptomics data from these same thin tumor slices. This time, instead of the digital microscope, there’s a long, complex and expensive process involving a sequencer, that ends up with the two dimensional coordinates of each RNA molecule in a large sample of the RNA from the slice. That’s obviously much more useful data, but much more expensive to collect, so there isn’t much of it.

What NOETIK has shown is that you can use TARIO-2 to take an H&E image, split it up into small squares, and predict the gene expression levels in each square. Not quite the same as the two-dimensional coordinates of each molecule, but close enough for all intents and purposes.

This type of prediction doesn’t isn’t an existing step in you’re typical drug discovery pipeline, but if you’re building a model or doing some other sort of analysis using spatial transcriptomics data, this gives you a vastly larger amount of (at least slightly lower quality) data to do it with.

The Clinical Information Bottleneck

I originally got excited about this result because it’s a great example of how foundation models can make any old data you have laying around more valuable than you think (particularly if it’s properly organized based on your data operations plan). But then I started thinking about the information bottleneck between the early discovery and clinical phases that I wrote about back in September.

The idea of the bottleneck is that you could run every available in vitro and in vivo assay on a pre-clinical drug candidate, spend billions running every conceivable experiment in the lab before filing your IND, and your drug would still have only a 10% chance of passing clinical trials and making it to market. So from a clinical standpoint, in vitro and even in vivo data isn’t quite useless, but it’s unnervingly close to it.

Meanwhile, in-human clinical data is very sparse. If you’re looking at a new target, or in a new area of chemical space, there will be little if any clinical data that’s close enough to the space you’re exploring. Little enough that it’s usually not even worth looking at.

But what if you could predict clinical results from a paired in vitro assay? In other words, if you could take a readout that is commonly collected in clinical trials, or just clinical practice, then run an in vitro assay that is appropriately paired with that clinical data, you could potentially train a model that predicts the clinical outcome directly from the in vitro assay. This is in contrast to a standard in vitro readout where you decide what a hit looks like based on some combination of your mechanistic understanding of the assay, a positive control, and vibes.

Pairing a clinical assay with an in vitro assay is a big step from what TARIO-2 does, since both H&E and spatial transcriptomics come from clinical tumor samples. But NOETIK has also shown that TARIO-2 can use H&E images from in vivo mouse samples to predict the transcriptomic profiles of human samples under the same perturbation, which is one step closer to in vitro. And previously I wrote about a company called Axiom that paired an in vitro assay with clinical data to predict liver toxicity better than animal models. So maybe it’s not completely crazy…?

Two-dimensional Transformers FTW

TARIO-2 is a transformer model that takes as input a spatial transcriptomics readout paired with an H&E image of the same sample. It’s goal is output the same thing a predicted spatial readout and H&E image that match the original. Not that exciting on its own, but it gets interesting when you mask out part of the data in the inputs. The model is trained to still predict the full original data, filling in gaps based on the parts that you didn’t mask out.

What the folks at NOETIK discovered is that if you mask out all the transcriptomics data, and just give it the H&E image, it can fairly accurately reproduce the original transcriptomics. Or more imporantly, if you only have the H&E image, and you pretend the transcriptomics is just masked out, the model can predict what the transcriptomics data would’ve looked like.

The model is based on a transformer, so to explain how it works, I’m going to start where my post on bio foundation models left off.

The first thing we need to do is define our tokens. For this, we’ll first cut the image into a grid of smaller blocks. For each block, we’ll define two tokens: One for that portion of the image, and one for the gene expression in that portion of the sample. We’ll annotate the tokens by adding vectors to indicate both what kind of token they are and where they sit in the coordinate grid.

Once the tokens are embedded, we run the transformer to update their embeddings based on the attention algorithm. Then we’ll run the final embeddings through another set of neural layers to map them back to either an image or a set of expression levels.

To mask out data, you just replace the appropriate tokens with zero vectors, then let the attention algorithm pull them to where the model thinks they would’ve been if they weren’t masked. The final neural layers will then map them to the predicted image and expression levels. If you do this with all the transcriptomics tokens set to zero, this will recover the predicted transcriptomics values based on the embeddings of the H&E tokens.

Conclusion

There are a lot of interesting takeways from NOETIK’s work on TARIO-2, but for me the one that stands out is this: They’ve shown that the information in an uncommon, expensive spatial transcriptomics assay can also be found in a cheap, ubiquitous imaging assay, and they’ve demonstrated a way to extract this information. If others can take this general idea and run with it, who knows what they may be able to accomplish.

Thanks for reading! I help biopharma teams integrate foundation models into their discovery and development pipelines. Check out merelogic.net to learn more.

Well, this paper suggests it is, so that’s what I’m going to write about this week.

*** But first, a quick reminder to check out the class for biologists who want to start using bio foundation models that I’m co-developing with Scriptome.AI. Participants will get hands-on experience running a variety of bio foundation models. ***

The first author on this paper, Yuge Ji, is the founder of Reflector Bio, one of the Virtual Cell Model developers profiled in my Buyers Guide to Virtual Cell Models. Reflector is built around the model in this paper, which doesn’t quite fit the framework for transformer-based virtual cell models that I wrote about a few weeks ago. But it makes largely the same kinds of predictions as a virtual cell model, so I think it counts. Here’s how it works:

Inputs and Outputs

The model predicts outcomes of different kinds of in vitro perturbational experiments. Each input to the model consists of three parts:

1. An environment token indicating the cell line that the experiment was run in.

2. One or more treatment tokens indicating what was done to the cells. In the paper, these can either be small molecules or genes for CRISPR knock-downs, but the approach could be extended to other types.

3. A token indicating the type of readout/phenotype that was measured.

The output is a set of vectors that capture the readout values from the different types of readouts/assays. The paper treats the output as a single vector that you get by concatenating all the readout vectors.

The model is based on a transformer. You can read about how they work in my post from back in March. This particular transformer starts with the three from the input, and adds a fourth class token that summarizes the other three. The output/prediction comes from running the transformer algorithm to re-embedd all the tokens, then passing the final embedding of the class token through additional neural net layers to map it to the predicted readout.

This approach sits one level of abstraction above typical virtual cell models, since instead of an initial token for each gene, the environment token encapsulates all the initial expression levels. Similarly, the output is derived from a single token (the class token) rather than the final embeddings of the per-gene tokens.

Tokens and embeddings

What makes this approach really interesting is that all three types of input tokens are embedded in the same embedding space, even though they represent very different kinds of concepts.

The environment and treatment tokens do this with a two step process: First, each token is embedded in a type-specific intermediate space. Second, each type-specific space is mapped into the common embedding space. That way, each intermediate space can have an arbitrary number of dimensions, based on the type of token.

Cell type tokens are first embedded in a space with one vector for each gene, based on its typical expression level for the cell type. Small molecules are embedded in a space using standard structure-based embeddings found in RDKIT. Genes for CRISPR knock-downs are embedded based on a combination their co-expression matrix and their coding sequence.

Both the intermediate, type-specific embeddings and the maps into the common space are learned as part of training the overall model.

The phenotype/assay type token doesn’t use a two-step process because there isn’t an intermediary space that makes sense for it. Instead, it’s a direct embedding, learned as part of overall training.

Using the Model

Once you’ve trained this model on all your experimental data, you can make new predictions by swapping out one or more of the three types of input tokens from an existing experiment:

• Swap out the environment/cell line token with all the other known cell lines to predict how the treatment will affect other tissues.

• Swap out the phenotype/assay type token to predict what other readouts for the same experiment would’ve looked like.

• Swap out the treatment token to do virtual screening trained on all your past assays, along with public data across multiple readout types.

Because this model, like all models, will be most accurate closer to the training data, it may not be a great idea to swap out more than one token at a time. (And for treatments, you probably don’t want to get too far away from known molecular structures…) But the paper shows promising results for swapping out each single type of token.

Conclusion

What I like about this approach is that it’s relatively simple but demonstrates real potential based on just publicly available data. With a few more iterations of the model architecture and a bunch of proprietary data (like, say, what Lily Tune Labs is collecting) this could be the start of something much bigger.

So maybe a few years from now, it won’t sound so crazy to say that all those billions of dollars of data that biopharma teams generate each year, then hide away on hard drives and disorganized shared drives, could actually train the foundation models that drive the next wave of drug discovery.

Thanks for reading! I help biopharma teams integrate foundation models into their discovery and development pipelines. Check out merelogic.net to learn more.

*** But first, if you’re worried about bias in your own data, it might be time to define a formal Data Operations Plan. Check out my guide here or send me an email to get started. ***

Predicting cell surface markers

First, the science: Every cell in your body has a bunch of peptides (small fragments of proteins) sticking out of its surface. These come from proteins inside the cell that get broken up into pieces. Some of the pieces get transported to the cell wall and pushed through, while others don’t. Your immune system uses these protein fragments to tell the difference between healthy human cells and foreign cells, as well as to detect cancer cells. (Note: I am not a biologist.)

Cancer cells are defined by mutations that create protein variants that don’t exist in healthy cells. If you can figure out which fragments of these proteins will get pushed onto the surface of the cell (and which don’t appear on healthy cells), you can try to develop a drug that attaches to those peptides and kills any cells where they appear. This is how immuno-oncology works.

The goal, then, is to train a model to take a sequence for a protein variant and predicts which fragments of it will appear on the surface of the cell.

Measuring cell surface markers

To build a model that predicts cell surface markers, you need training data, which means you need a way to identify the surface peptides. You’re going to have to trust me that there’s a process to get them off the surface of the cell and into a solution because I’m not qualified to explain it. (By which I mean I don’t understand it - again, not a biologist.)

Once that’s done, a mass spectrometer (mass spec) can be used to identify the proteins in the solution. This breaks up each peptide into a bunch of smaller pieces, then identifies the molecular weight of each piece. In the readout from the mass spec, each piece shows up as a peak along the scale of masses. Each protein shows up as a collection of peaks depending on its sequence.

In the mass spec readout, these peaks are all overlayed against each other, and the purpose of mass spec analysis is to deconvolute them: figure out what distribution of proteins would’ve created the overlayed collection of peaks that appear in the data. It’s possible to do this completely from scratch, but it’s much easier (and more common) to start with a “candidate list” of peptides that you expect to find. The mass spec will only look for the peptides on this candidate list.

The problem is what happens when you both use predictive models to generate the candidate list, then use the resulting data to train and benchmark more models.

Compounding Bias

You may see where this is going, but let’s follow it through, step by step:

First, we generate Dataset A, a list of peptides on the surfaces of different sample cells, without using a candidate peptide list. Then we train and evaluate Model A on this data.

So far so good.

Next, we generate more experimental data, Dataset B, but to make the mass spec analysis easier, we use the top peptides predicted by Model A as the candidate list. According to the Deepflare paper, we would typically use the top 2% of predictions from Model A. That means any peptide that isn’t on the candidate list won’t show up in our analysis, even if it was physically present in the sample.

We’ll then train and evaluate Model B on Dataset A and Dataset B together.

The problem, of course, is that Dataset B doesn’t include any peptides that were outside the top 2% of the predictions from Model B. In other words, if Model A was biased against certain types of sequences, then Dataset B will also be biased against them. So Model B will be even more biased against them then Model A was.

Moreover, because we’re evaluating/benchmarking Model B against a dataset with this bias, we won’t even notice it.

In fact, if you were to benchmark Model A again, based on the Dataset B (with or without Dataset A), Model A would look even better, since you would find more true positives while finding only a tiny fraction of the new false negatives.

Now repeat this over and over again: The models become increasingly biased while the benchmark values look better and better.

The Immune Epitope Database

The Deepflare paper notes that most models for this problem are trained on and benchmarked against mass spec data in the Immune Epitope Database (IEDB). They carefully reviewed the methods of 37 of the studies that produced this data and found that only around 44% of the data could be verified to use unbiased measurements, while the rest was analyzed using previously trained models.

They also ran simulations, using the clean portion of the data to verify that using candidate lists pulled from earlier models does indeed bias later models. (Not that anyone should doubt that…)

They argue that the steady increase of reported accuracy of previously defined models could potentially be a result of this compounding bias rather than actual improvements in accuracy. And, of course, they introduce their own model called DeepMHCflare, trained on only the “clean” portion of IEDB data and validated its results using an in vivo study of a cancer vaccine.

Subtle Bias

This particular cycle of compounding bias is specific to how mass spec data is analyzed. But if you look at it alongside the bias in small molecule binding datasets I wrote about a few weeks ago, it’s clear that bias in general can sneak into biological data in lots of different and subtle ways.

Both these examples could’ve easily gone unnoticed for years or decades, silently poisoning multi-million dollar drug discovery programs. And we might never have noticed the programs that failed and the drug candidates that were passed over as a result.

The only way to identify and fight this kind of bias is to understand both the technical and scientific aspects of data collection, and to create an environment where you can explore the data with as little friction as possible. Otherwise, it’s easy to be so focused on just getting results that you never step back to see the bigger picture.

Thanks for reading! I help biopharma teams integrate foundation models into their discovery and development pipelines. Check out merelogic.net to learn more.

*** But first, if you haven’t already, check out this upcoming class for biologists who want to start using bio foundation models that I’m co-developing with Scriptome.AI. This will be an eight week hybrid in-person/online class in Boston/Cambridge where participants will get hands-on experience running a variety of bio foundation models.***

Unspoken assumptions are often wrong

Whenever a lab experiment completes and it’s time to gather up all the data (instrument readouts) and metadata (ELN notes, plate maps, etc.) there’s an endless list of options for how one could do this. Some of these decisions are really important, like where you put the plate map so you can find it later. Others, like whether or not to capitalize column names, are arbitrary.

Each bench scientist, if left to their own devices, will make different decisions about both the important decisions and the arbitrary ones, which is a problem when even arbitrary decisions need be made consistently.

But beyond just consistency, there are also important requirements from data scientists and computation biologists that go unstated because both teams just assume they’re so obvious that the other team must be on the same page… even though they often aren’t.

For example, I’ve known bench scientists who drafted their lab notes in word docs and only copy/pasted them into the ELN once they were perfect, because the ELN was supposed to be the golden record. And I’ve seen computational biologists shoot steam out their ears hearing this because they want that information to be in the ELN as soon as physically possible.

These are organizational and operational problems that can’t be fixed by any amount of AI or other tech.

No one’s responsibility

Someone just needs to make these decisions and communicate them to the rest of the team. However, in most labs, particularly early stage biotech startups, there isn’t a person who can do that.

Individual bench scientists don’t feel empowered to tell the rest of the team how to do their work, and don’t understand the downstream requirements well enough, anyway.

Data scientists and computational biologists don’t think they can tell the bench team how to do their jobs, and they often don’t have the bandwidth to understand the lab processes, document what they need, and advocate for those changes.

Anyone in leadership who’s accountable for both bench and digital teams doesn’t want to micro-manage these processes, even if they had time to get into the weeds of metadata handoffs (which they don’t).

At larger organizations, someone like a lab informatics engineer would be responsible for defining these processes. But smaller biotech startups generally can’t afford a dedicated informatics engineer. And even at larger organizations that do have them, they’re often focused on core, high-throughput assays rather than the long tail of infrequent protocols.

Communicating the problem

To solve this problem, I recently started creating Data Operations Plans for biopharma labs. (I had been doing projects like this a few years ago, then moved on to other kinds of work. But now that I’m seeing how important this is for AI adoption, I’m back to it.)

Since the pain of inconsistent data collection practices is often felt most acutely by the computational biologists and bench scientists who aren’t the ones signing the contracts, I wanted to give them a resource to help communicate to leadership why a project like this is necessary. So the first half of my guide to Data Operations Plans for Early Discovery Labs is all about why building one of these plans is worth the up-front cost.

My goal is to give the folks feeling the pain the arguments to advocate for the changes that will address these problems. I just rewrote it to be (hopefully) more compelling, and added a bunch of graphics/figures to make it easier to read. I want this to be something you can share with your boss if you’re feeling the pain.

Building a (financially) viable solution

But I also recognize that budgets are extremely tight these days, particularly for early stage startups. Every cent needs to be carefully spent. That’s why I only build Data Operations Plans as a fixed-price service with a guaranteed outcome and a clearly defined schedule. Because my clients know exactly how much the project will cost them, regardless of the number of hours on my end, they don’t have to worry about unexpected budget overruns.

The price may still be high for some startups, but it’s a fraction of what it would cost to hire a full time lab informatics engineer, and an even smaller fraction of what they’re spending to generate data. Think of a Data Operations Plan as an insurance policy on that data.

As VCs increasingly recognize how bio foundation models are increasing the importance of data as an asset that drives biotech valuations, they’re going to look for companies that have a concrete data strategy. Having a Data Operations Plan is the first step in building that story. So I’m confident that the startups that are serious about building a moat with their data will find a way to fit it into their budget.

Thanks for reading! I help biopharma teams integrate foundation models into their discovery and development pipelines. Check out merelogic.net to learn more.