An engineering agent that runs your process model
Ask it to cut steam on the evaporator, find why the concentrate went off-spec on Tuesday, or fit the model to last month's data. It runs the rigorous solver, honours your operating constraints, and shows the tool call behind every number.
23 worked demonstrations across 9 industries — free to browse, no account
Not a chatbot bolted onto a simulator
A copilot answers questions about a flowsheet. This does the engineering: it runs cases, optimizes under constraints, investigates upsets against plant data, and writes the report — then tells you what it could not explain.
Engineering studies, not chat
Commission a study — reduce energy, raise production, find a root cause, rate equipment — and the agent works a playbook: baseline, sensitivity, constrained optimization, economics, report. Each phase is ticked from the tools that actually ran, and a skipped phase sends the agent back for it.
A process model with named variables
The workspace holds your flowsheet plus a map from engineering names to it: steam flow in t/h, evaporator pressure in bar, product concentration in wt%. The agent, the optimizer, the scenario table and the report all speak those names, and unit errors are refused rather than silently converted.
Constraints it cannot argue with
Hard and soft limits live on the workspace — product spec, production floor, vessel rating, solvent-degradation ceiling. Every optimization carries the hard constraints whatever the question asked, and the answer reports each one's margin.
Plant data and root cause
Load a historian export, and the agent compares periods, finds operating regimes, and attributes a change to the inputs that moved — simulating each one alone. What the model cannot reproduce is reported as an unexplained residual, which is a finding, not a gap.
Calibration against measurements
Fouling, efficiency and the other parameters no named variable sets get fitted to real operating points. Applying a fit is a human action that creates a new model version — the agent can propose one, and has no tool that installs it.
Verification after implementation
Once the plant has run at an approved scenario, the prediction is checked against the measurements — and 'the plant never ran at those settings' is reported separately from 'it ran there and the model missed', because they need opposite next steps.
The rules it works under
These are the reason an engineer can put an answer in front of a plant manager. Each one is enforced by a test in the codebase, not by a line in a prompt.
The AI never produces a number
Tools do. Every figure in an answer traces to a tool invocation, a scenario id and a simulation — and an answer whose numbers are not in a tool result fails the grader.
There is no approval tool
Approval is a route a member calls, only from a validated scenario, forwards only, and an approved scenario is frozen. The agent cannot approve, implement or actuate anything.
Unavailable beats invented
With no model provider configured the agent reports itself unavailable and answers nothing. Scenarios, optimizations, investigations and reports still run — the AI is never on the critical path.
Documents are untrusted input
Uploaded datasheets and reports are retrieved with citations and handed to the model in a labelled envelope. A mention is a place to read, not a fact, and the tool output says so.
23 worked demonstrations, 9 industries
Each one is a converging process model with its own named variables, operating constraints and price book — the question an operator would actually ask, already set up. Filter by industry or search, and open one in a workspace.
Prices and constraint limits in the demonstrations are illustrative and each says so. The process models and every solved number are real.
Works across the stack you already run
The point is to operate over your existing industrial software, not to replace it. Connectors that are not built yet are listed as planned rather than implied.
| Digital-twin historian | Built in | The readings your OPC-UA, MQTT, Modbus or EtherNet-IP collectors already write. |
| Aspen, HYSYS & DWSIM files | Built in | A .bkp, .apw or .hsc becomes a process model with a starter variable map. |
| REST / HTTP (incl. PI Web API) | Available | Recorded-value streams, JSON records or CSV. Credentials travel once and are never stored. |
| SQL | Available | One read-only SELECT on your own warehouse. The connection string is used for the call and not kept. |
| PI, PHD, IP.21, Aspen & AVEVA live | Planned | Shipped as manifests with their config fields, labelled planned — visible architecture, no claim. |
Plant data loads into the same store the digital twin already uses, so one dataset shape serves the historian, the investigations and the calibrations.
Start with a plant that looks like yours
The gallery is open — read the question each demonstration asks, the variables it can move and the limits it is held to, before you sign up for anything.