Prompt & flow builder

Design branching phone conversations as a visual flow - every node, transition, and setting explained in plain language.

Some calls are a straight line: say the pitch, handle a couple of questions, wrap up. A single-prompt agent handles those beautifully. But real conversations branch. “Are you the account holder?” → if yes, continue; if no, end politely. “Interested?” → qualify, then book; not interested → take a callback time. When one instruction sheet can’t hold all those forks, you build a flow instead.

A flow lays the call out as a map: boxes (we call them nodes) joined by arrows (transitions). Each node is one step of the conversation with its own short instruction; each arrow is a rule for when the agent moves from one step to the next. The agent starts at the greeting and walks the map, turn by turn, based on what the caller actually says.

This is the flow builder (you’ll also see it called the multi-prompt builder). It’s a visual editor: drag nodes around a canvas, wire them together, and click any node to edit it in the panel on the right.

Single prompt or multi prompt? You pick this once, when you create the agent. Single prompt = one instruction set for simple, repeatable calls. Multi prompt = a flow of connected prompts that branch mid-call. If you’re not sure, start single - you’re not locked in, and most calls never need a flow.

How you get here

When you create an agent and choose Multi prompt, it opens straight into the flow builder - there’s no separate form to fill out first. You’ll land on a tiny starter flow: a Greeting node wired to a Close node. That’s a complete, publishable call (it says hello and hangs up), and it’s your starting point. From there you add nodes and wire them up.

Everything you do here autosaves as a draft - you’ll see a “saved just now” note near the top. Nothing reaches a real caller until you Publish. So explore freely; you can’t break anything live by editing.

The top bar has four things you’ll use constantly:

Settings - agent-level choices that apply to every node: voice, language, knowledge base, compliance pack, and your variables (more on those below).
Generate flow - the AI drafts a whole flow from a sentence of description (see below).
Test - role-play the call in a side panel, watching the flow light up node by node, before you ever dial a phone.
Publish - pushes the flow live. Greyed-out settings and a warning bar tell you if anything needs fixing first.

The canvas

The canvas is the map. Each node is a card showing its name, type, and how many other nodes lead into it. To work with it:

Add a node - the “Add node” button opens a small dialog: name it, pick what it does, and (optionally) wire it to an existing node right away.
Connect two nodes - drag from a node’s bottom handle to another node. That drops an arrow you then describe in the inspector (it starts as an empty intent transition waiting for your words).
Edit a node - click it. The right-hand inspector opens with everything about that node.
Move things around - drag cards to lay the flow out however reads best. Positions are saved, so it reopens exactly as you left it.

Tip: lay the flow out the way the call actually runs - greeting at the top-left, the happy path flowing down and to the right, dead-ends and “not interested” branches off to the side. A tidy canvas is far easier to reason about when something misbehaves.

Node kinds

Every node has a kind that tells the agent what job it’s doing on that step. The kind also decides which extra settings appear in the inspector. Here’s every one.

Greeting

Opens the call. The agent introduces itself, says who’s calling and why, and gets the caller’s consent to continue. Every flow starts on a greeting (it’s the one node you can’t delete, and it can’t be a silent or closing kind).

Tip: keep it to one or two sentences. The greeting sets the tone; a rambling opener loses people before you’ve made your point.

Conversation

A free back-and-forth toward a goal. This is your workhorse node - the agent talks naturally with the caller to accomplish one thing: qualify a lead, explain a product, handle an objection, pitch the offer. Most flows are mostly conversation nodes.

Tip: one job per node. “Qualify and pitch and book” is three nodes, not one. Small nodes are easier to wire, test, and fix.

Collect

Captures one specific value from the caller - a date, a number, a yes/no, a name - and stores it in a variable you can use later. The agent asks clearly, once, confirms the answer, and moves on. See Collecting values below for its extra settings.

Tip: use a collect node whenever you need the answer saved as data (to route on it, put it in a report, or send it to your CRM). If you just need the agent to chat, use a conversation node.

Decision

Routes silently - no speech. A decision node doesn’t say anything to the caller; it just looks at the values you’ve already collected and picks which way to go. Use it to branch cleanly on data: if score ≥ 700 → premium offer, else → standard offer.

