Building a Frontier Lab for Chemistry: A Conversation With Hatem Helal

by Corin Wagen · Nov 6, 2026

Yesterday, Potential Sciences emerged from stealth, announcing support from the UK Sovereign AI fund and TwinPath Ventures to build, in their words, a frontier lab for chemistry. You can read the company's announcement here, and the launch was also covered by Joel Khalili at Wired.

I've known Hatem Helal, Potential's founder and CEO, for a few years. Now that Potential's public, I reached out to discuss what he's building, what Potential will do differently than other scientific frontier labs, and what they're hoping to achieve next.

Corin Wagen: Today I'm speaking with Hatem Helal, who is the CEO and founder of Potential Sciences, which we'll hear more about in a second. Previously, Hatem was at Recursion and Graphcore where he was working on a variety of projects in AI, simulation, hardware and generally scientific infrastructure. Previously to that, he did a PhD on electronic-structure theory with a particular focus on fast and low-parameter implicit-solvent models. Hatem, my first question is: can you tell us about Potential? Who are you, what are you trying to do, where are you at, and what should we be excited about?

Hatem Helal: The shortest version of it is: we're a frontier lab for chemistry. That means many things to many different people. But what I think is really exciting is that we're combining actual data acquisition at a really high level of theory—so coupled cluster–level theory—with atomistic foundation models that are universal. And we're expecting to be able to reuse these across many of the applications that we've seen MLIPs progress across in the most recent years.

From my background, we're really excited about specific problems in pharmaceuticals, particularly lead optimization, but of course physics is physics wherever you look. One thing that I see as genuinely overlooked in our space is the role of data, particularly simulated data, and for me it's been really exciting to focus on how we can acquire the best quality computational data and then use that to bootstrap better models that do a better job of generalizing and predicting phenomena that would be impossible to observe using traditional tools.

Corin: I want to dig into the applications a little bit later. Let's talk about simulated data: specifically the modality you guys are targeting, which as I understand is GPU-accelerated coupled-cluster theory and related methods, but also generally many forms of simulated data. What's the case for these as opposed to experimental data? Something more akin to what Radical or Periodic or Lila seem to be targeting with their platforms, among others.

Hatem: It's a great question and for me it's not an either/or. We should be doing both.

We should also recognize that the electronic-structure community is not a very large scientific subgroup, and there just aren't that many people who've had the meandering career path I've had. I've been fortunate to see all these different perspectives of "yes you can go and just build an electronic structure code." Even if they've worked in the field, not everyone believes that you can go and optimize for hardware and have dramatic success with acceleration, using the same kind of performance engineering that has brought us all the great modern LLM/AI coding tools that we're all benefiting from now.

The evidence is the classic one in science: we're standing on the shoulders of giants quite literally. It goes back to Dirac claiming that the theory is basically complete: we just need tools that allow us to solve these equations in a way that's tractable, and our interpretation of that is bringing accurate surrogates at scale and with extremely high throughput. One of our bets is that you can learn from small molecules at the coupled-cluster level and extrapolate to bulk properties. There's a richer and deeper theory there, and it's part of the sort of linear scaling that the electronic structure community has been looking at for a while: how local can you be while still capturing these subtle changes in electron correlation?

Corin: Is there an implicit claim that the characteristic length scale of the phenomena that we care about in chemistry is relatively small? And that we should be able to get the properties at the mesoscale and beyond that we care about purely from emergent behavior on top of nanoscale models? Would you characterize that as a non-consensus belief, or do you think that's just plainly obvious?

Hatem: I think it depends on the application area. This is another reason why chemical lead optimization is a great problem for us. Physiological conditions are very different from trying to understand defects in solids, based on the length scales that these are interacting over. I would love to scale electronic structure to be able to better model device physics and better explain the failure modes of materials in a way that stands up to all the diverse needs of the community.

Our initial bet is that we can go quite far with just this quite local view with small molecules that are enumerated across diverse chemistries and diverse structures, and from that view extrapolate to really interesting phenomena at the structural biology level.

