Skip to main content
example-main A flow is a structured interaction made up of steps, each containing a prompt and one or more actions. You use flows when an interaction requires:
  • Collecting user input (e.g. name, phone number, confirmation code)
  • Performing validation or retries
  • Calling internal or external APIs
  • Routing, handoff, or escalation
  • Following a specific sequence to meet business logic or regulatory requirements
Use individual knowledge base entries for short, factual answers. Use a flow when an interaction needs structure, memory, or logic.

​
How to trigger a flow

There are a few common ways to start a flow. The right choice depends on where you are in the product and how deterministic you need the trigger to be.

​
1) Trigger an existing flow from code

Use this when you are in a function and you want to start a flow deterministically. Example: 
    conv.goto_flow("Reservation flow")
This starts the named flow on the next turn.

​
2) Create a flow from within a knowledge base action

example-main Type /Flow and then use the plus sign (+) to start this process.

​
3) Trigger a flow from inside another flow

Use this when the user is already in a flow and you want to switch to another structured interaction (for example, escalation, payments, identity verification, or a separate task). Typical pattern:
  • You use a Function step (or a transition function) and call conv.goto_flow to move into a different flow
APIs do not trigger flows directly. Instead, flows orchestrate steps, and Function steps can call APIs. If an API result should change the path, you use code to route or start the appropriate flow.

​
How flows work

Each flow is made up of:
  • Steps: Self-contained conversation states, made up of:
    • Text prompts, just like knowledge base entries.
    • Global functions and transition functions: Logic blocks that validate input, call APIs, store values, and move the conversation forward.
That means as each step is sequentially processed, the LLM sees:
  • The current step’s text prompt.
  • A list of available functions with names, descriptions, and arguments.
What the LLM doesn’t see:
  • Previous step prompts.
  • Any system context, unless it’s surfaced in the prompt or state.
Because previous steps are not visible, each prompt must be self-contained. Provide all necessary context and clear guidance in each step.

​
LLM interaction model

When the agent is inside a flow step, this is the input order:
  1. System prompt (includes Rules and About agent configuration).
  2. Any relevant knowledge base entries (if applicable).
  3. The conversation history.
  4. The step prompt (which is appended last).

​
Knowledge base function visibility in flows

To make global knowledge base functions available while a flow is running, set: 
    {
      "llm": {
        "include_kb_functions_in_flows": true
      }
    }

​
Key techniques

​
Connecting steps

In the Flow Editor:
  • Use /Steps in the prompt to connect to the next step
  • Add named transition functions to manage movement between states
  • Use the Flow Functions modal to see all transitions in one place
Always include an exit step in your flow. Un-exited flows can cause hallucinations.
Use descriptive function names like check_reservation_match, not vague ones like step_two — this helps the LLM reason correctly.

​
Standard entity types

Entity types define the kind of information your agent collects from users. They help the system validate and structure input once it has been recognized by ASR.

​
Available types

  • Alphanumeric — any mix of letters and numbers. Useful for booking references or codes.
  • Number — numeric values.
  • Date — calendar dates.
  • Time — clock times.
  • Phone number — telephone numbers.
  • Name — personal names.
  • Address — street addresses or locations.
  • Free text — open-ended responses without validation.
  • Multiple choice — selection from predefined options.

​
Further reading