Important: because it never speaks, every arrow out of a decision node must be a Rule (an exact expression over variables). An “intent” arrow here would be ignored. The builder flags this for you.

Action

Performs a tool - fetch availability, book a slot, look something up in your CRM. The agent briefly tells the caller what it’s doing (“Let me check that for you…”), runs the tool, and continues. You choose which tool(s) it can use in the node’s Runs on card.

Tip: if a tool returns something you want to reuse later (an available time, an order status), map its result into a variable so a later node or rule can read it.

Transfer

Hands the caller to a human. The agent stays brief and doesn’t promise a specific outcome, then connects the call to one of your approved transfer numbers.

Pitfall: always give a transfer node a fallback arrow. If the transfer can’t complete - line busy, nobody available, caller declines - the call needs somewhere to go, or it gets stuck re-prompting. The builder warns you when a transfer node has no fallback.

Distress handler

A system safety net for upset callers. This one is special - you don’t wire it into the flow like the others. See The distress handler below for the full picture. Add one to any flow that talks to real customers.

End

Closes the call with an outcome - booked, not interested, wrong person. The agent says a brief, warm goodbye and hangs up. A flow can (and usually should) have several end nodes, one per way the call can finish.

Pitfall: an end node hangs up right after it speaks - so it must be a goodbye, never a question. If your end node says “…and what time works for you?”, the agent asks it and then immediately disconnects, so the answer is lost forever. Put the ask on a collect or conversation node before the end. The builder warns you if an end node looks like it’s asking for something.

Transitions - how the call moves

A transition is an arrow leaving a node: when this happens, go there. Each one has a kind that decides how it fires.

Intent

Fires when the caller’s reply matches something you describe in plain language. You write what the caller says or wants - “the caller agrees to a demo”, “asks about pricing”, “wants to reschedule” - and the agent judges each turn against it.

This is the one you’ll reach for most, because it handles the messy reality of how people actually talk.

Write conditions the caller can say, not steps the agent takes. A good intent describes something observable in the caller’s words: “the caller confirms the address”, “the caller says they’re not interested”. A weak one describes the agent’s own progress: “finished pitching”, “explained the offer” - the agent can’t hear those, so the arrow never fires reliably. Ask yourself: could I tell this happened just by listening to the caller? If yes, it’s a good condition.

Rule

Fires when an exact expression over your variables is true - no interpretation, no AI judgement. Things like score >= 700, interested == true, age < 18. Rules are checked deterministically, so they’re perfect for routing on hard data you’ve already collected.

Tip: a rule must be a real comparison, not a sentence. consent == true works; “the caller agreed” does not (that’s an intent, not a rule) - the builder will flag prose written into a rule.

Retries

Fires after the node has re-asked this many times without getting anywhere. It’s your escape hatch. Set it to 2 and, after two failed attempts on a step, the agent gives up on that step and follows this arrow instead of nagging forever.

Tip: every collect node should have a retries arrow pointing somewhere sensible (a callback, a polite close). Without a give-up path, a caller whose answer never quite matches could be re-prompted endlessly. The builder warns you about this exact trap.

Handoff (advanced)

Hands the live call to a different published agent - the caller stays on the line, and the new agent takes over with everything collected so far. Useful when a specialist agent should finish the call (e.g. billing questions go to your billing agent). You describe when to hand off in plain language and pick the target agent.

How the agent chooses

When more than one arrow could apply, the agent resolves them in a fixed order so behaviour is predictable: exact Rules first, then Retries, then Intent - deterministic checks win over the AI-judged ones. Within that, the first matching arrow wins, so put your most specific conditions first.

If no arrow matches, the agent simply stays on the current node and re-engages the caller - it won’t wander off the map.

Collecting values

Give a collect node an Extract card in the inspector, where you tell it exactly what to capture:

Variable - the name it saves the answer under (e.g. credit_score, callback_at). Later nodes read it with {credit_score}, rules compare against it, and it lands in the call’s saved data.
Type - how to interpret and clean up the answer: Text, Date and time, Number, Phone, Yes or no, or One of a list. Picking the right type means “next Tuesday” becomes a real date and “seven hundred” becomes 700, so your rules compare like-for-like.
Options (for “One of a list” only) - the exact set of allowed answers. The caller’s reply is matched to one of them.
Retries before giving up - how many times to re-ask before following the node’s retries transition instead of looping.

