A letter from Georgy Maikov, Co-founder and CEO, Elementics.AI
Almost everyone building AI for science is trying to make the experiment faster. Faster synthesis, faster screening, robots that run through the night.
I think most of that effort is aimed at the wrong problem. In physical R&D, the experiment will not go fast. The slowness belongs to the lab itself. Materials cure, samples age, seasons turn, and plants scale up on their own schedule. You cannot engineer that away.
This letter explains why we believe that, and what we are building because of it.
The number that decides everything
Think about any R&D project. You start with a lot of uncertainty, and you want to end with a product. Getting there costs time and money. The most important question is how many steps you can take before one of them runs out.
Call that number N.
By a step I mean one full learning cycle. You decide what to try, you run it, you wait for the result, you read it, and you decide what to try next.
N shapes the whole method. It tells you what a wrong step costs, and so how much guessing you can afford.
Why AI works so well in software
In software, N is in the thousands. A developer can write code, run it and check the result many times a day. A wrong step costs a tiny fraction of the project. Often it costs a few minutes.
So the method is built on being wrong quickly and often. Try something, watch it fail, adjust, try again. Today's AI tools fit this loop well. They produce many candidate answers, and the loop throws out the bad ones almost for free.
Why physical R&D is different
In physical R&D, N is in the tens.
A cure takes the time it takes. An accelerated stability study runs for weeks, often months. A field trial waits for the growing season. A scale-up takes a quarter. None of these clocks respond to budget. Money can buy more equipment, more people and more samples. It cannot shorten a four-week oven test.
With N in the tens, each wrong step costs something like a tenth of the project. A wrong guess means weeks gone, a stability slot used, and a deadline that is closer than it was.
That changes what a good method looks like. A method that works by being wrong a thousand times breaks down when you only get twenty tries.
"But I can run twenty samples at once"
This is usually the first objection a good chemist raises, and it is a fair one.
Yes, you can put twenty samples in the oven. You should. Design of experiments, high-throughput screening and parallel formulation all make each round richer.
They do not add rounds, though. Twenty samples in one stability study is still one learning cycle. You still wait four weeks before you know what to change. Parallel work makes each step wider. The number of steps stays about where it was.
A wider step also only helps if you picked the right variables to put in it. If the real cause of your problem sits outside the twenty samples you chose, you have run twenty experiments and learned very little. So running in parallel raises the stakes on the decision you make before the run.
A fast answer to a slow problem
This is why I am skeptical of the main direction in AI for science.
Bigger models and robotic labs are fast-loop answers. They help most where the bottleneck is hands or compute. Where the bottleneck is the wait, automating the pipetting makes the fast part faster, and the slow part stays exactly where it was. Without a better way to choose what to run, they let you run the wrong experiment sooner.
To be fair, automation has real value, and there are problems where a high-throughput robot is the right tool. But for most teams in formulation, coatings, polymers and materials, the scarce resource is the number of learning cycles. That is the resource worth protecting.
Design for the slow loop
So we treat the slow loop as a boundary condition. You do not remove it. You design for it.
Once you accept that, the first question becomes: which experiments can I avoid running at all? And for the ones I must run, which single run will teach me the most?
This is an old idea in science. In 1890, the geologist T. C. Chamberlin argued that researchers should hold several working hypotheses at once instead of growing attached to one.1 In 1964, the physicist John Platt called the same discipline "strong inference": list the alternative explanations, then design a crucial experiment whose outcome rules some of them out.2
Good scientists already work this way when they have time to think. What they rarely have is the time to do it thoroughly on every problem, with every relevant paper, record and past run in view. That gap is where we think AI can help most.
What a slow-loop tool does
A tool built for the slow loop does most of its work before the run.
It starts with what the lab already has. The last good batch. The batch records and process logs. The notebook entries. The run that failed last spring and never made it into a report. The papers, patents and supplier data behind each raw material.
From that, it names what could have caused the problem and what each cause would predict. Then it looks for the experiment that separates those suspects: the one run whose result would rule out the most of them.
And it says so when the evidence does not reach an answer. In a fast loop, a confident guess is cheap, because if it is wrong you find out in a minute. In a slow loop, a confident wrong guess can cost a month. So "I don't know yet, and here is what would tell us" is part of the job.
An example
Here is a simple case. A cream that passed stability last year now separates after three weeks at 45 °C. On paper the formula has not changed. There are four suspects:
- a new lot of carbomer thickener,
- a preservative swap that added salt to the water phase,
- a change in homogenizer speed during a scale-up, or
- pH drift during storage.
Each suspect predicts something different. If the added salt is the cause, the failed batch should show higher conductivity and an early drop in viscosity, since carbomer thickens poorly in the presence of electrolytes. If the homogenizer is the cause, the droplets under a microscope should already be larger on day one. If the carbomer lot is the cause, a small side batch made with the old lot should hold up where the new one does not. If pH is the cause, a retained sample will show it.
Some of these checks cost nothing, because the lot numbers and the process log already exist. Some cost an afternoon at the bench. Only one needs another stability slot. The job is to spend that slot last, and only on the question the cheaper checks could not settle.
None of this is new to an experienced formulator. The hard part is doing it every time, under deadline, with all the evidence in view.
Where REACTOR stands today
This thinking is the basis of REACTOR, our AI platform for chemical and materials R&D. I want to be precise about what exists today and what we are still building.
Today, the REACTOR Formulation Troubleshooter does a real part of this job. A formulator describes the failure and puts the evidence on the table: spectra, curves, photos, batch records, data sheets. REACTOR returns ranked causes to investigate, with the reasoning for each. It states its assumptions and marks each one High, Medium or Low confidence. It cites its sources, and it asks for missing context instead of guessing. The work stays in a Research Space, so the next chemist who hits the same wall starts from the last answer.
It also has limits, and we are clear about them. It does not run experiments. It does not predict property values nobody has measured. It does not replace the bench. Its job is to narrow down what is worth testing and to show why.
Designing the single most informative next experiment, across everything a lab knows, is where we are heading. It is a harder problem than generating answers, and we will get parts of it wrong along the way. We think it is the right problem for physical R&D.
Why we are building this
I trained as a physical chemist. The labs I respect most are the ones that waste the fewest cycles.
Most of the effort in AI for science today goes into speeding up the loop. Much less goes into the decision that comes before it. That decision is where we have chosen to work.
If your lab lives with long cycles, I would like to hear what slows you down.
Georgy Maikov
Co-founder and CEO, Elementics.AI
References
- Chamberlin, T. C. (1890). The method of multiple working hypotheses. Science, 15(366), 92–96. doi:10.1126/science.ns-15.366.92
- Platt, J. R. (1964). Strong inference. Science, 146(3642), 347–353. doi:10.1126/science.146.3642.347
Ready to Transform Your R&D?
See how Reactor's chemistry-native AI can accelerate your research and development workflows.
Schedule a Demo
