Use variables with agents

Enable Variables tools for agents and name values so agents can pick and update them safely.

Agents use variables in two practical ways:

As tools — enable the Variables app for the agent so it can list, get, or update values when a conversation or task needs them (for example “what is our default reply-to address?” or “set the escalation flag to true”).
Indirectly through workflows — if the agent starts a workflow that already references variables, those values are resolved when the workflow runs.

Agents choose which variable to read or update from the name and description. Treat those fields as instructions for the agent, not only as labels for people.

Create and maintain the values on the Variables page (Create and manage).

Name and describe variables for agents

When an agent has the Variables tools, it lists available variables and picks one by reading the name and description. Vague names force guessing. Clear names plus a short “how to use this” description make tool calls reliable.

How to name variables

Use a short business phrase a colleague would recognise. Prefer spaces and plain English over codes or abbreviations.

Prefer	Avoid	Why
`Support inbox`	`email1`, `var_to`	Says what the value is for
`Approvals enabled`	`flag`, `bool2`	States the business meaning
`Default reply language`	`lang`, `dl`	Agents can match user requests like “switch to German”
`Invoice reminder days`	`n`, `days`	Includes the unit in the name
`CRM base URL`	`url`, `endpoint`	Distinguishes from other URLs
`Quarter end`	`date1`	Clear calendar meaning

Naming tips:

Start with the business concept, not the technical field (Support inbox, not to_address).
Keep names under a few words when you can (still within the 100-character limit).
Use the same wording your team uses in chat and tickets so agents and people stay aligned.
Do not encode the data type in the name (Support inbox text); the type selector already does that.
Avoid near-duplicates (Support inbox vs Support inbox email) unless the difference is obvious in both name and description.

Why descriptions matter for agents

The description is the agent’s usage guide. A good description answers: what this value is, when to read or change it, and what must stay true (format, who owns the decision, do not invent values).

Without a description, the agent only sees a short name. That is often enough for Support inbox, but not for flags, counters, or values that must not be guessed.

Write descriptions that:

State the purpose in one sentence.
Say when to update (operator request, after approval, never mid-conversation, and so on).
Constrain the value (email format, True/False only, ISO date, allowed languages).
Point to related process if needed (which workflow or team owns it).

Name	Weak description	Strong description
`Support inbox`	Email	Shared mailbox for customer replies. Use as the To address in outbound support emails. Update only when IT changes the mailbox.
`Approvals enabled`	Flag	When True, the invoice workflow pauses for human approval. Set to False only if an ops lead asks to skip approvals temporarily.
`Default reply language`	Language	ISO-style language for agent replies (for example `en` or `de`). Read this before drafting customer messages. Do not invent a language code.
`Invoice reminder days`	Number	Days after due date before sending a reminder. Whole number only. Agents may read it; only finance may ask to change it.

Example: approval flag (workflow + agent)

Goal: Turn human approval on or off without rebuilding the flow.