Corin: How do you think about the work Potential is doing through a classic "basic research"/"applied research"/"engineering" trilemma? Where do you see the biggest challenges, and where do you think that your focus in the next several years will be?

Hatem: Yeah, that's a really good question. We're somewhere between applied research and engineering practice. How do you co-design the algorithms so that they make the most out of modern hardware, and how do you evolve them as quickly as possible? That's actually a software engineering question more than anything.

Corin: Absolutely.

Hatem: How do you move fast and make the codes run really fast and as efficiently as possible, so that you're getting the most science per watt that you're burning? For us, that's perhaps less interesting as a deep research task that has seen loads of study across many academic institutions.

I think where we'll have a lot of success is that there are great results in the electronic-structure community that have yet to have the kind of industry impact that everyone wants to see. We want to be one of the levers for that translation from "hey, this is a cool paper with an interesting result that's been experimentally verified" to "we're using this system at scale to help us solve inverse problems" like designing molecules that do a better job of selectively targeting a protein and not potentially wreaking havoc on other biological mechanisms.

Corin: You touched on the full-stack nature of your work. There is this valley of death where there's really interesting papers, but making them practical and deploying them and embedding them is hard and requires a lot of work not only at the top level—actually building on top of these algorithms—but also all the way down the stack, making them fast and reliable and properly engineered.

You have a background in hardware. What do you think about the modern hardware stack for science and how it's changing? Do you think there's a role for beyond-GPU-accelerated computing like ASICs, FPGAs, and other sorts of hardware modalities?

Hatem: Yeah. I don't have a list, but one of the most influential papers in my working life is "The Hardware Lottery" by Sarah Hooker. It's the bread-and-butter when you join a company like Graphcore working on an ASIC that is trying to find a niche within the ML community. We tend to think of software, hardware, and algorithms as independent choices, and we publish papers about the algorithms and we're excited about algorithmic breakthroughs, but actually there's feedback between those three different ecosystems and there needs to be more idea flow between all three.

At Graphcore I was really fortunate to be able to explore those at both the software layer—how do you even express these fundamentally massively asynchronous processors that are all seeing different forms of data?—alongside the scientific applications and algorithms that we wanted to accelerate. We wrote a DFT solver that ran on the Graphcore IPU. It was limited in many ways, but it also enabled an enormous scale data-generation project. I would love to try to place as many bets across the hardware lottery. It might be that coupled cluster is a task that works well on modern GPUs, but it could also be really well suited to other ASIC inference chips that are being developed now.

Corin: Looking back over your career and publication history, you've been an advocate both for conventional physics-based electronic structure methods and also pretty early on the ML-for-chemistry movement. What do you think about the balance between machine learning, MLIPs, quantum mechanics, semi-empirical methods, data-driven methods: how does this look going forward?

Several potential views: some people think that DFT is a bootloader for a machine-learning future, so there's a big demand for DFT now and then we'll be done. There's other people who argue that MLIPs are intrinsically unscientific because you're doing a very fancy form of interpolation and that science is intrinsically always about extrapolation. How do you see this playing out?

Hatem: Yeah, it's a great question. I'm going to answer it first in the abstract: I love building tools. In The Structure of Scientific Revolutions, a core part of Thomas Kuhn's thesis is that the tools that we have shape the questions that we can ask and answer.

Particularly in the Graphcore years I was thinking about how we shape the tools in a way that we can start asking bigger and different questions. If we had a massively accelerated DFT engine, what does that allow us to do? We can run studies looking at how models do a better job of generalizing to out-of-distribution predictions and are able to avoid overfitting just by the sheer scale of the data, which is a really fun result. That's still how I see it.

Which horse are we backing at Potential? There are a lot of unanswered questions around the interplay between which electronic-structure methods you use, which MLIP architecture, and what happens post-training. Once you've trained this universal potential, fine-tuning seems to be extremely successful at fitting these into specific chemistry domains.

