Edges & routing

Every node has a list of edges. After each customer message, the framework picks the next node by checking deterministic edges first (instant, free), then handing off to the routing LLM if nothing deterministic matches.

Edge fields

Field	Description
`to_node_id`	Target node id. Required.
`condition`	Human-readable description of when to transition. Used as the routing LLM’s tool description.
`condition_type`	One of `"llm"` (default if unset), `"expression"`, `"unconditional"`, `"event"`.
`expression`	Required when `condition_type == "expression"`. See Expression edges.
`event_name`	Required when `condition_type == "event"`. The external event name to listen for. See Event injection.
`function_name`	Override the auto-generated routing tool name (default: `transition_to_<to_node_id>`).
`function_description`	Override the auto-generated routing tool description.
`parameters`	Values to extract from the user’s input during the transition: `{name: type}`, or `{name: {type, description, allowed_values}}` to define each value. See Inline data extraction.
`priority`	Lower fires first. Defaults: expression / unconditional / event = `0`, llm = `100`.

Edge types

`condition_type`	How it works	When to use
Not set or `"llm"`	Routing LLM evaluates `condition` against the customer’s reply.	When the decision requires understanding intent.
`"expression"`	Rule-based check on context variables. Fires instantly if matched.	Time of day, retry counts, language detection, any data-driven decision.
`"unconditional"`	Always takes this edge. No check.	When there is only one possible next step.
`"event"`	Fires only when a matching external event arrives via REST. Ignored during speech routing.	When an external system (payment, form, link click) drives the conversation. See Event injection.

Expression and unconditional edges are checked together (in priority order, ascending) before any LLM call is made. To put routing in its own node instead of on a conversational node’s edges — a silent classifier or a pre-conversation dispatcher — use a router node.

Expression edges

{
  "to_node_id": "after_hours",
  "condition": "Outside working hours",
  "condition_type": "expression",
  "expression": {
    "logic": "or",
    "conditions": [
      { "variable": "recipient_data.current_hour", "operator": "lt",  "value": 10 },
      { "variable": "recipient_data.current_hour", "operator": "gte", "value": 18 }
    ]
  }
}

Use "logic": "and" when all conditions must be true. Use "logic": "or" when any one is enough.

Operators

Equality

eq, neq

Numbers

gt, gte, lt, lte

Text

contains

Lists

in, not_in

Existence

exists, not_exists

Priority

Lower priority fires first. Defaults if not set: deterministic edges (expression, unconditional, event) get priority 0; LLM edges get priority 100. Within the deterministic bucket, the first matching edge wins. For mutually-exclusive rules (e.g. working-hours vs after-hours), set distinct priorities to make ordering explicit.

Built-in variables

These variables are populated automatically and can be referenced in any expression.

Variable	Type	Notes
`recipient_data.current_hour`	int (0-23)	Hour in the call’s timezone.
`recipient_data.current_minute`	int (0-59)
`recipient_data.current_weekday`	string	Lowercase, e.g. `"wednesday"`.
`recipient_data.current_day`	int (1-31)
`recipient_data.current_month`	int (1-12)
`recipient_data.current_year`	int
`recipient_data.current_date`	string	Display string for prompts only, not for comparisons.
`recipient_data.current_time`	string	Display string for prompts only.
`recipient_data.timezone`	string	e.g. `"Asia/Kolkata"`.
`recipient_data.user_number`	string	E.164 phone number.
`detected_language`	string	Top-level, not under `recipient_data`. e.g. `"hindi"`, `"en"`.
`_node_turns`	int	User messages on the current node. Resets on every transition.
`_total_turns`	int	User messages in the entire call.
`_silence_repeats`	int	Times the current node has replayed because the user stayed silent past `repeat_after_silence_seconds`. Resets on transition. See Static nodes.

Time variables (current_hour, current_weekday, etc.) are populated only when recipient_data.timezone is set on the call. Without a timezone, time-based expressions silently never match. Always set timezone when creating a call that uses time-based routing.

Typed variables

Values used in expressions often arrive as strings (event properties, extracted parameters, dynamic context_data). So "18" would not match 18, and "false" would not be treated as a boolean. Declare the variable’s type and both sides of the comparison are converted before matching. Add a variable_types map at the top level of the graph config. Each key is the variable path, written exactly as it appears in the condition (including dot-notation):

{
  "variable_types": {
    "recipient_data.age": "number",
    "recipient_data.hold_status": "boolean",
    "plan_tier": "string"
  }
}

