The model assistant

August 26, 2026

Every model so far has been built by hand: right-click, fill in a builder, click Create. The model assistant is a second way in: describe a change in plain language, and it proposes the same nodes, states, relationships and equations you'd otherwise author yourself, for you to review before anything actually changes.

This page uses the bundled Local demonstration configuration, which needs no API key. It's a real, working assistant configuration, just not backed by an external model. Everything shown here (the proposal structure, the diffs, the apply/discard flow) works identically with a real provider: Ollama running locally, or a hosted OpenAI, NVIDIA, Hugging Face or Gemini configuration.

Describing a change

Open the assistant from the toolbar and describe what should change, in words: "Add an ambient boundary at 298 K and connect it to the battery with a conductance of 15 W/K."

The assistant's proposal for a new ambient boundary
Native validation passed · 5 changes: every change is a discrete, individually-labeled step, not an opaque model replacement.

The proposal is never applied silently. It's broken into individual ADD/UPDATE steps (here, a new node, a state on it, a relationship connecting it to the battery, a parameter and the equation that uses it) and validated against the same native validator every hand-built model goes through. Revise proposal re-asks with adjusted wording without losing the conversation so far.

Collapsing without losing it

The panel collapses to a small status card, so a pending proposal doesn't have to block looking at the rest of the canvas.

The assistant panel collapsed to a compact status card
"Proposal ready to review": the canvas underneath stays fully interactive.

Applying it

Apply changes commits every step in the proposal as one transaction: one undo, not five.

The canvas after applying the proposal
4 nodes, 4 relationships: the ambient boundary and its connection to the battery, exactly as described.

Updating a value, and reading the diff

A request doesn't have to add anything. Asking to change an existing value produces a proposal too, shown as a direct before-and-after.

A proposal updating the battery's initial temperature
initialValue 353.2 → 325: an explicit diff, not a description you have to trust.

Worth noticing here: an Assumptions section ("The requested temperature applies to the initial state, not a live simulation value"). The assistant states the interpretation it chose for an inherently ambiguous request, rather than silently picking one. The full conversation stays visible above the current proposal, so a follow-up request reads in context rather than starting fresh each time.

Where to go from here

Everything on this page still started from a plain-language description you wrote. The last piece works in the opposite direction: recovering a causal graph from data instead of from a description of one.


Follow Konjugate on LinkedIn for updates.

Comments