System Variables

Alongside the variables your flow sets, every run carries a set of system variables the platform fills in for you: which workflow is running, who called, what the current time is. Reference them exactly like your own variables — $(sys.ctx.conversation_id) — anywhere a field accepts $( ).

Two ways to write a reference

$(sys.date.now) and {{sys.date.now}} are equivalent — same grammar, same result. Use whichever you prefer; the editor's suggestion menu completes whichever one you start typing. To write a literal delimiter instead of a reference, escape it with a backslash: \$( or \{{.

Every reference below follows your choice.

Two clocks: sys.date and sys.utc

Date and time come in two namespaces with identical fields. $(sys.date.*) is the workflow's own timezone, set in workflow settings; $(sys.utc.*) is UTC. A workflow with no timezone configured falls back to America/New_York.

Within a single node, every date reference is evaluated once, so $(sys.date.minute) and $(sys.date.second) in the same field can't straddle a tick.

When a variable isn't there

Anything marked Optional depends on how the conversation started — telephony fields need a phone call, SMS fields need an inbound message, and a carrier may not supply a caller name at all. An optional value that wasn't supplied resolves to an empty string when you interpolate it into text, so a message body of $(sys.telephony.ani) renders as nothing at all on a conversation that didn't start with a phone call. To branch on whether a value was supplied, use a Condition node's Exists or Does Not Exist operator rather than relying on the rendered text.

Reference

The other namespaces

sys. is one of five namespaces a reference can name. The other four hold values you set yourself, and they are read in different places: a workflow node reads its own variables and $(sys.*), while a voice agent's configuration reads three more.

Full details, and how to create the values, are on Secrets & Variables.

An organization-wide value

Create a variable named brand with the value Northwind Traders, then write an agent's system prompt against it:

You are the virtual receptionist for {{org.brand}}.

Change the variable once and every agent that references it picks up the new value. Nothing needs to be re-saved. Allow up to five minutes for the change to reach every call; When a change takes effect explains why.

A value for one agent

Add a variable named queue with the value Billing in that agent's Variables section, then reference it in the same agent's prompt:

Transfer to the {{agent.queue}} team when the caller asks about an invoice.

An agent. name is visible only to the agent that declares it. Two agents can each have a queue with different values.

A secret resolves in one place only

A secret is deliberately harder to use than a variable. {{secrets.stripe_key}} is resolved in one place only — the outbound HTTP request an integration tool makes — so it may appear only in that tool's constant parameters and its request path. Anywhere else (a prompt, a greeting, a disposition, an agent variable) is rejected when you save.

That is the point of the design: if a prompt leaks, it leaks the text {{secrets.stripe_key}} rather than the key.

A value for one call

A workflow can hand an agent values that change call to call — a customer id, an account tier, the result of a lookup it already did — through the AI Voice Agent node's Pass to agent list. The agent reads them as {{vars.<name>}} in its prompt, greeting, thinking cue, disposition descriptions, and an integration tool's constant parameters.

Greet the caller by name. Their account tier is {{vars.tier}}.

They travel one way. A name the workflow didn't pass reads as empty rather than failing the call, and the values are fixed at the moment of the handover. See Secrets & Variables for the limits.

Functions don't work in agent configuration

{{UPPER(org.brand)}} is valid in a workflow node. In agent configuration, and in an org variable's value, a function call is rejected — use a plain reference instead.

In a voice agent, only part of sys. resolves

An agent session has no workflow behind it, so the tokens that describe one have nothing to read. These are the sys. tokens an agent's configuration accepts:

• Context: $(sys.ctx.conversation_id), $(sys.ctx.organization_id), and $(sys.ctx.agent_id) — the last exists only for agents, which is why it isn't in the reference table above.
• Telephony: $(sys.telephony.ani), the other party's number. On an inbound call that's the caller's number. On an outbound call placed by a Convert to Voice node, it's the number that was dialed, not your caller ID. It is the only telephony field an agent session receives.
• Date and time: every $(sys.utc.*) field.

Everything else is refused when you save the agent, with is not available to a voice agent. That covers $(sys.ctx.workflow_id), $(sys.ctx.workflow_instance_id), $(sys.ctx.workflow_name), $(sys.ctx.version), $(sys.ctx.conversation_type), $(sys.ctx.timezone), all three $(sys.sms.*) fields, $(sys.telephony.dnis), $(sys.telephony.cnam), and every $(sys.date.*) field.

Next steps