How the conversation works

It is an agent with tools, not a chat box over a form#

Behind the conversation sits a registry of engineering tools. The Phases agent chooses the appropriate tool, fills in its arguments, and reports what came back. Web chat and the delegated MCP agent share these capabilities; external MCP clients normally reach them through the single ask_phases entry point.

Which tools you actually get depends on your workspace. Every chat tool except Listed runs and Inspected run sits behind a feature flag an admin or an operator can switch off. The Tool reference carries the full list with the flag each one needs.

You can see the tools working. 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, and one for each of the rest. A thin rail across the top of the card carries its state: it sweeps while the tool runs and settles green when the tool succeeds.

A card in the transcript is a tool that really ran and succeeded. Failures are the asymmetry. In production a failed tool's card is withheld entirely — any failure, not only an internal diagnostic — and what you get instead is the one-sentence message below. So the absence of a card is not proof that nothing was attempted.

That visibility is still 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. If durable recording succeeds, the application adds a trackable reference:

The operation could not be completed. Diagnostic details were retained. Reference INC-ABCDEF123456.

If recording is unavailable, it says only "The operation could not be completed" and does not overpromise.

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, and heat treatment, CCT and V-Gleeble use it automatically when you do not name a grade, so you can run several experiments on the same steel without re-stating it.

RSW is the exception. Its plates must always carry one of the twenty RSW-supported grades, so an active custom material is mapped onto its supported base grade rather than used directly. Your own chemistry rides along only when the microstructure stage is switched on, and that stage is off by default — the shipped rsw-params card carries "micro_enabled":false. Asking for a session plate material with the microstructure stage off is refused rather than quietly downgraded:

Plate materials from a previous run are only used when the microstructure stage is on. Retry with micro_enabled=true, name the run version in session_material_version_top/bottom, or drop use_session_material to weld on the built-in grade properties.

If you want your own chemistry inside a weld, turn microstructure on and check the card before you run. Otherwise the weld uses the plate grade's own properties.

Rule two: confirmation before anything expensive#

Confirmation is not one gate but a family of them, and they exist for different reasons.

The simulation parameter cards. 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 material card. Creating, modifying or saving a chemistry goes through a material-params card that shows the composition before anything is written.

The flow-stress card. A flow-stress prediction is confirmed through its own card — material, ASTM grain size, bainite model, maximum plastic strain and temperature — and the tool is called only after you submit it. The agent is forbidden from calling it off the back of any other request; loading a material or running a simulation does not authorize a flow-stress calculation.

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.

Exact-phrase confirmations. Three actions need you to type back a specific phrase the tool returned, because a paraphrase is too easy for a model to manufacture: running a published workspace simulator, publishing a simulator draft, and approving an RSW process window. The first call of each pair only previews; the second repeats the unchanged call with confirmation set, and the agent may never do both in one turn. See Running a custom simulator.

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, replays what happened while you were away, and shows the result.

Simulations run through durable execution: their state and their event history live in the database, not in the web process, so a run survives a backend restart and can be replayed long after it finished. A durable run does have a deadline instead — six hours for heat treatment and CCT, twelve for V-Gleeble, twenty-four for RSW — and an expired run is terminal.

A legacy in-process path still exists for deployments that have not moved, and it is the one with the short memory: its replay buffer lives inside the backend process, does not survive a restart, and keeps a finished run for ten minutes. If you meet that path, the banner reads "Resuming simulation from background…" rather than naming a durable status.

Either way, once the replay window is gone the run itself is not: you read it from the run history instead of watching it stream. While a simulation is running covers the status vocabulary, cancellation and reconnection in full.

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, and that is enforced by the application rather than left to the model's manners.

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 and Workspace limits and features.

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.