Steps
A workflow is made up of steps. Each step does one thing: send a message, search your knowledge base, ask the AI to decide, or route the conversation based on a condition. Steps connect together to form the full flow your assistant follows.
There are four types of steps: Prompt, Action, Branch, and Ref.
Prompt
Section titled “Prompt”A prompt step is where the AI does its thinking. It sends context to the AI model and gives it a set of tools to choose from. The AI reads the conversation, considers the context you’ve provided, and picks the best tool for the situation.
A prompt step has four parts:
| Part | Purpose |
|---|---|
| Preamble | Sets the AI’s personality and role. This is the main instruction that tells the AI who it is and what it should do. |
| Rules | Specific constraints the AI must follow, like “only answer from the provided sources” or “keep responses concise.” |
| Tools | The actions the AI can choose between. Each tool has a name, description, and follow-up steps. See Tools for details. |
| Postamble | Extra context injected at the end, like search results from your knowledge base. Dynamic information gets added here. |
Example: You want your assistant to answer product questions. The preamble says “You are a customer support assistant for Acme Corp.” The rules say “Only answer from the provided sources” and “Be concise.” The tools are answer (reply to the customer) and escalate (hand off to a human). The postamble contains search results from your knowledge base.
When the AI runs this step, it reads the customer’s message, reviews the search results in the postamble, and decides whether to answer or escalate to a human.
Action
Section titled “Action”An action step performs a concrete operation without AI involvement: send a message, search your knowledge base, escalate to a human, present choices, update user info, jump to another workflow, or run custom code. See Actions for the full list.
Branch
Section titled “Branch”A branch step routes the conversation down different paths based on a condition. The workflow checks something about the customer or the conversation and takes the matching path.
Built-in conditions
Section titled “Built-in conditions”These conditions check common things about the customer or conversation:
| Condition | What it checks |
|---|---|
| User has email | Whether the customer has an email address on file. |
| User is anonymous | Whether the customer is unidentified (no external ID). |
| User is identified | Whether the customer has been identified with an external ID. |
| User is verified | Whether the customer’s identity has been cryptographically verified. |
| Conversation has messages | Whether this conversation has any previous messages (useful for distinguishing a greeting from a reply). |
| Conversation has active operator | Whether a human operator is currently assigned to the conversation. |
Each condition evaluates to true or false, and you specify which path to take for each case.
Example: A customer asks to speak with a human. A branch checks User has email. If true, the workflow escalates directly. If false, it first asks the customer to provide their email so the team can follow up.
Custom conditions
Section titled “Custom conditions”For more advanced routing, custom conditions let you check any value using comparison operators.
| Operator | Meaning |
|---|---|
== |
Equals |
!= |
Does not equal |
> >= < <= |
Numeric comparisons |
startsWith |
Text starts with a value |
endsWith |
Text ends with a value |
type |
Value is of a given type (string, number, boolean, object, array, null, or undefined) |
truthy |
Has a value (not empty, null, or false) |
falsy |
Does not have a value |
Example: A custom branch checks whether a search query was provided. If truthy, the workflow runs a knowledge base search before composing the response. If falsy, it skips the search and responds with what it has.
A ref step points to another step that already exists in the workflow. Instead of duplicating a step that’s used in multiple places, you create it once and reference it wherever it’s needed.
Example: Both the “answer” path and the “hypothesize” path in a support workflow end with the same escalation logic. One path defines it, the other uses a ref to reuse it.