Assistant node, and the Control tab as one conversation (openpanel V5)

run_turn takes its tools, system prompt and tool caller; the chat passes the
MCP tools as before. The assistant node offers one tool per wired target,
reads its other inputs as context, streams its reply a sentence at a time,
warms the provider on `listening` and says so when the provider is not there.
Completions share the per-server HTTP client. wren replies when nothing reads
`unhandled`, stt shows a note when nothing was heard. /ai/control lists one
conversation per entry node with the messages to watch.

docs/code/agents.md

@@ -67,11 +67,16 @@ works without it.
 
 ## Control
 
-A live [Wren node](../reference/node-types.md#wren) with both `prompt` and
-`actions` wired adds a **Control** tab to the chat. It uses the node's local
-model and needs no assistant provider.
+A live [Wren](../reference/node-types.md#wren) or
+[Assistant](../reference/node-types.md#assistant) node with its `prompt` and a
+`reply` or `actions` wired adds a **Control** tab to the chat. Wren uses its
+local model, the Assistant node the provider above.
 
-Choose a node, type a command, and inspect the reported actions: target
-message, value, confidence, and whether each action was applied.
-The node's `apply` and `min_confidence` settings decide whether it writes
-to devices. Control conversations stay in the browser and clear on reload.
+Choose a conversation and type a command. It goes out on the node's prompt,
+which is where a `stt` node writes what a device heard, so typed and spoken
+commands are one conversation: the words heard so far, the command, each
+reply, and the reported actions with their target message, value and whether
+each was applied. A node whose prompt is another's `unhandled` answers in that
+node's conversation. Wren's `apply` and `min_confidence` settings decide
+whether it writes to devices. Control conversations stay in the browser and
+clear on reload.

docs/interface/index.md

@@ -45,8 +45,9 @@ broker topic, URL or other external target share a neuron; computation nodes
 appear individually. Messages connect them, and activity makes them pulse.
 
 A problem keeps the affected neuron's label visible. A
-[`wren` node](../reference/node-types.md#wren) also adds a chat button for its
-[Control tab](../code/agents.md#control).
+[`wren`](../reference/node-types.md#wren) or
+[`assistant`](../reference/node-types.md#assistant) node also adds a chat
+button for its [Control tab](../code/agents.md#control).
 
 ### Flows and dashboards
 

docs/reference/node-types.md

@@ -398,7 +398,9 @@ applied. Keep `apply=false` while checking how the model interprets commands.
 
 `reply` is one sentence saying what was applied, such as "Kitchen light on."
 or "Garage light on in 5 minutes.". When nothing was applied, `unhandled`
-carries the prompt instead, for something else to answer.
+carries the prompt instead, for something else to answer, such as an
+[Assistant](#assistant). When no node reads `unhandled`, `reply` says "Sorry,
+I can't do that yet." instead, so a spoken command never goes unanswered.
 
 A call with a delay ("in 10m") is held by the engine's work queue, like the
 Debounce node's second value: it survives a restart where the queue is in
@@ -415,6 +417,53 @@ They are reported but cannot receive writes unless wired.
 
 The chat's [Control tab](../code/agents.md#control) sends commands by hand.
 
+### Assistant
+
+**`assistant`** — answer a request with the instance's AI provider, acting only
+on what is wired to it.
+
+| Input | Type | Notes |
+|---|---|---|
+| `prompt` | `str` | the request, such as a Wren node's `unhandled`; it runs the node |
+| `listening` | `bool` | optional; turning true opens the connection and loads the model while the request is spoken |
+| any other | any | read as context when a request arrives, as `outside_temperature: 12.5` |
+
+| Output | Type | Notes |
+|---|---|---|
+| `reply` | `str` | the answer, one sentence at a time while the model writes it |
+| `actions` | `list` | one record per value set: `message`, `value`, `applied`, `delay_s`, `call` |
+| any other | `bool`, `int`, `float` or `str` | a **target**: one tool, named after its port, taking a `value` of its type |
+
+| Setting | Default | Notes |
+|---|---|---|
+| `model` | empty | the model to ask; empty asks the instance's |
+| `extra_body` | `{"temperature": 0, "reasoning_effort": "none", "keep_alive": "30m"}` | added to every request as it is |
+
+It asks the provider set under **Settings → Assistant**. As for Wren, the
+wiring is the allowlist: the model is offered the targets and nothing else,
+never the tools the chat's assistant uses. Its instructions list the context
+inputs and what each target holds now. A target is set the moment the model
+calls its tool, and a request may take three rounds of tool calls.
+
+Every request ends in a reply:
+
+- When no tool fits or the request makes no sense, the model says so, as
+  "Sorry, I can't do that.".
+- When no provider is set up, the connection is refused, it takes over 3
+  seconds to connect or 15 seconds to answer, the reply is "The assistant
+  isn't available right now." and the node reads degraded. A model that has to
+  be loaded first can take about 10 seconds.
+
+The default `extra_body` is for Ollama. `temperature` makes the same request
+do the same thing each time. `reasoning_effort` turns thinking off through
+Ollama's OpenAI-compatible API, which ignores Ollama's own `think`.
+`keep_alive` keeps the model loaded for 30 minutes after the last request
+instead of 5. Drop a field the provider refuses.
+
+In a voice flow, `stt` writes the prompt of a Wren node, Wren's `unhandled` is
+the assistant's prompt, both `reply` outputs go to `tts`, and the device's
+`listening` warms the assistant.
+
 ### Speech to text
 
 **`stt`** — turn a microphone's audio into text, through a speech server.
@@ -435,8 +484,9 @@ utterance is one realtime transcription session (`{url}/v1/realtime`), opened
 when `listening` turns true or at the first chunk and committed when it turns
 false. A clip is sent whole to `{url}/v1/audio/transcriptions`. The node
 returns at once and publishes when the server answers, since a device's next
-chunk waits for it. An utterance that fails, or gets no chunk for 10 seconds,
-publishes nothing and is logged.
+chunk waits for it. An utterance that comes back empty, fails, or gets no
+chunk for 10 seconds publishes "Didn't catch that." on `partial` alone, so a
+caption shows it and nothing speaks it. A lost one is logged.
 
 `listening` has to hold a value before a chunk wakes the node. Declare it as a
 flow input with the initial value `false` when a device may never send it,