The model chooses.
The solver computes.
If you have heard that AI is coming for simulation software, this is what an agent driving a simulator actually does. Four steps, one of which is the same solver you have trusted for forty years. Then the sentence two of the biggest vendors both published this year, and a worked case you can move yourself.
Reflux does this on your own Aspen Plus, from a sentence. Try it free on Aspen Plus →, or jump straight to the four steps.
Out now
Try Reflux Student free on Aspen Plus
Reflux Student drives your own Aspen Plus V14 from plain English. You type what you want, it opens the case, makes the change in Aspen, runs it, reads the result back and tells you what it verified. Aspen does the math. You keep the judgment. Windows, your own licence, and free to start is a trial with a limit on it, not a free product.
Enter your email on the next page and the download link lands in your inbox, so you can open it on the Windows machine Aspen lives on. Windows will say it does not recognise the app the first time: click More info, then Run anyway. The certificate is new and Windows trusts it by reputation, which takes downloads to build. Nothing is wrong with the file.
Not on Aspen Plus? Tell me which simulator you use → and you hear the day your build exists.
The four steps.
Strip the word “AI” out of it and an agent driving a simulator is a loop with four stations. Nothing in it is mysterious, and exactly one of the four does any physics.
A tool, not a guess.
This is the part that does the work, and it is duller than the word “agent” suggests. The model does not emit an answer. It emits a call, against a list of things it is allowed to do, with arguments that have to typecheck:
Tree.FindNode(node).Value = value
Engine.Run2()
Tree.FindNode(node).Value Those are Aspen Plus’s own COM automation calls, the same interface Python and VBA scripts have driven for twenty years. Reflux is not doing anything to your flowsheet that a macro could not. It is deciding which macro to write, and then reading what came back. The node is a path in
\Data\Blocks, which is where Aspen keeps every
block’s inputs and results.
So the three calls that sentence turns into are just:
FindNode(colPressure).Value = 12
Engine.Run2()
Why the solver stays the source of truth.
The fear is that a language model will invent a number. It cannot, in this shape, because it is never the thing producing the number. Step 3 is a rigorous, deterministic, physics-based solve, and step 4 reads a variable out of it. What the model can get wrong is the choice: the wrong block, the wrong spec, the wrong property method.
A wrong choice gives you a wrong number, not an invented one. That is a real difference and it is the whole reason this architecture is worth having: a wrong number is reproducible, inspectable and arguable. You can open the case and see the spec it set. An invented number is none of those things.
It is also why the human stays in it. The literature agrees: every actual computation stays in the deterministic solver, and human oversight remains essential (Liang, Groll & Sin, DTU, 2026).
What the vendors said.
This is not a startup’s idea of the future. In November 2025 MathWorks shipped an MCP server for MATLAB. In September 2026 COMSOL announced one for Multiphysics 2027, and described it like this:
An agent can build and/or modify a model, run simulations, inspect results, and use those results to decide what to do next. COMSOL, Burlington MA, 16 September 2026. press release
Read it against the four steps above. Build a model is step 2. Run simulations is step 3. Inspect results is step 4. Use those results to decide what to do next is the return path. It is the same loop, described by a vendor who has been solving PDEs since 1986.
MCP, the protocol underneath most of this, is barely two years old (Anthropic, November 2024; MathWorks MATLAB MCP Server). The direction is not in doubt any more. What is still open is who does it for process simulation, and how well.
Move the pressure yourself.
Here is the case from the video, solved in your browser: a condensate stabiliser separating n-butane overhead from n-pentane in the bottoms, 98% recovery of the light key and 97% of the heavy, at 1.3 times minimum reflux. Fenske, Underwood and Gilliland, which is what Aspen’s DSTWU block runs. Drag the pressure and watch what it costs you.
At 8 bar the two keys are 2.95 apart and the reboiler wants 0.50 MW. At 12 bar they are 2.82 apart and it wants 0.52 MW which is 4.4% more heat for the same separation, because pressure pushes boiling points together and you buy back the lost volatility with reflux. That is the answer the agent came back with, and every digit of it came out of the solver.
| 8 bar | 12 bar | |
|---|---|---|
| Relative volatility, geometric mean | 2.95 | 2.82 |
| Minimum reflux, Underwood | 0.85 | 0.94 |
| Reflux ratio at 1.3 × Rmin | 1.10 | 1.22 |
| Theoretical stages, Gilliland | 16 | 17 |
| Condenser temperature | 65 °C | 83 °C |
| Reboiler temperature | 141 °C | 163 °C |
| Reboiler duty | 0.50 MW | 0.52 MW |
Vapour pressures from Antoine, latent heat from the Clausius Clapeyron slope of the same Antoine fit, so the two cannot disagree. A shortcut method, deliberately: the point is the direction and the size, and a rigorous RadFrac on your own feed is the thing you should run next.
What Reflux drives today.
Every simulator is about to get an interface like this. The agent itself is simulator-agnostic: it talks to an adapter, not to a product. Today the deep, live one is Aspen Plus.
If the one you use is not the live one, tell me which simulator you use → and you hear the day your build exists. That list is ordered by who asks.
Try it on your own Aspen Plus.
Free to start, Windows, your own licence. Install takes a few minutes and I will do it with you on a call if you want.
Nathan
← reflux.sh