Distillation is another way of creating hyperefficient MLIPs that learn from high-resolution universal potentials, and then you can use those to deploy into anything: MD or other latent-space representations that you consume in larger ML systems. I feel like building tools is where we want to be and that we have a different vantage point that we just haven't seen anywhere else. And that's one of the things that's really exciting about the team that's come together.

Corin: That makes good sense, and I think this segues nicely into the lead-optimization point. I'm curious to hear more specifically what you guys are hoping to do in the lead-optimization space, and what you think you'll be able to do that others haven't tried or haven't been able to pull off.

Hatem: Really good question. Obviously, it has been pointed out to me that we're smaller, we're less well-funded—what exact unique advantage over some of these behemoth pharma labs do we have?

Corin: Yeah.

Hatem: I think it comes down to the fact that everyone's training on the same fixed data set in the co-folding space. That's a really good problem just to focus on for a minute. There's this rich history of the PDB, and there's a Nobel Prize for AlphaFold which is 100% deserved, a real breakthrough moment for the field. But on the other side, the PDB is extremely biased.

We don't see physiological conditions, we see X-ray crystallography data which is very different. It's still remarkable that you can actually correlate the structure from a crystal into what might be happening in a biological system—that's an amazing result that you wouldn't think is possible. It's as if from looking at ice, you can predict how bulk liquid water works.

It's a long way of saying that we see the stack of electronic structure feeding into using those representations in new ways in other models: potentially in cofolding, and being able to do more direct prediction of assay results. Binding affinity is a project I worked on for quite a while when I was at Recursion, and we had some interesting results using a very similar stack. There are broader applications that we'd love to bring forward building on that stack: ADME, tox, these structure–activity relationship curves that have been very elusive with previous means.

But the core thesis for us is that atomistic foundation models learn an interesting representation of chemical environments. This representation can be repurposed in lots of new and interesting ways. And for us, we keep finding ways that those representations just seem to keep applying, which is really exciting.

Corin: How is building a company in the UK different from building in other locales?

Hatem: Good question. I only know what it's like to build over here.

Corin: Well, you're welcome to speculate.

Hatem: I think there's a lazy take which I think is true to a certain extent. A number of investors in Europe will do a quick pass and say: "there's not a clear product, come back when you have something else." On the talent side, which I think is underestimated, we have an exceptionally committed team. The mission resonates with them. Of course, you could build that in lots of places, but I think there's a different set of values. We're in this for the long haul.

My impression particularly of Silicon Valley is that there's a lot more job hopping. You could argue that's more from opportunity cost, but in my mind some of our unfair advantages of being in the UK have been access to this kind of niche of talent that have worked across AI, life sciences, and hardware optimization.

Also, as part of our funding round we've brought in the UK sovereign AI fund.

Corin: Congrats.

Hatem: Thank you. This has been huge because alongside their investment we've had access to UK national supercomputing facilities through the AIRR program, and that's transformative for a company like ours which could potentially spend quite a lot on compute. To have the investment paired with a very sizable number of GPU hours means we can be bold. We can really try things that in a different world, in the standard US venture-backed business, you'd have to raise twice or three times as much money to procure enough compute to really fuel that scientific ambition alongside the product ambition.

Corin: Speaking of teams, are there traits that, because of the nature of the work you're doing or because of your background or personality, you value in team members more highly than does the median employer? Everyone wants people who are smart, hardworking, responsible, but what are the things that you price differently than the market?

Hatem: Adaptability, right? Our team is not the team to join because you want a box to fit in. Go back to pre- or post-training: "I am the post-training guy. I just do post-training. People just hand me a foundation model and I just do post-training." This is not that kind of place.

We want the kind of people who are so adaptable that they're just curious: "That's maybe not running as fast as it should be. Oh, I've heard about CUDA warps. What do they do?" And then they just follow that chain of thought into: "oh, actually, I found another 50% performance improvement in the data-generation pipeline" and that feeds through everything we do.