Type	Matches
`number`	Any number or numeric string, e.g. `18` or `"18"`.
`boolean`	`true` / `1` / `yes` and `false` / `0` / `no` (case-insensitive).
`string`	Compared as text.

{
  "to_node_id": "premium_flow",
  "condition_type": "expression",
  "expression": {
    "conditions": [
      { "variable": "recipient_data.age", "operator": "gte", "value": 18 },
      { "variable": "recipient_data.hold_status", "operator": "eq", "value": true }
    ]
  }
}

Declare a type whenever a value can arrive as a string. If you leave a variable out, the framework guesses based on the values, which is fine for plain numbers but unreliable for booleans.

Common patterns

Working hours (10 AM to 6 PM)

{
  "to_node_id": "transfer_call",
  "condition": "Working hours",
  "condition_type": "expression",
  "priority": 0,
  "expression": {
    "logic": "and",
    "conditions": [
      { "variable": "recipient_data.current_hour", "operator": "gte", "value": 10 },
      { "variable": "recipient_data.current_hour", "operator": "lt",  "value": 18 }
    ]
  }
}

Auto-escalate after too many retries

{
  "to_node_id": "transfer_call",
  "condition": "Too many retries on this node",
  "condition_type": "expression",
  "expression": {
    "conditions": [
      { "variable": "_node_turns", "operator": "gte", "value": 2 }
    ]
  }
}

Inline data extraction

Edges can capture typed values from the user’s reply during routing. The routing LLM treats them as required parameters; on a successful transition the values are merged into context_data and become available everywhere.

{
  "to_node_id": "confirm_order",
  "condition": "Customer provided their order id",
  "parameters": {
    "order_id": "string"
  }
}

After the transition, context_data["order_id"] is set and you can:

Reference it in node prompts via {{order_id}}.
Use it in downstream expression edges: { "variable": "order_id", "operator": "exists" }.
Pass it to API tools as %(order_id)s.

Prefer parameters over a separate “extract” node. One LLM call routes and captures data.

Define what each value means

Give a parameter a description and, for string values, allowed_values. The routing model sees the description on that key, and it can only answer with one of the allowed values, so expression edges can match one exact value.

{
  "to_node_id": "availability_check",
  "condition": "The candidate replied to the question.",
  "parameters": {
    "availability": {
      "type": "string",
      "description": "Yes if they can talk now (available, go ahead). No if they cannot (driving, in a meeting, busy). N/A if they ask to repeat or say something unrelated.",
      "allowed_values": ["Yes", "No", "N/A"]
    },
    "callback_hour": "number"
  }
}

Without a description, the model is only told “The <name> provided by the user”, so put the rules for each value in its own description rather than in function_description.
allowed_values works on string parameters only.
Both forms can be mixed on one edge.

Naming rules

reasoning, confidence, recipient_data, detected_language and names starting with _ are reserved, and an agent using them is rejected when saved.
A value with the same name as an earlier one, on this edge or another, replaces it. A retry edge that asks again overwrites the first attempt’s answer.

Getting the values after the call

The values a call collected are returned on the execution as node_extracted_data, the latest value per key, in Get execution and the webhook payload.

Routing instructions

The routing_instructions field is prepended to every routing request. Keep it short and directive:

You are the Routing System for this conversation. Analyze the user's input
and the available edges. Select the edge whose condition best matches.
If no edge matches, stay on the current node.

You can include {{variable}} placeholders. They are substituted from context_data (and the flattened recipient_data) at runtime. Missing keys render as NULL.

Build

Deploy

Monitor

Go live

Edge fields

Edge types

Expression edges

Operators

Equality

Numbers

Text

Lists

Existence

Priority

Built-in variables

Typed variables

Common patterns

Inline data extraction

Define what each value means

Naming rules

Getting the values after the call

Routing instructions

Next steps

Router nodes

Graph agents overview

​Edge fields

​Edge types

​Expression edges

​Operators

Equality

Numbers

Text

Lists

Existence

​Priority

​Built-in variables

​Typed variables

​Common patterns

​Inline data extraction

​Define what each value means

​Naming rules

​Getting the values after the call

​Routing instructions

​Next steps

Router nodes

Graph agents overview

Edge fields

Edge types

Expression edges

Operators

Priority

Built-in variables

Typed variables

Common patterns

Inline data extraction

Define what each value means

Naming rules

Getting the values after the call

Routing instructions

Next steps