K Rudy
04/27/2026, 7:58 PMAI Evy
04/27/2026, 7:58 PMAI Evy
04/27/2026, 7:59 PMAI Evy
04/27/2026, 7:59 PM{{current_time_Europe/London}} in your prompts, begin message, or tool configurations. This will provide the current time in the Europe/London timezone, which observes BST during summer months.
For example, in your agent prompt:
Now is {{current_time_Europe/London}}. Use this time for all scheduling and time-based decisions.
You can also use {{current_hour_Europe/London}} to get the current hour as a fraction, or {{current_calendar_Europe/London}} for a 14-day calendar in that timezone.
If you need to use this in a Logic Split node for time-based routing, you can create equation-based conditions like:
{{current_hour_Europe/London}} >= 9 AND {{current_hour_Europe/London}} < 17
[(2) ]()
This approach is more reliable than letting the LLM interpret time from prompts alone.AI Evy
04/27/2026, 7:59 PMK Rudy
04/27/2026, 8:00 PMAI Evy
04/27/2026, 8:00 PMAI Evy
04/27/2026, 8:00 PMAI Evy
04/27/2026, 8:00 PMAI Evy
04/27/2026, 8:00 PMK Rudy
04/27/2026, 8:03 PMAI Evy
04/27/2026, 8:03 PMAI Evy
04/27/2026, 8:03 PMYou have access to the current time: {{current_time_Europe/London}}. You can tell the user the current time if asked.
However, the Prompt Engineering Guide specifically recommends switching to Conversation Flow when you need reliable time-based decision branches. The guide states that you should use Conversation Flow agents when dealing with "multiple decision branches" or when "reliability concerns" arise where "single prompt shows inconsistent behavior." [(1) ]()
From Discord community experiences, prompt-based logic for time checks works but can be unreliable - one user reported that "prompt based agents have a terrible time with determining whether or not it is inside business hours" and typically had to write custom functions to handle it programmatically. [(2) ]()
If you need deterministic time-based routing (like business hours vs. after hours) , Conversation Flow with Logic Split nodes will be more reliable than relying on the LLM to interpret time conditions in a prompt. [(1) ]()AI Evy
04/27/2026, 8:03 PMAI Evy
04/27/2026, 8:03 PMK Rudy
04/27/2026, 8:34 PMAI Evy
04/27/2026, 8:34 PMAI Evy
04/27/2026, 8:34 PM{{current_time}} is a reliable default system variable that Retell automatically provides. [(1) ]() It returns the current time in America/Los_Angeles timezone.
For example, the format is: "Thursday, March 28, 2024 at 11:46:04 PM PST".
For BST specifically, you should use {{current_time_Europe/London}} instead, which will give you the accurate time in that timezone. The timezone-specific variables follow the pattern {{current_time_[timezone]}}.
In practice, a workshop tutorial demonstrates using this variable by including it in the agent context like this: [(2) ]()
The current date and time is {{current_time}}
The dynamic variable itself is reliable and automatically updated by Retell's system. [(1) ]() However, as discussed in the previous messages, how the LLM interprets and acts on that time information in prompt-based agents can be less reliable than using equation-based Logic Split nodes in Conversation Flow. [(3) ]()AI Evy
04/27/2026, 8:34 PMAI Evy
04/27/2026, 8:34 PMK Rudy
04/27/2026, 9:19 PMAI Evy
04/27/2026, 9:19 PMAI Evy
04/27/2026, 9:20 PM{{current_time_America/Denver}}. [(1) ]()
Denver is in the Mountain Time Zone, which observes Mountain Standard Time (MST) or Mountain Daylight Time (MDT) depending on the season.
You can use this in your agent prompt, begin message, or tool configurations just like the BST example:
Now is {{current_time_America/Denver}}. Use this time for all scheduling and time-based decisions.
You can also use {{current_hour_America/Denver}} to get the current hour as a fraction, or {{current_calendar_America/Denver}} for a 14-day calendar in the Denver timezone.AI Evy
04/27/2026, 9:20 PMAI Evy
04/27/2026, 9:20 PMK Rudy
04/28/2026, 3:31 AMAI Evy
04/28/2026, 3:31 AMAI Evy
04/28/2026, 3:31 AMAI Evy
04/28/2026, 3:31 AMjson
{
"first_name": "John",
"email": "john@example.com",
"phone_number": "+18005551212"
}
These variables will then be available in your agent prompt using the {{variable_name}} syntax. For example, {{first_name}}, {{email}}, and {{phone_number}}.
Important: Do NOT wrap your variables in a retell_llm_dynamic_variables object for the Inbound Call Webhook response. That structure is only used when making outbound calls via the API. The Inbound Call Webhook expects the variables directly as top-level key-value pairs.
If your dynamic variables aren't populating, double-check that:
- Your webhook returns a 200 status code [(2) ]()
- The JSON structure matches the format above (no nested objects) [(1) ]() [(2) ]()
- The variable names in your prompt match exactly what you're returning from the webhook [(3) ]()AI Evy
04/28/2026, 3:31 AM