It's just more me as well. I've had to adapt to all these various transitions in my career. Moving from the US to the UK was another kind of culture shock. And it's part of the early company-building story as well: adapting to the fundraising cycles, navigating early commercial partnerships, early product releases that we want to get out, that's all about getting a sense of what is interesting to people and thinking "oh I could actually build that," and that requires quick adaptation. If you're too rigid, you miss the opportunity or it's just never there.

Corin: That makes a ton of sense. I think that's very similar to what we screen for as well. I always ask interview candidates to do a completely out-of-domain technical problem just to see how they handle it.

You've written before about work–life balance at Graphcore. How have you thought about that from a company culture formation point of view? How do you balance that humanity with the rigors of being an early startup who has to hustle a good amount?

Hatem: That's a really good question and it's really important to me. Graphcore treated us very well. I was able to join at a good point in the company. They had exceptionally generous parental leave, particularly for dads. And I think balancing that with the always-on "996" culture, it's the recognition that people do their best work if they're not counting the hours. It's just all about the flow of it.

I never imagine that people are working 18-hour days as a norm. Maybe there are occasions where you're just in the flow and it turns out it was an 18 hour day, but it reminds me more of being in university, just being so completely oversubscribed with problem sets that it just forces this thought: well I need to eat and I need to sleep and actually it's fun if I hang out with my friends sometimes as well, so I need to do all these things and now I need to constrain all the problem sets I need to do to allow me to feel human.

And today it's different. I have a young family and it's just so important that my kids don't feel like I'm just always on the road or always away doing work. Something I often lean on is this mathematician G. H. Hardy, who's another Cambridge legend. (It's a great book to read as well: A Mathematician's Apology, I highly recommend it.) He details his working pattern which was basically four hours of pure maths and then followed by tea in the college common room catching up on cricket scores. And that four-hour target feels about right for genuinely mentally strenuous creative work. If we can achieve that every day, then all the other things: messaging, communicating, writing, updating investors, all the other stuff that has to happen…

Corin: NDA redlines.

Hatem: Exactly. All these things that there's back and forths on and which are rarely super urgent. That's all we can ask of ourselves and of each other actually.

Corin: Can I invite you to speculate for a little bit?

Hatem: Yes.

Corin: One of the things that's baffled me about the computational-chemistry research space is how little attention gets paid to solvent modeling and implicit solvent in particular, despite (as Claude would say) the "genuinely load-bearing" role that this plays in most applied simulations. I can't understand. When I ask academics to work on these, I tell them what frustrates us or what limits us in the implicit-solvent space and there seems to be very little interest in actually tackling these problems. Do you know why that is?

Hatem: I think it's just considered the wrong shape problem. It's actually quite complicated and that doesn't fit very well… cool electronic-structure research is very reductive. You're looking for a simpler way to solve a problem. Here, the solution is probably more parameters. This is maybe a dig at my own thesis of trying to find a minimal-parameter solvent model, but that seemed to be a worthy aim at the time. Given its potential impact on predictions, particularly for physiological conditions, my feeling has always been that it should have more attention, but it can devolve into "maybe you should be using explicit water."

That's part of our bet here. A really good universal atomistic foundation model trained on coupled cluster–level data. Does it recover the bulk properties of water? Does it recover the right boundary conditions that you can naturally mesh into a dielectric-type implicit-solvent model? I would like to see more studies on how you make implicit-solvent methods actually mesh well with a few explicitly treated solvent molecules.

Corin: I've always hated approaches like that, to put my own cards on the table, because there's so much room to be arbitrary. There's a lot of room for p-hacking where you continue placing solvent molecules until the result matches experiment and then stop.

Hatem: Yeah. I think it's just that intuitively, for a reaction that's mediated by a water molecule, of course you're going to need a few hydrogen bonds, a few explicit water molecules around that regime. And maybe it comes from the intuition of these relatively old results in QM/MM where for crack propagation in silicon, there's a really clear correspondence with what's been observed in experiment. You can just see these bonds break like a zipper and further away you could just get away with a relatively simple elastic model.

