Skip to main content
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:
  1. 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.
  2. 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.
Both approaches work. Use placeholders only if explicit phrasing reads better than letting the agent infer from the context block.

​
Available variables

​
Time & caller (always on)

These are computed every call from the engine clock + your agent’s timezone setting. Zero added latency.
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)

When a number that has called before dials your agent again, the engine looks up the caller’s most recent call that captured a name - in parallel with the agent load, so it adds zero latency. If a name is on file, the engine passes a short hint to the agent, and places it in the greeting instruction itself so a scripted opening line cannot override it:
That’s the whole block - a name and one line of intent. No summaries, outcomes, dates, bookings or sentiment are ever injected into a live call. This is deliberate: injecting past booking details once caused agents to confirm bookings they had never made. The reason line records only what the caller wanted (“wanted to book a check-up”), never what happened, so it carries no such risk. The name and the reason both come from the most recent previous call where a name was captured, so they always describe the same visit, and a quick call that captured no name will not erase a known name. Both are extracted automatically on every call - there is nothing to configure. If the caller gives a new name, that becomes the name on file going forward. First-time callers (no name on file) get nothing extra - no clutter.

​
When variables fire

Variables are read-once. Their values don’t change during the call. If your business hours rotate by minute, don’t put them in a variable — put them directly in the prompt.

​
What’s NOT supported (and why)

We’re deliberate about what to add. Each variable is a contract — once shipped, agents depend on it.

​
Direction support

  • Inbound calls: full support ✓
  • Outbound calls: the engine injects the same real-time context block (date, time, day of week, timezone, the number being called, business number, call direction, and more) at the top of the prompt automatically. For batch campaigns, every column from your recipient CSV is also injected as context for that call, so you can write a natural prompt and the agent receives each recipient’s details without needing placeholders. See Outbound calls.
On outbound campaigns you do not need to add placeholders for your CSV columns - the engine passes every column to the agent as context automatically.

​
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