From Lab Intuition to Machine Learning Algorithms: ReactWise’s Playbook for Faster Reaction Optimization
INTERVIEW
Dr. Alexander Pomberger, CEO and Co-founder | ReactWise
From Lab Intuition to Machine Learning Algorithms: ReactWise’s Playbook for Faster Reaction Optimization
Interviewed by Dr. Rahul Nabar
“With transfer learning, we’ve shown that the number of experiments can be reduced by over 90% - without sacrificing process insight.”
ReactWise is building a data-driven decision layer for chemists, helping teams navigate vast reaction and process-parameter spaces with fewer experiments and clearer insights. In this conversation, Dr. Rahul Nabar (Business Development Consultant at Amar Equipment and Adjunct Professor at IIT Bombay) spoke with Alexander from ReactWise about how Bayesian optimization, transfer learning, and emerging self-driving-lab workflows are changing process development.
Alexander is a trained organic chemist who completed an industry-funded PhD at the intersection of organic chemistry, machine learning, and self-driving laboratories. ReactWise was founded to translate those research learnings into a practical platform that chemists will actually use at the bench - especially during process development, where robust, scalable operating windows must be found under real constraints.
Excerpts from the interview:
How did ReactWise start, and what problem are you trying to solve?
ReactWise came out of a simple observation: organic chemistry is still heavily manual and intuition-driven, and for decades, it has underused digital tools. During our PhDs, my co-founder Daniel Wigh and I worked on machine learning for chemistry and self-driving laboratory concepts, but we saw that many advances remained trapped in journal papers or code repositories. We founded ReactWise to put those capabilities into the hands of bench chemists.
We focus on the process development stage - after discovery - where teams need to manufacture kilograms of material with high yield, low impurities, and stable, scalable operating conditions. Even for ‘simple’ reactions, the number of possible parameter combinations can run into the hundreds or thousands (and sometimes far more). Our platform uses Bayesian optimization to iteratively recommend experiments - closing the design-make-test–analyze loop - and help chemists move through that space efficiently.
We also built a transfer-learning approach called MemoryBO that allows teams to leverage relevant historic data as a smarter starting point. In our published work, this can dramatically reduce the experimental burden - often by more than 90% - because the optimization begins from informed conditions instead of starting cold. Today, we are a team of nine, based in the UK and the US, working across pharma, chemicals, materials, and formulation process development.
What types of chemistries and use-cases do you see most often from customers?
We started primarily with pharmaceutical process development. In pharma, the ‘core transformations’ repeat surprisingly often - many of them are catalytic coupling reactions. We frequently see palladium-catalyzed cross-couplings (for example Buchwald–Hartwig and Suzuki-type couplings), along with other staple bond-forming steps such as amide coupling and SNAr chemistry. Beyond reaction optimization, the same platform is also useful downstream - including crystallization and formulation development - because the underlying problem is similar: navigating a multidimensional space of conditions to meet quality and manufacturability targets.
Before platforms like ReactWise, how did teams typically optimize and validate their parameter space?
We see a wide spectrum. In many organizations, optimization is still driven by senior chemists making decisions based on decades of experience. In others, classical design-of-experiments (DoE) is used to probe robustness and interactions between parameters. The pain point is that teams often don’t want (or can’t afford) the large number of experiments that a full DoE program can imply.
Bayesian optimization is valuable here because it balances exploration and exploitation: it learns from each iteration and recommends the next best experiment to run. Some companies already have in-house Bayesian tools, but adoption can stall if usability is poor. We’ve put a lot of effort into making workflows and visualizations simple enough that chemists actually want to use them - without hiding the rigor in the background.
What experimental scales do you work with, and how do you connect the algorithms to real lab execution?
We support a broad range - from micro-litre high-throughput experimentation (HTE) in 96- or 384-well plate workflows, all the way up to pilot-type reactors. On the algorithm side, our methods originated in our PhD research and have been hardened over time to be more adaptive and robust.
On the lab side, the industry is clearly investing again in parallel synthesizers and HTE. That changes what the software needs to do: you’re not just choosing one next experiment - you may be designing an entire plate while thinking carefully about exploration vs. exploitation across dozens or hundreds of conditions.
Flow chemistry is also a natural fit for Bayesian optimization because it often runs experiments sequentially - one at a time - so the surrogate model can be updated after every run. The logical next step is closed-loop optimization. At ReactWise we’ve built an API-first approach so labs can connect automation and PAT (for example, UVVis detectors) directly to the platform: the system requests experiments, receives analytical data, converts it (via calibration) into metrics like yield or purity, and iterates with minimal friction. This enables plug-and-play self-driving lab workflows that work under real constraints, not just in a demo setup.
High-throughput and combinatorial workflows had an early wave years ago. What feels different in today’s resurgence?
My understanding is that the first big wave was strongly centered on medicinal chemistry. The current resurgence is showing much deeper adoption in process development teams - and that brings different constraints. Process teams care about process-relevant solvents and scalable conditions, which means you can’t always run everything in ‘convenient’ plate-compatible setups. You have to consider materials compatibility, sustainable solvent choices, and hardware that can survive those conditions. We also built our own screening lab, with the goal of generating large, process-relevant datasets that can be reused to kickstart new optimizations and help train more general reactivity models.
ReactWise seems to combine software with wet-lab screening. How do you engage customers, and why maintain an internal lab?
At the core, ReactWise is a software company - our main business model is annual software licenses that give customers access to the platform. The reason we operate an internal screening lab is tightly linked to transfer learning and staying close to our clients’ workflows.
We learned that transfer-learning optimization works best when you have strong starting data. In practice, that data can come from (1) the literature - often sparse and noisy, (2) a customer’s historical data - sometimes difficult due to confidentiality and data structure, or (3) a high-quality dataset generated in a consistent way. To make this as frictionless as possible, we generated our own datasets of transformations observed across clients, spanning broad electronic and steric diversity.
So far, we have screened more than 15,000 process-relevant reactions. When a new customer comes in, they can filter that library to build a proxy dataset close to their chemistry, start from a pre-trained model, and then transfer knowledge into their campaign.
This is also where partnerships with equipment experts - such as Amar - become powerful. Hardware imposes real constraints (operating ranges, dosing limits, feasibility boundaries). We have features that allow users to encode those constraints directly, so the recommendations stay technically feasible. And as closed-loop optimization becomes more common, software–hardware integration - especially around PAT - will be essential.
There’s a lot of literature on self-optimizing reactors, but fewer industrial deployments. What has held adoption back?
Robustness is a major barrier. In many industrial labs, the self-optimizing setups that exist were either developed in-house or in collaboration with academic groups. They can work well - but keeping them running reliably can require constant maintenance. For example, a fully automated flow reactor requires mitigation strategies for clogging and safeguards against chemical hazards. Industry cannot afford a situation where a PhD-level chemist is forced to supervise a system that is supposed to run autonomously.
A second barrier is that real processes often involve heterogeneity. Many published demonstrations assume homogeneous feeds, whereas industrial reality includes solids and complex mixtures. Accurate solid dosing - especially neat dosing rather than a suspension - is non-trivial, and it can define whether flow is the right choice for a given process.
Many practitioners say reaction technology has advanced faster than downstream work-up. How do you see that gap?
Downstream operations such as crystallization and work-up can indeed become the pacing step. From our side, our clients primarily focus on upstream reaction optimization, because that is where they can create the largest immediate impact across many campaigns.
One data source you mentioned is the literature. How do you deal with data quality and noise when using historical datasets?
Chemistry data is inherently noisy: different labs use different protocols, quantification methods, and calibrations. In practice, we see large variability - reaction yields can easily differ by plus/minus 15–20% across sources. Our guidance is pragmatic: if you have high-quality internal data, use it first. If not, use consistent datasets (such as those we generate). Literature data can be helpful, but it is better to start with a smaller, higher-quality dataset than a large, low-quality one. Models can learn uncertainty, but ‘garbage in, garbage out’ still applies.
How is the platform built day-to-day - and how are LLMs changing the way you develop, or even the way chemists might use tools like yours?
Most of our algorithmic development is in Python, which remains the backbone of machine learning research and deployment. Large language models are absolutely changing software productivity: compared to the start of my PhD - when I learned coding by watching tutorials - today you can generate robust functions or prototypes much faster with the right prompts.
But that shifts the bottleneck. The differentiator becomes user experience, testing, and building workflows that are reliable in real lab contexts. LLMs can already give decent ‘generic’ starting conditions (for example, common Suzuki coupling ranges), because they can reflect what appears frequently in the public literature. Where they still fall short is on specificity: functional-group intolerance, complex substrates, and encoding solvent and process descriptors such as polarity, miscibility, and solubility in a disciplined way.
Finally, proprietary experimental datasets remain a strategic advantage. The high-quality data we generate and curate is not available to general models - and that is exactly what enables more trustworthy, chemistry-specific recommendations.
Do you see a path toward more open reaction datasets - without compromising confidentiality and competitive advantage?
There are encouraging efforts, such as the Open Reaction Database, which aims to make reaction datasets available in structured formats rather than as unstructured experimental sections in papers. Initiatives like this also create incentives for researchers to upload data - especially relevant for parallel synthesis, HTE, flow, and batch chemistry.
I’m optimistic we will see meaningful progress over the next few years. But for industrial process development, proprietary data will remain critical. The practical path forward is likely a blend: better public standards and repositories for non-sensitive data, combined with tools that let companies extract value from their own internal datasets without exposing them.
With more manufacturing shifting to India, how do you view India as a market for ReactWise?
We work globally and don’t take a geography-first approach, but we have had many conversations with Indian CMOs and manufacturers. Early adopters of these tools were often in the US and Europe, yet we now see growing interest from India. Given the scale of chemical and pharmaceutical manufacturing in India, it is a natural market for data-driven optimization - especially as organizations look to improve yield, quality, and speed-to-process under cost pressure.
If you had to pick one or two focus areas for the next 12 months, what would they be?
We want to expand beyond ‘only’ lab-scale process development in both directions: earlier into discovery chemistry, and later into pilot and manufacturing contexts. That includes having the right data and models ready for real-world events such as batch failures - so teams can diagnose issues faster and make better decisions.Ultimately, the goal is to support a larger portion of the end-to-end development pipeline, while continuing to deepen the integration between algorithms, data generation, and practical constraints in the lab.
Dr Rahul Nabar
rahul@nabarcon.com
