Flows
Conversations that cannot go wrong.
A prompt asks the model to follow your steps. A flow makes it. Define the steps, the data each one must collect, and the tools it is allowed to touch; the engine drives the transitions, refuses to save a flow that dead-ends, and — in strict mode — replaces an answer that skipped a required field with the question it should have asked.
2
flow modes
5
transition kinds
0
LLM calls to simulate
1
step the engine guarantees
Why a flow
Asking the model to follow steps is not the same as making it.
You can write “always get the order number before offering a refund” in a system prompt, and it will mostly work. Mostly is the problem. A flow moves that guarantee out of the prompt and into the engine, where it is a state machine rather than a request.
What a prompt gives you
An emergent flow. The model usually asks the right question, usually in the right order, and usually does not offer the refund before it checked. Every one of those usuallys is a support ticket.
What a flow gives you
A current step, a goal injected as its instruction, a tool allowlist for that step, and transitions the engine evaluates. The path is not suggested. It is driven.
Where it lives
A flow attaches to a bot or to an agent group. The dashboard never writes it directly — the engine validates and stores it, so what you saw in the builder is what runs.
Anatomy of a step
Five things a step decides, before the model says a word.
A step is not a paragraph of hope. It is a small contract: what to achieve, what to collect, what may be touched, who handles it, and where the conversation can go next.
FLOWS / REFUND REQUEST · SUPPORT BOT
strict · 6 stepsAssess eligibility
Goal — injected as this step's instruction
Look the order up and decide whether it is inside the return window.
Must collect
—
Tools allowed here
orders.lookup
Transitions — first match wins, otherwise stay
A goal
What the bot is trying to achieve right here.
Injected into the system prompt as this step's instruction.
Data it must collect
The fields this step cannot finish without.
Reuses your bot's existing collection field keys.
The tools it may use
All of them, none of them, or an explicit list.
A step that should not be refunding money cannot reach the refund tool.
The agent that handles it
For a group flow, which sub-agent owns this step.
Routing becomes a property of the step, not a hope about the router.
Its exits
The transitions out, evaluated in order.
First match wins. If nothing matches, the conversation stays put.
Five transitions
The edges are evaluated in order. First match wins.
If none of them match, the conversation stays exactly where it is — which is the honest behavior, and the reason a flow never silently teleports a customer into a step you did not intend.
always
Move on unconditionally, as soon as the turn ends.
greet → ask_reason
data_complete
Move on once every field this step had to collect is actually collected.
identify → assess, once order_id and email exist
intent
Move on when the customer's classified intent matches.
decline → escalate, when they ask for a human
condition
Move on when an expression over the turn's context evaluates true.
assess → refund, when days_since_delivery <= 30
tool_result
Move on when a specific tool ran successfully this turn.
refund → done, once refunds.create succeeds
Strict vs guided
A spine, or a cage.
Both modes drive the same state machine. What changes is what happens when the customer has not given you what the step needs.
The missing field is a wall, not a suggestion
Strict adds a real enforcement gate. If a required field is still missing at the end of the turn, the model's answer is replaced with one bounded question — after the model has run, not by asking the prompt nicely.
This is the point of the whole feature: a prompt instruction improves behavior, but it is not an enforcement boundary. A gate in the engine is.
Build, validate, simulate
Watch the edge it takes before a customer does.
The builder pairs the step list with a canvas of the graph, live validation, and a simulator that runs the real transition logic without spending a single token.
Simulate before anyone sees it
Dry-run the flow turn by turn with no LLM call and no backend round-trip. The simulator mirrors the engine's transition evaluator, so the edge it takes is the edge production takes.
Validation that blocks the save
Unreachable steps, transitions to steps that do not exist, an intent edge with no intent, a condition edge with no expression — these are errors, and the engine re-validates on save.
Warnings for the traps
A step that stalls with no way out. Edges stranded after an “always”. An unconditional self-loop. A terminal step with transitions that runtime will ignore anyway.
Versions you can go back to
Every save keeps the prior revision with its full step list, so a flow that regressed can be compared and restored rather than reconstructed from memory.
The builder and the engine cannot disagree
The validator mirrors the engine's own checks and the engine re-runs them on save. A flow that could dead-end a customer never reaches production.
Where people drop
The step where they give up is a number, not a hunch.
Because the conversation has a defined shape, it has a funnel. Flow analytics count what happened at every step and on every edge.
Runs and completions
How many turns hit this step, and how many conversations reached the end of the flow at all.
Advanced vs stayed
The ratio that tells you a step is asking for something people will not give.
Edge counts
Which transition actually fires in the wild — and which one you designed but nobody ever takes.
Back into the loop
A step people stall on is a prompt to rewrite, a field to drop, or a test case to add.
Access and plans
Flows are on every plan.
Determinism is not an enterprise upsell — a bot that refunds the wrong customer is everybody's problem. What scales with the plan is how many flows you keep.
Free
1 flow
Taste the feature on your one bot
Lite
10 flows
Enough for a real product surface
Pro
Unlimited
Flows on every bot and group
Team
Unlimited
Flows on every bot and group
Enterprise
Unlimited
Flows on every bot and group
FAQ
What the engine guarantees, plainly stated
The difference between a conversation that usually goes right and one that cannot go wrong.
How is a flow different from just writing it in the prompt?
A prompt asks the model to follow steps. A flow is a state machine the engine drives: it decides the current step, injects that step's instruction, restricts that step's tools, evaluates the transitions, and advances. Prompt instructions improve behavior; they are not an enforcement boundary.
What happens if nothing matches?
The conversation stays on the current step. Transitions are evaluated in order and the first match wins, so a flow never silently teleports somewhere you did not define.
Can a flow stop the bot calling the wrong tool?
Yes. Each step declares its tool access as all, none, or an explicit list, so a step that has no business issuing a refund simply cannot reach the refund tool.
Does a flow work with a group of agents?
Yes. A flow can attach to an agent group instead of a single bot, and each step can name the agent that handles it — so which specialist answers becomes a property of the step rather than a hope about the router.
Can I test a flow without spending tokens?
Yes. The simulator dry-runs the flow with no LLM call and no backend round-trip. Condition expressions are evaluated server-side at runtime, so in the simulator you set their truth value yourself instead of being shown a guess.
How do I know where people are falling out?
Flow analytics report per-step runs, how many advanced, how many stayed, and how many conversations completed — plus the count on every edge. The step where people stall is a number, not a hunch.
Stop hoping it follows the steps. Make it.
Define the steps, restrict the tools, let the engine drive the transitions, and simulate the whole thing before a customer ever reaches it.