How the conversation works
The mental model behind Phases — an agent with tools, a material-first rule, confirmation before anything expensive, and runs that persist.
It is an agent with tools, not a chat box over a form#
Most simulation front ends are a form with a Run button. Phases is not that. Behind the conversation sits a fixed set of tools — thirteen of them on the web chat surface — and the model's only job is to choose the right one, fill in its arguments, and report what came back.
You can see this happening. Every tool call renders as its own card in the transcript with a plain label: Listed materials, Loaded material, Compared materials, HT simulation, CCT diagram, RSW welding simulation, V-Gleeble, Listed runs, Inspected run. The card is amber while the tool runs, green when it succeeds, red when it fails. A card in the transcript is a tool that really ran. The reverse does not quite hold: a tool that fails with an internal diagnostic has its card withheld entirely, and you get the one-sentence message quoted below instead.
That visibility is the point. The agent is instructed to report only what the tools actually returned in that turn, and never to claim a simulation ran, a diagram was produced or a file was saved unless the tool was called and returned a result. It is equally instructed not to invent a reason for a failure — no "interface limitation" or "schema constraint" stories. When something fails with an internal diagnostic, the diagnostic is kept private and you get exactly one sentence:
The operation could not be completed. The issue was recorded for investigation.
That sentence is a real, deliberate output, not the agent stonewalling you. The full tool list is in the Tool reference.
Rule one: material first#
There is no default material. Not EN13261, not DC04, not the last thing you ran. Before any new simulation, the agent needs one of:
- a built-in grade you named,
- a workspace material you named,
- a composition you supplied, or
- a material already active in the session.
Phrasings like "run a simulation", "generate CCT", "run Gleeble", "simulate welding" or "surprise me" get a question, not a run. The tool layer enforces the same rule independently of the model, so it cannot be talked around.
The exception is the common case: name a simulation and a material together — "Run RSW with DP600 at 8 kA", "run CCT with my loaded material" — and it proceeds directly, while still showing you the material it resolved.
Once you have loaded a material, it stays active for the session. All four simulators use it automatically when you do not pass an explicit grade, so you can run several experiments on the same steel without re-stating it.
Rule two: confirmation before anything expensive#
There are two confirmation gates, and they exist for different reasons.
The parameter card. When you set up a simulation, the agent emits a configuration card rather than running immediately: phases-params for heat treatment, cct-params, vgleeble-params, rsw-params. The card renders as editable fields with one run button. Nothing executes until you press it, and pressing it posts the exact JSON into the conversation so the parameters that ran are part of the record. The card formats are described in Parameter blocks.
RSW is stricter than the others: the card is shown always, even when you already stated every parameter in your message. Your values are pre-filled, but you still confirm them.
The chemistry gate. When you supply a custom or modified composition, load_material and modify_material return a "needs confirmation" status and create nothing. The agent tells you which named grade your chemistry is closest to and asks whether to continue or adjust. Only if you agree does it re-issue the same call with confirmation.
What confirming does is narrow, and the product is careful to say so: it creates a stable material definition and a compatible base-card template. It does not calculate transformation kinetics, phase flow stress or V-Gleeble flow surfaces, and it is not a calibration claim. Each simulator then resolves the physics it needs and reports unavailable or fallback states explicitly. See Using your own chemistry.
Why the gates are there#
Read as friction, these gates are annoying. Read correctly, they are the product refusing to do three specific bad things.
A simulation is not free. It occupies a solver, produces a numbered, stored artifact, and — this is the part that matters — produces a number somebody may act on. A run against a material you did not intend is worse than no run, because it looks like an answer.
The gates also stop the agent being over-helpful. It is explicitly forbidden from running a simulation "to demonstrate" or "to be helpful": creating, loading, modifying, comparing, listing or saving a material is not a request to simulate. And one request runs one simulator — asking for a CCT diagram does not authorize a heat treatment or a Gleeble test alongside it.
Finally, they keep the interpretation visible. The card is the moment you see what the agent understood from your prose, before the solver spends time on it.
Long runs survive you closing the tab#
A simulation started in a turn keeps running on the server after the browser disconnects. When you come back, the client reattaches and replays the buffered events, showing a "Resuming simulation from background..." banner while it catches up.
Two practical limits: the replay buffer is held in the backend process, so it does not survive a backend restart, and a finished run is retained for replay for ten minutes. After that the run itself is still there — you read it from the run history rather than watching it stream.
While a simulation is still pending, the agent will tell you the operation was accepted and nothing more. It will not report phase fractions, plots or conclusions for work that has not finished.
Runs and artifacts persist and are versioned#
Each simulation creates a numbered run in the session — run_001, run_002, and so on — stored under a run-scoped path of the form session/<session id>/run_001. Versions are allocated atomically and never reused, so a run number always refers to exactly one execution, forever.
You browse them by asking, not by hunting through a file tree:
List my previous runs
Show me the hardness from run 2
Plots come back as signed URLs attached to the results. The agent never touches the filesystem and never calls a plotting tool directly. See Sessions, runs and artifacts.
Correcting and refining#
Follow-up turns are the normal way to work. The session keeps the active material and the run history, so you can iterate without restating context:
Now run the same thing at 100 °C/s
Change the carbon on my active material to 0.25%
Compare my material with DP600
The agent is seeded with a bounded slice of the conversation for continuity — the last eight turns, truncated, by default. Long conversations therefore do not carry every detail forward in the text. If you are referring to something from far back, restate it or point at the run number.
If the agent misreads a card, say what is wrong in the next message rather than editing around it. Re-issuing the card is cheap; a wrong run is not.
What "session" means#
A session is one conversation and everything attached to it: its messages, its active material, and its numbered runs. Signed in, your first turn on the home page moves the URL to /sessions/<id>, and that URL is the conversation from then on. Runs are scoped to the session, which is why "run 2" is unambiguous inside one conversation and meaningless outside it.
Guests get the chat and nothing else — no history sidebar, no run browser, no materials pages. Signing in adds persistent history, saved runs and artifact storage. See Guests and limits.
When a capability is switched off#
In a workspace, an admin can disable individual simulators or the material knowledge base. When that happens the agent does not pretend the feature never existed: it acknowledges the capability, says it is disabled for this workspace, and points you at your admin. In the transcript the configuration card is replaced by a notice reading "Simulator name is disabled for this workspace. Ask your admin to enable it."
Workspace roles matter too — a viewer cannot run simulations. See Workspaces and roles.
Next#
Put the model to work: Compare two grades is the shortest useful thing to try after your first run, and Known limits is worth reading before you rely on any number. When a reply is a refusal or a confirmation request rather than a result, Common problems explains what each message means.