Skip to main content
Practical patterns for building reliable flows: labeling edges, structuring agents, validating data, and testing before you ship.

​
Write clear edge labels

Write edge labels as clear conditions from the caller’s perspective:
  • ✅ caller confirms they are an existing customer
  • ✅ caller wants to cancel or reschedule
  • ❌ yes, path A, continue
Make sibling labels mutually exclusive and cover the realistic cases. If two labels overlap, routing becomes a coin flip.

​
Keep agents small and single-purpose

One agent = one job (qualify, answer billing questions, book). Short, focused instructions per agent outperform one mega-agent with a wall of text. Handoffs are cheap — use them.

​
Validate data with collect nodes, not prompts

Emails and phone numbers transcribed from speech are noisy. collect nodes confirm and validate (“Was that m-e-y-e-r?”) and only proceed on success. Always name the variable clearly (callback_phone, not var1) — those names surface in webhooks and call details.

​
Design the failure paths

  • Give collect nodes a failed edge that leads somewhere sensible (a human transfer or a polite goodbye).
  • Set warm-transfer fallback deliberately: continue for optional handovers, cold_transfer when the caller must reach someone.
  • End every branch with an end node with a proper farewell.

​
Test with web calls, watch the events

Run test calls from the browser after each change. In the call detail view, the event log shows node transitions, tool calls, collect results, and transfer outcomes — read it like a stack trace when the flow misbehaves.

​
Use asynchronous tools for slower requests

For slow webhooks, enable Run asynchronously and configure filler phrases so the conversation can continue while the request runs. See the tool node.

​
Start from the prompt, graduate to the flow

Prototype behavior with a plain system prompt first. When the call develops distinct phases or needs guaranteed data capture, move that structure into a flow — agent nodes with empty instructions inherit the system prompt, so migration is incremental.