Extract variables

Let the agent capture values from the conversation into dynamic variables while the call is in progress.

The Extract Dynamic Variable function (type: "extract_dynamic_variable") turns what the caller said into named values. The LLM calls the tool with the values it heard; the worker stores them as collected dynamic variables. Later prompts, tools, transfer destinations and flow conditions can then use {{name}}.

Use it when values matter during the call, for example to route on a reason for calling or to pass a date to a booking tool. For values you only need after the call, use post-call analysis instead.

Configure in the dashboard#

Open the agent, expand Functions, click Add and choose Extract Dynamic Variable.
Set Name and Description. The default description is "Extract information from the conversation." Make it say when to extract, for example "Call this once the caller has given their name and preferred day."
Under Variables, add one row per value:
- Type: Text, Selector, Boolean or Number.
- variable_name: spaces become underscores.
- Description: what the value is.
- For Selector: Choices, comma separated.
Click Add variable for more rows, then Save.

Fields#

Field	Type	Description
`type`	`"extract_dynamic_variable"`
`name`, `description`	string
`variables`	array of fields	Values to extract

Each entry in variables:

Field	Type	Default	Description
`type`	`"string"`, `"enum"`, `"boolean"`, `"number"`		Value type
`name`	string		Variable name
`description`	string	`""`	What to extract
`choices`	string array		Allowed values for `enum`
`examples`	string array		Example values (API only). For `string` fields they are added to the description the LLM sees
`required`	boolean	`false`	API only. Marks the argument as required in the schema

{
  "type": "extract_dynamic_variable",
  "name": "capture_reason",
  "description": "Call this as soon as the caller says why they are calling.",
  "variables": [
    { "type": "enum", "name": "reason", "description": "Reason for the call", "choices": ["booking", "billing", "other"] },
    { "type": "string", "name": "preferred_day", "description": "Day of the week the caller prefers", "examples": ["Monday", "Friday"] },
    { "type": "boolean", "name": "new_patient", "description": "Whether the caller has not visited before" }
  ]
}

What happens when it runs#

The LLM calls the tool with values for some or all of the variables.
The worker keeps only arguments whose names are in variables and that are not null.
Values are stored as strings: booleans become true or false, whole numbers lose the .0, objects become JSON.
A dynamic_variables event is recorded and the values appear in collected_dynamic_variables on the call.
The LLM gets the extracted values as JSON and replies.

Extracting again overwrites earlier values with the same name.

Using the values#

In prompts and tool settings: {{reason}}.
In flow equation conditions: {{reason}} == billing.
In webhooks and the call object: collected_dynamic_variables.

Tool vs node#

	Extract Dynamic Variable tool	Extract Variables node
Who decides when	The LLM, from the description	The flow, when it reaches the node
Extra LLM call	No: values come from the reply call's tool call	Yes: one forced extraction call
Typical use	Single and multi-prompt agents	Flows before a logic split

Gotchas#

The LLM can call the tool with only the values it heard. Check for missing values with exists / not_exist conditions or in your prompt.
Values are strings. Equation conditions compare numbers numerically when both sides parse as numbers.
Keep variable names unique across tools; the last write wins.