Name variables the way your CRM does (interested, callback_at, preferred_slot) so the data lines up when you sync it out. And remember: the value is only saved if the caller actually gives a usable answer - a blank stays blank, which is exactly when the retries path should catch it.

Custom variables

Variables are the flow’s memory - named slots that hold values as the call moves along. You declare them in Settings → Variables, and only declared variables can be used in a prompt ({name}) or a rule (score >= 700). The builder warns you if a prompt or rule mentions a variable you never declared.

Each variable has an origin that says where its value comes from:

From the CSV - filled in per call from your calling list, before the call even starts. This is how one flow says “Hi Priya, about your order #4821…” to one caller and the right details to the next. The column must exist in your list, or the value arrives empty.
Collected in call - captured by a collect node during the conversation.
Written on end - produced by a tool result during the call (see the Action node).

Inside a node’s Prompt, use the insert variable menu to drop a {variable} at your cursor - no need to type the braces or remember exact spelling.

Persona lives in Settings, not in your prompts. Voice, tone, and language are set once in Settings and apply to every node - so a node’s prompt should describe what to do on this step, not repeat “be friendly and speak Hindi.” Keep prompts short and task-focused.

Per-node settings - the “Runs on” card

Each node picks its own reply model and tools, and can inherit or override the agent’s knowledge base. This is where a flow earns its keep - a cheap, fast model for the greeting, a careful one for the tricky reasoning step, and only the tools each step actually needs.

Reply model - which AI generates this node’s replies. Every node picks its own; a new node defaults to Fast (Haiku), which is right for most scripted turns. Switch a node to an accurate model when it needs careful reasoning. Mix and match freely across nodes.
Knowledge base - Inherit from agent, None (this node quotes nothing), or a specific knowledge base. Point a node at your real docs so it answers a caller’s question from your actual content instead of guessing.
Tools available here - the tools this node may use, chosen per node. Nothing is selected by default, so a node has no tools until you add them. A tool the node can’t see, it can’t call - everything else stays off no matter what the caller asks. This is how you make sure the “book a meeting” tool only fires on the booking step, not during the greeting. For a transfer node you can also narrow which numbers it may hand the call to; for CRM tools, which integrations it may touch.

Grant the least each node needs. Every extra tool on a node is one more thing that could fire at the wrong moment. Turning tools on step-by-step (rather than agent-wide) is the whole point of a flow - use it.

Silence timeout

Below the transitions, each node can have its own silence timeout: if nobody speaks for N seconds, reprompt once, then follow this arrow. Handy on a collect node - if the caller goes quiet after you ask for their date of birth, nudge once, then route to a fallback rather than sitting in dead air. Leave it off and the agent’s normal silence handling applies.

Capturing data and wrapping up a call

Every real call needs two things at the end: the data you wanted, and a clean, tagged finish. A flow does both with the pieces you’ve already met, so here’s how they fit together.

The data you walk away with

There’s no single “what to capture” panel in a flow like there is on a single-prompt agent - capture is deliberate and lives on the nodes:

Each Collect node saves one value into a variable (callback_at, credit_score, interested).
Those variables, plus anything filled from your CSV and any tool results (Custom variables), are the call’s saved data - what you filter, report on, and sync out afterwards.
While you Test, watch the “Captured so far” panel fill in turn by turn, so you can confirm each value lands before you ever dial.

One Collect node per thing you need to keep, and name the variables the way your CRM does - that’s the whole capture story in a flow.

Tagging how it turned out

To label the outcome, attach the Set disposition tool to your closing steps (a node’s Tools available here in the Runs on card). The agent tags the call - booked, not interested, callback, wrong person - as it wraps, and that tag shows up in results and on your pipeline board. See Dispositions & outcomes.

If a caller asks not to be contacted again, attach the Opt out tool so the request is recorded. Both are per-node tools - put them on the end/decision nodes where a call actually finishes, not on every node.

