Visual Editor

The workflow editor is a drag-and-drop canvas for building state machines. Access it from the assistant detail page by selecting the Workflow tab and clicking Edit.

The Canvas

The editor displays your workflow as a directed graph. States appear as nodes and transitions appear as arrows between them. The first state added is the entry point (marked with a green border). Terminal states (no outgoing transitions) are marked with a red border.

Adding States

The node palette on the left lists the available state types, organized into three categories:

Interact – States that involve people or LLMs:

Automate – States that run without LLM or human interaction:

Compose – States that structure larger workflows:

Drag a node type onto the canvas to create a new state. Click the state to configure it.

Common Configuration

All state types share these fields:

• Name – A short label for the state (e.g., “Gather Requirements”, “Search Products”)
• Instructions – What the assistant should do in this state. Supports {gathered.field_key} references.
• Required fields – Data keys that must be recorded before the state is considered complete (used by the all_required_answered guard)
• Tools – Which tools are available in this state (in addition to global tools)

Type-Specific Configuration

• Output states – Select the delivery target (conversation, email, or webhook), write the body template with {gathered_data.key} placeholders, and optionally set a subject template and recipients.
• Parse states – Define the fields to extract (name, type, description, required), choose the source text, and add optional instructions for the LLM.
• Approval states – Set the approver addresses, write the request template, and optionally configure escalation (timeout, escalation contacts, max rounds).
• Wait states – Select what to wait for (email reply, webhook, or timer), set a timeout, and optionally enable response classification with custom port names and hints.
• Task states – Configure the task template for participant resolution and fan-out.
• Delegate states – Select the target assistant to hand off to.
• Logic states – Configure the operations to execute (see below).
• Subworkflow states – Select the child workflow, and optionally configure input and output data mappings between parent and child gathered data.

Approval Gates

Any state can be configured as an approval gate by enabling the Require human approval toggle in the state properties. When enabled, configure the Approval contacts field with the email addresses or gathered data references of the people who can approve. See Approval Gates for details on the approval flow.

Retry Policies

States that may fail (e.g., API calls, external integrations) can have a retry policy. In the state properties, set Max attempts and Backoff seconds to control how many times the retry_state tool can re-execute the state.

Configuring Operations (Logic States)

When you select a Logic state, the property panel shows an Operations list. Click Add Operation to append an operation step. Each operation has a type selector and type-specific configuration fields:

• set_data – Key name and a value or template string
• transform – Source key, transformation function, and optional output key
• http_request – URL, method, headers, body template, and output key
• send_notification – Recipients, channel (email/chat/webhook), subject, and body templates
• conditional_branch – A list of conditions (key, operator, value, target state) and an optional default state
• wait – Duration in hours and an optional reason
• loop – Source list key, item variable name, child operations, and optional results key

Operations execute in the order listed. Drag to reorder.

Error Handling

Any state can have an error boundary. In the state properties, expand the Error Handling section and select a strategy:

• None – Errors stop the workflow (default).
• Route to error port – Adds an error output port to the node. Connect it to a fallback state.
• Retry then error port – Retries the state up to N times with backoff, then routes to the error port. Configure max attempts and backoff seconds.
• Ignore – Logs the error and continues through the done port as if the state succeeded.

Named Output Ports

States like Output, Parse, Approval, and Wait have named output ports – colored labels on the right side of the node representing built-in exit conditions. Each port connects to a different target state.

For example, a Parse node shows complete (green) and incomplete (blue) ports. Drag from a specific port to the target state to create the connection. No guard configuration is needed – the state itself decides which port to activate.

Port colors indicate semantics: green for success, red for error/rejection, blue for needs-attention, amber for timeout.

Creating Transitions

For states without named ports (Conversation, Action, Logic, Task, Delegate, Subworkflow), click and drag from the output handle to another state’s input handle to create a guard-based transition. Click the transition arrow to configure its guards.

For states with named ports (Output, Parse, Approval, Wait), drag from a specific port label to the target state. These transitions are port-based and need no guard configuration.

Each guard-based transition can have one or more guards. When multiple guards are present, all must pass for the transition to fire (AND logic). Use a composite guard for OR logic.

Configuring Guards

Select a transition and use the guard panel to add conditions. Each guard type has its own configuration fields:

• all_required_answered – No additional configuration; uses the state’s required fields
• tool_called – Specify the tool name and whether success is required
• data_contains – Specify the data key and an optional regex pattern
• data_equals – Specify the data key and the exact value to match
• data_greater_than / data_less_than – Specify the data key and a numeric threshold
• data_in_list – Specify the data key and a list of allowed values
• user_confirmed – Optionally provide custom confirmation phrases
• llm_judge – Provide a natural language rubric and optionally select the model
• all_tasks_complete – No additional configuration; used with Task states
• external_event – Specify the event key to wait for
• always – No additional configuration
• composite – Select AND/OR logic and add child guards

Global Tools

Click the gear icon in the toolbar to open workflow settings. The Global Tools section lets you select tools that are available in every state. The record_data tool is enabled by default.

Testing

Click the Test button in the toolbar to save, validate, and launch a live test conversation with a debug trace panel showing state transitions, guard evaluations, data flow, and tool calls in real time. See Testing Workflows for details.

Save and Validate

Click Save to persist the workflow. The editor validates the structure before saving and reports errors:

• At least one state is required
• Every non-terminal state must have at least one outgoing transition
• Transition guards must be fully configured
• Task states must reference a valid task template
• Delegate states must reference an existing assistant
• Subworkflow states must reference an existing workflow
• Logic states must have at least one operation configured