The Flow Designer lets you build structured, multi-step AI voice agents using a visual, node-based interface. Instead of relying on a single prompt, you design a conversation graph where each node handles a specific task—whether that’s collecting information, making decisions, or executing actions.
Flow Designer agents are built on deterministic conversation logic, meaning the conversation follows a predictable, step-by-step path. This approach offers several advantages:
In practice, choose Flow Designer when you need explicit control over the path a call can take, and choose Single-Prompt Agents when flexibility matters more than deterministic routing.
Not sure which approach is right? Check out our detailed comparison guide to choose between one mode or the other.
Deterministic logic means your agent follows explicit, pre-defined rules rather than making autonomous decisions. Think of it like programming: “If condition A is true, go to step B. Otherwise, go to step C.”
Benefits:
When to use deterministic logic:
When to use non-deterministic logic (Single-Prompt):
Click on the Plus icon to insert a new node into your flow.
Nodes are the building blocks of your conversation flows. Each node represents a specific action or decision point in your conversation. Here is a summary of all the available node types:
The most common build pattern is:
As your agent grows and your use cases expand, conversations naturally become more complex. That’s why the Multi-Agent System exists—it helps you keep your flows organized, scalable, and easier to manage as your product or customer interactions evolve.
How it helps you:
Example: Create a “Pricing Questions” subflow. Use the Trigger Subflow node whenever a user asks about pricing—the agent enters the pricing subflow, answers their questions, then automatically returns to continue the main conversation.
Learn more about it in the Multi-Agent System documentation.
This example demonstrates how different node types work together to create a complete conversation flow. The agent collects information from the user (party size, date, time), checks availability via an API call, handles both success and failure scenarios with branching logic, and confirms the reservation—all while handling potential objections through Global Settings.
Goal: Allow users to book a table at a restaurant
What this flow demonstrates:
The Conversation node is essential for collecting variables that you’ll reference later in your flow. It waits until the user provides the requested information before continuing, ensuring you have the data you need for branching logic, API calls, or personalization.
For example, if you need to route users based on their department preference, first use a Conversation node to collect that information, then use a Branch node to route them accordingly.
Here’s a helpful pattern to keep in mind when building your flows:
Key principle: Always use a Conversation node between your greeting and any branching logic. This ensures the system actively waits for and stores the user’s response.
Why the incorrect pattern fails:
Learn more about how the Conversation node works here.
Key reminders before you build:
No. Use Conversation nodes only when you need to store the user’s response for later use (e.g., branching logic, API calls, or final confirmation). For simple questions that don’t require storage, you can handle them in the Global Settings or use a Message Node for one-way communication.
No. You must choose one approach when creating your agent. However, you can create multiple agents—some using Flow Designer and others using Single-Prompt—and coordinate them using call transfers or webhooks.
There’s no hard limit, but for maintainability, we recommend keeping individual flows manageable and readable. For larger workflows, use the Multi-Agent System to break logic into smaller, reusable sub-flows.
Nodes themselves can’t be directly reused, but you can use the Multi-Agent System to create reusable sub-flows that can be triggered from multiple parent flows.
This is one of the most common mistakes! The Greeting Message node delivers its message once and immediately moves to the next node—it doesn’t wait for or capture user input.
If you try to branch right after greeting, there’s no data for the Branch node to evaluate. The correct pattern is:
[Greeting Message] → [Conversation] → [Branch]
The Conversation node waits for input and stores it, giving the Branch node something to evaluate.