Landing the call

Give each way the call can finish its own End node with an outcome and a short goodbye. Remember an end node hangs up right after it speaks, so collect anything you still need on a Collect node before it.

Wrap-up checklist: capture what you need on Collect nodes → tag the result with Set disposition on the closing step → record opt-outs with the Opt out tool → land every path on an End node.

Sending outcomes onward to a CRM

Pushing that captured data and disposition to a CRM after the call isn’t configured in the flow builder itself. Connect your CRM under Integrations (each tool is marked Mid-call or Post-call), and use your pipeline board’s column automations to push outcomes onward. The flow’s job is to capture and tag; where that data goes next is set there.

The distress handler

This is a built-in safety net, and it behaves differently from every other node - so it’s worth understanding on its own.

You add it, but you don’t wire it in. There are no arrows into or out of it. Instead, the call jumps to it automatically whenever the caller:

is genuinely distressed or upset,
asks to speak to a human, or
stays frustrated with the automated agent past a short de-escalation budget (the agent tries to calm things and re-orient a couple of times first; only if that fails does it escalate).

When it triggers, the handler warmly acknowledges the caller and offers to connect them to a person. Then:

Caller says yes → it does whatever tool you attached to it. By default that’s a transfer to a human. If you attach the end call tool instead, it simply ends the call gracefully - no transfer.
Caller says no → the call resumes exactly where it left off. Nothing is lost.

A flow can have exactly one distress handler (the builder stops you adding a second). Add one to any flow that talks to real customers - it’s the difference between a caller who feels heard and one who’s stuck arguing with a robot.

Tip: if you turn on the transfer behaviour, make sure your transfer numbers are set (in the handler’s “Runs on” card or at the agent level). A distress handler that offers a human with nobody to receive the call is worse than none.

Generate a flow with AI

Short on time, or not sure where to start? Generate flow drafts a whole working flow from a sentence or two.

Describe what the agent should do - “Call leads who booked a demo, confirm they still want it, collect a preferred time, and book it - otherwise take a callback time” - and the AI drafts the flow, test-calls it against itself, reviews how it went, and improves it before handing you the result. You’ll see it work through those steps live (generating → test-calling → reviewing → improving → ready). It even adds a distress handler for you.

Heads up: if your canvas already has a flow, generating won’t silently wipe it - you’ll be asked to confirm the replace first.

Always review and test what it generates. It’s a strong first draft, not a finished call. Read every node and transition, tweak the wording to sound like you, and run a test before publishing.

Test, then publish

Test first, always. The Test panel role-plays a caller and runs the whole flow, lighting up each node as the sim reaches it and each arrow as it’s followed - so you can see the routing, not just guess at it. It’s fast and free, so use it after every meaningful change. For a real-phone test, see Test your agent.

When you hit Publish, a pre-flight checklist runs. It reframes the builder’s validation into plain checks:

Errors (red) must be fixed before you can publish - a dead-end node with nowhere to go, a collect node that doesn’t name its variable, a decision node with a non-rule arrow, a required in-call variable that no node collects. These would genuinely break a call.
Warnings (amber) don’t block publishing but are worth a look - an unreachable node, a path that never reaches an end, a transfer with no fallback, a rule that reads like prose and so never fires, a possible re-prompt loop.

The modal also shows a few reassuring green checks when things are clean: every node reachable, every path ends, compliance pack attached.

Once published, the flow is live on new calls, and your campaigns and phone numbers can point at this agent. Made changes later? Just Publish again to push the update - but note that campaigns already running stay on the version they started with until you move them, so an in-flight campaign never changes mid-run. You can also take a live agent offline at any time; the published flow is kept, so re-publishing brings it right back.

Keep flows shippable

Every path should reach an end node, so the call always has a clean finish.
Add a distress handler to any customer-facing flow.
Give every collect node a retries (give-up) exit so a caller can’t get stuck.
Keep node instructions short and specific - one job per node.
Write intent conditions the caller can be heard saying, not steps the agent takes.
Test the branches, not just the happy path - the “no”, the silence, the “wrong number” are where calls go wrong.

Next: Voice & language →