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.

The panel also opens by itself in two situations:

• New blank workflow - the chat opens in build mode with the prompt "Let's build your workflow" and the input placeholder "Describe your workflow…". Describe your goal; the assistant first shows a plan card summarizing what it intends to create - click Build it to let it start adding nodes. You can also just close the panel and build manually.
• Workflow created from a template - the chat opens in adapt mode and walks you through customizing the template: it asks one focused question at a time, configures nodes for your case, and checks that required resources are in place.

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>}}
• Previous run output - so {{steps.<id>.output.<field>}} references point at fields that actually exist

If a required resource is missing, the assistant emits a setup card with an inline form instead of telling you to leave the chat: an AI provider key (pick the provider, paste the key), an MCP server (a form generated from the server's config schema), or a global variable (value + Save) - everything is saved directly from 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 based 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 (Accept / 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; expand a card to see the details and its Accept / Reject buttons.
• 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 with a "N pending changes" counter - one click applies everything in order, with structural changes batched and re-rendered as a single canvas update.
• Sensitive changes (e.g. touching credentials or destructive edits) carry an amber Review badge and are always expanded, so you see the diff before Apply all can include them - Reject the card if you don't want it.

You stay in control: cards are never auto-applied. You can also ask the assistant to revise a proposal before accepting it.

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 an earlier step, the assistant pre-fills the {{steps.<id>.output.<field>}} reference for you.
• If an earlier step hasn't run yet, the field stays empty and is marked so you can fill it in.

Checks before "ready to run"

Before the assistant tells you a workflow is ready to run, it checks that everything it needs is actually in place. The check happens when it proposes the change, not after you apply it, so you don't accept a card and discover a missing prerequisite later.

It surfaces:

• MCP servers the workflow needs but that aren't configured or assigned to this workspace
• Tools that require credentials your organization hasn't set yet
• Global variables referenced in node configs but not yet in the workspace's Global Context
• Forms used as a trigger but not enabled on the workspace

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

Slash commands

Type / in the input to open a command dropdown ("Type / for commands" is shown as a hint below the input); use Tab to autocomplete.

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

Node context chip

Click any node on the canvas while the chat is open and it attaches as a compact chip above the input - the assistant then sees exactly that node as context for your next message. The chip has three one-click actions - Explain, Analyze, and Debug - scoped to that node, and an × button to detach it. The chip always reflects what the assistant will actually see: chip attached means the node is in context, chip dismissed means it isn't.

Usage limits

Assistant usage is metered per plan: each organization has a daily token budget (resets at midnight UTC) and each user a messages-per-hour limit. When either is exhausted the chat replies with a clear message about when it resets and what to do. Limits depend on your plan.

Members with read-only access to a workflow can still chat - the assistant answers questions and explains, but won't propose changes to the workflow.

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.