Dialogue (Conversations)

What it is

Strategic, multi-turn conversations with the model that double as the main on-ramp for turning an idea into approved work. A conversation can read the system's live state and, when you ask it to act, either propose work for your approval or — with the write tier enabled — take a bounded action.

Operator surface

  • conversation_create, conversation_send, conversation_list, conversation_get, conversation_complete — the conversation lifecycle. Each conversation is tagged with a Track (Governance / Research / Planning / Build) for context.
  • conversation_branch — fork a conversation to explore an alternative.
  • mission_propose — the current bridge into execution. On a turn where you ask for a feature or a change, the model calls this (instead of describing the work in prose) to raise one approval request. It creates an unpublished workflow draft plus a single Approval attention request that lands in the Decisions queue — no live mission and no published workflow. You review and approve — and approval then creates the mission automatically (see below).
  • dialogue_propose_mission — the older, simpler bridge, still present: it creates a pending mission directly, linked to the conversation, for you to approve. No workflow draft is attached.
  • dialogue_check_mission, dialogue_get_mission_results — track a proposal, and pull a completed mission's task outcomes back into the conversation to synthesise a reply.

DialogueController and ConversationExportController back the REST / dashboard chat surface.

How it works

Conversations are stored as Conversation + ConversationMessage rows, tagged with their Track. Model calls made during a conversation route through the LLM layer under their own dialogue call site (e.g. Dialogue:GeneralDialogue, Dialogue:MissionAssistant) and are cost-attributed to the conversation. Anything the model creates carries the originating conversation id (OriginConversationId), so a proposal or a mission is always traceable back to the dialogue that spawned it. Dialogue can run against an in-process direct model provider or a sidecar, depending on the resolved preset and backend.

What the model is allowed to do (tool tiers)

The tools a conversation can call are tiered by how much they can change. By default Core serves them in-process (no separate Bridge process required):

  • Read tier — always available. Status, list, and get tools (missions, tasks, decisions, costs, pipelines, …) run directly. A few read-named tools that actually fan out to expert or model calls — and so cost money — are held back until an operator opts in.
  • Act / write tier — off by default, twice gated. A curated allowlist of create/update tools (mission_create, task_create, decision_create, mission_add_task, …) is served only when a deployment-level switch (Dialogue:InProcessTools:WriteEnabled) admits it. Even then a tool runs only when the tenant has turned write tools on (a toggle on the Features settings screen — the refusal message points there) and you explicitly asked for the action (an execution-command intent) or a live session grant authorises it. On an ordinary feature-request turn it does not execute — the model surfaces the proposed action and a suggestion is recorded instead. The dispose verbs (*_approve / *_reject / *_respond / *_promote) are excluded outright, so a conversation can never approve or resolve a human-gated item — including its own proposals.
  • Propose tier — mission_propose. Served under the same deployment switch as the write tier, so on a deployment with write tools off you will not see it at all. What proposing skips is the execution gating: it mutates nothing directly (it only raises an approval request), so neither the per-tenant toggle nor the explicit-intent check applies — even a plain feature-request turn is allowed to propose. The system proposes; the human disposes.

What approving a proposal does — and doesn't

The proposal lands in the Decisions queue carrying the proposed mission spec and a handle to the unpublished workflow draft, with three options: Approve and create, Request changes, Reject. Choose Approve and create and the mission is created for you: a resolution handler watches for the approval and materialises the mission through the same path mission_create uses — no manual re-entry, and exactly one mission per proposal even if the approval fires twice.

What approval deliberately does not do is publish (or attach) the workflow draft. If the model could not sketch an execution plan, the draft is a placeholder graph that would fail publish validation — so the draft always stays a draft for you to review, complete, and publish yourself. In short: approving creates the mission automatically; publishing the workflow remains your deliberate act.

If a feature request never reaches a formal proposal, the conversation still records a suggestion (a MissionSuggestionRecord row) tied to the conversation, so the idea is captured for later review rather than lost.