The short answer is yes. Aspen Plus has had a programmatic control surface for decades, and an AI agent layered on top of it can already open a case, read the flowsheet, change inputs, run the solver, and report results from a natural-language request. The longer answer is that "can" and "should trust" are different questions, and the gap between them is where most of the engineering lives.
This post walks through what programmatic control of Aspen Plus actually is, what an AI agent built on it can genuinely do today, why the naive approach is risky in a licensed, stateful simulator, and what a trustworthy version looks like.
Aspen Plus already has a control surface
Aspen Plus exposes a COM automation interface. It is the same interface that Python and VBA scripts have used for years: connect to the application, open a case, navigate the variable tree to read or write values, run the engine, and read results back out. Nothing about it is new or exotic.
What this means is that AI control of Aspen Plus does not require anything from AspenTech beyond what already ships. The question is not whether a program can drive the simulator. It is what sits between a natural-language request and those low-level calls.
What an AI agent can genuinely do today
With that interface underneath, an agent can translate plain-language requests into concrete simulator actions. Working against Aspen Plus today, that includes:
- Opening a case and reading its structure: blocks, streams, and components.
- Reading current block parameters and stream specifications.
- Editing parameters and stream specs, and building or modifying flowsheet topology.
- Running the solver and reading convergence status and results.
- Connecting reported errors back to the specific inputs and blocks involved.
That covers a large share of routine simulation work: sensitivity sweeps, spec changes, re-running a case after an upstream edit, and the first pass of convergence troubleshooting. None of it requires the agent to guess at the flowsheet, because it can read the actual state of the case before proposing anything.
Why "have the LLM write a script" is risky
The obvious first architecture is to have a language model generate an automation script and execute it. This works in demos and fails in practice, for reasons specific to simulators.
A process simulator is stateful. A generated script that writes the wrong variable path may not error at all; it may silently do nothing, or change something adjacent to what was intended. The case keeps running, the number looks plausible, and nobody notices until the results are already in a report.
It is also hard to review. A reviewer shown two hundred lines of generated code has to reverse-engineer the intent before they can judge the change. And a runaway script against a licensed seat can hang the engine on bad inputs or leave the case in a state nobody asked for. Freeform code generation puts the least verifiable layer at the most sensitive point in the stack.
How Reflux approaches it instead
Reflux drives Aspen Plus through that same COM interface, but the model never writes raw automation code. It calls a typed tool surface: a fixed set of inspectable actions like reading a stream, setting a block parameter, or running the solver. Every action is legible on its own, so a reviewer sees "set the reflux ratio on this column to 3.2," not a script to decode.
On top of that sit three verification layers. First, write receipts: every write is read back from the simulator and verified before Reflux reports it as applied, so a silent no-op cannot masquerade as a change. Second, run gates: runs are checked for required-input completeness before they start, and results pass quality gates before Reflux reports success. Third, review: real changes sit behind explicit human review, with each proposed change tied to the specific block, stream, and result a reviewer needs to check it.
Convergence troubleshooting follows the same pattern. Reflux reads the run history and status the simulator reports, connects errors to the inputs and blocks involved, and proposes changes through the same reviewed path. The Aspen Plus connection itself lives behind a simulator-agnostic adapter layer: Aspen Plus is supported today, with an architecture designed to extend to other process simulators.
What to look for in any AI-for-simulation tool
Whether or not you evaluate Reflux, apply the same checklist to anything that claims to drive your simulator:
- Does it read the actual case state before proposing changes, or work from assumptions?
- Are actions discrete and inspectable, or buried in generated code?
- Is every write verified against the simulator after it lands?
- Are runs gated on input completeness, and results checked before they are reported?
- Is there an explicit review step before real changes, and can a reviewer trace each change to a specific block, stream, and result?
A tool that passes this checklist can earn a place in real workflows. A tool that cannot is a demo.
Request a demo if you want to see this working against a live Aspen Plus case, from Slack, Teams, the local control panel, CLI, or an MCP client.