AI Chat Assistant

The AI Chat Assistant is an interactive panel in the workflow editor that builds, edits, and explains your workflows through conversation. It's the same surface for "create a new automation from scratch", "adapt this template to my case", "what's wrong with this run?", and "review this workflow for issues" - the assistant detects which mode you're in from the message you send.

Accessing the Assistant

Click the Sparkles icon in the editor toolbar to open the Chat panel on the right side of the canvas. It uses the same slot as the Inspector and Execution Panel - only one is visible at a time, and switching tabs preserves panel state.

What the Assistant can do

You can switch modes mid-conversation - the assistant follows the latest user intent rather than locking into a behavior.

Workspace awareness

Every reply is grounded in the resources actually configured for the current workspace:

• AI Providers - only models from connected providers are suggested
• MCP Servers - only tools from servers assigned to this workspace; full param schemas are loaded
• Knowledge Bases - surfaced for Agent context or rag Action nodes
• Forms - surfaced as triggerType: "form" candidates with their field shapes
• Templates - clone-ready workflows from the org library
• Global Variables - referenced via {{global.<key>}}
• Last Execution Outputs - real shapes from the most recent successful run, used to write correct {{steps.<id>.output.<field>}} references instead of inventing field names

If a required resource is missing, the assistant emits a request_setup card with an inline form (Save button included) instead of telling you to leave the chat.

Where values live - the lifecycle taxonomy

When the assistant needs a value (a project key, an API base URL, a date range, a model name), it picks where the value belongs from a fixed five-row table - the choice depends on the value's lifecycle, not on what's easiest to wire up:

If the lifecycle is ambiguous ("is this workflow always for one project, or many?") the assistant asks one clarifying question before committing - it doesn't default to globals just because they're easy. Globals that should have been trigger inputs leak across runs and force a separate workflow per variant.

Action cards (Apply / Apply all)

The assistant doesn't write changes silently. Every mutation it proposes - adding a node, updating a config, creating a global variable, requesting a missing setup - renders as a compact action card in the chat:

• The card shows the operation, the target node, and a diff/summary of what will change.
• Click Apply to execute that single action.
• When the assistant emits multiple cards in one turn (e.g. "add three nodes and wire them up"), the chat shows an Apply all button at the top of the group - one click, in order, with structural changes (add_node, add_edge, update_node) batched and re-rendered as a single canvas update.

You stay in control: cards are not auto-applied. You can also reject a card or ask the assistant to revise it before applying.

Tool params - structured, not free-form

Tool / MCP-server actions in the chat use structured parameter forms rather than free-form JSON. When the assistant proposes a mcp Action node, the card surfaces the tool's full param schema with typed inputs, defaults, and inline validation.

• For params whose values come from upstream output, the assistant pre-fills {{steps.<id>.output.<field>}} references using last-run inference - it inspects the real output shape from the most recent successful execution rather than guessing field names.
• If a referenced upstream node hasn't run yet, the field stays empty and is marked so you can fill it in.

This means the configurations the assistant proposes are usually runnable as-is: the references resolve against shapes the executor has actually seen.

Propose-time validation

Before the assistant tells you "ready to run", it calls validate_requirements as a final checkpoint. The check runs at propose time - not at click-Apply time - so you don't apply a card and then discover later that a prerequisite is missing.

The validator surfaces:

• MCP servers referenced by the proposed graph but not yet configured / not assigned to this workspace
• Tools that exist on the server but require credentials the org hasn't set
• Globals referenced in node configs but not yet in the workspace's Global Context
• Forms referenced by triggerType: "form" but not enabled on the workspace

Each item comes back as its own card (request_setup or set_global_variable) with a working save form, so you can resolve everything without leaving the chat.

Determinism

Chat completions use a fixed temperature of 0.3 for tool calls and structured output. Lower temperature gives near-reproducible, schema-conformant tool calls - important when the assistant is editing your workflow rather than writing prose. Conversational replies use the same setting; if you ask the same question twice, you'll get a similar (not identical) answer.

Slash commands

You can also trigger these implicitly - "review this for problems" works the same as /analyze.

Tips

• Reference nodes by name, not internal id: "update the Fetch Data node" beats "update node-3".
• Talk in any language - the assistant answers in the language you wrote the message in.
• One ask per turn beats five. The assistant intentionally proposes one or two changes per reply when adapting a template; let it apply, see the canvas update, then continue.
• For build mode, start with the goal. "When a Slack message contains 'urgent', create a Jira ticket and assign it to me" gives the assistant enough to compose the graph end-to-end. "Improve my workflow" does not.