Even going all the way down to a continuum mechanics model in biology—I think that's still an unanswered question. I'd like to see: does it even work? Can you observe reactions? Where is there that focus of control, that sort of nearsightedness of electronic structure that descends into the continuum model? Of course, there's loads of hyperparameters that one could play with to then make sure it does agree exactly with reality.

Corin: This ties back very much to the mesoscale question. Ideally building better atomistic pictures should not only make us better at atomistic understanding, but also give us the foundation to be able to translate that and build more coarse-grained, phenomenological, insightful models.

Hatem: Yes.

Corin: I think we have a bias towards finding things that are simpler than just a massive 10-million-element matrix of positions and velocities. Trying to build the tools to let us find these for new problems is one of the things I'm very excited about. (Maybe to put words in your mouth a little bit.)

Hatem: Maybe it ties into the tool-building idea as well: you have universal potentials and you can distill them into other super-efficient ML potentials or start doing a better job of fitting classical force fields in a way that's done in a more on-the-fly manner.

Corin: That's right. What do you do to de-stress when you're not working?

Hatem: I ride my bike as fast as I can. Slower than I used to, but that's the nature of the game as well. The less time you do it, the slower you get.

I bake bread as well. Like many people, I got into sourdough baking in the pandemic. There's something about kneading the bread: if things are not going particularly well, it's a good way to de-stress.

And also just hanging out with my kids. My son has gotten into cricket, which I know nothing about, but he's very happy for me to throw a ball to him and he tries to hit it and it keeps you in the moment, which is a perfect thing to completely empty the mind of whatever else is going on in the chaos of an early company.

Corin: I have two more questions for you. One is: how do you see the relationship between open- and closed-source software evolving or playing out in this new agentic coding world? A lot of old software companies are feeling very stressed. A lot of new companies and forms of companies like your own are emerging. What do you think is going to happen and how do you see Potential reacting or being a part of this?

Hatem: Even before good coding agents, I had that somewhat controversial take that all source code on its own is genuinely useless. I think I could have made some IP lawyers very nervous having that argument with them. But for me it was always the building and test process, the deployment, and the verification that this runs across all the different types of hardware. We know it performs this well and we know it's been tested in this way. That's actually super valuable and that doesn't actually go away with agents. That's still true in my head.

Corin: It's actually much more important.

Hatem: Yeah, exactly. It's made good CI and good flows critical between an idea or a "hey, maybe this thing should work" to "it's deployed in production and people are trying to use it now, and by the way, it's running some safety critical system and it better never fail." I've also been fortunate to have part of my career programming in that sort of environment, where there is no plan B. The system either runs or it doesn't.

I want us to have a very clear open-science mandate and that will include a certain amount of publishing our work as white papers, but also sharing libraries and reusable tools that we've found to accelerate our own work. We also want feedback and community input on how we should shape this or what direction we should take this in? We have a little electronic-structure library that does direct minimization directly in JAX. That's kind of fun. Tell us where is the limit? Or are there new problems that we haven't even thought of that this could actually be reused for?

Corin: Last question. What are you hoping to do next? If we're watching Potential from the outside, what should we expect to see? Where do you hope to be a year or two from now?

Hatem: I want us to be clearly deployed in and benefiting live lead-optimization programs. So finding the hardest chemical problems and suggesting improvements that perhaps are not obvious. These kinds of atomistic simulations being more deeply embedded into the early preclinical drug-discovery phase would be incredibly exciting for us.

The potential for impact on our customers and then eventually their patients that benefit is really exciting and a big part of our mission. We see a path that feels somewhat overlooked: yes, there is a connection between electronic-structure simulation and atomistic foundation models and chemical prediction systems all the way to a patient feeling a bit better. That's really exciting. As a group, that's a thesis that we have seen the evidence for, but we need to demonstrate more evidence for it in the next year or two.