Variables are placeholders like {{current_date}} that the engine replaces with real values once per call, before sending the prompt to the agent. They let your agent reference dynamic information (date, time, caller, history) without you hardcoding anything.
Variables are substituted once at call start, not per word. They add no latency to the call.
How it works
Two things happen when an inbound call begins:
- The engine builds a “call context” block with real-time data (date, time, caller phone, timezone, etc.) and prepends it to your system prompt. The agent sees this context automatically — no setup needed.
- If your prompt contains
{{variable}} placeholders, the engine substitutes them with values from the same data source. This is optional — useful when you want to phrase something explicitly.
Your prompt: "Today is {{current_date}}. We close at 11pm."
The agent sees: "Today is Monday, May 25, 2026. We close at 11pm."
Available variables
Time & caller (always on)
These are computed every call from the engine clock + your agent’s timezone setting. Zero added latency.
| Variable | Example value | Source |
|---|
{{current_date}} | Monday, May 25, 2026 | Server clock formatted to agent timezone |
{{current_time}} | 14:32 | 24-hour, agent timezone |
{{current_day_of_week}} | Monday | Agent timezone |
{{tomorrow_date}} | Tuesday, May 26, 2026 | Agent timezone |
{{caller_phone}} | +447446466847 | Twilio caller ID |
Timezones honour DST automatically. Set your agent’s timezone in the dashboard toolbar or via PUT /v1/agents/:id { "timezone": "Europe/London" }.
Smart context (active by default)
| Variable | What it does |
|---|
{{caller_history}} | The name a returning caller gave on their most recent previous call (name only - no call summaries or booking details) |
=== CALLER HISTORY (this number has called you before) ===
RETURNING CALLER: the name on file for this caller is "John". Greet them by name
naturally at the start of the call (for example, "Hi John"). If they correct you
or it is clearly someone else, use the new name instead.
When variables fire
| Stage | What happens |
|---|
| Call starts | Engine loads agent + caller history in parallel |
| Before greeting | Engine builds final prompt with values substituted and context block prepended |
| Greeting plays | The agent responds using the merged prompt for the entire call |
| Call ends | Prompt and context are discarded |
What’s NOT supported (and why)
We’re deliberate about what to add. Each variable is a contract — once shipped, agents depend on it.
| Often-requested | Why we don’t have it |
|---|
{{agent_name}} | You already type the agent’s name in your own prompt. A variable just adds indirection. |
{{business_hours}} | Hours rarely match a single string. Put them in your prompt directly so the agent can reason about edge cases (“closed for lunch”, “open on bank holidays”). |
{{caller_name}} for inbound | Inbound callers are strangers until they identify themselves. Once they have given their name on a previous call, {{caller_history}} greets them by name. |
| Arbitrary developer-supplied vars per call | Coming later — requires API and webhook changes. |
Direction support
- Inbound calls: full support ✓
- Outbound calls: not yet — variables don’t substitute on outbound. See Outbound calls for the current capability.
This is on the roadmap.
Behaviour reference
- If a
{{var}} has no matching value, the engine leaves it untouched (visible in the prompt as {{var}}). Easier to debug than silent removal.
- Unknown variable names are not errors — they’re just passed through.
- Values are converted to strings. Booleans show as
"true"/"false".
- Variables are case-sensitive.
{{Current_date}} won’t match current_date.
See also
