Skip to main content

Configure prompt variables

A custom variable is a name and text value stored with the agent configuration. The system prompt references it with double braces:

The business serves {{service_area}}.

At runtime, Wirevox replaces that token with the configured value before sending the system prompt to the model.

Decide whether a variable is appropriate​

Use a variable when all of the following are true:

  • the value is stable for the published agent version;
  • the value is short enough to include whenever the prompt is compiled;
  • the value is approved and verified;
  • the value is not secret; and
  • maintaining it separately makes the prompt easier to reuse or update.

Good candidates include:

  • business_name;
  • business_hours;
  • service_area;
  • supported_languages;
  • escalation_department; and
  • a short approved policy statement.

Use a knowledge base for detailed policies, long FAQs, product catalogs, or source documents. Use a function for information that can change during the day or differs by customer.

Name variables consistently​

Use lower-case snake_case names that begin with a letter and contain only letters, numbers, and underscores.

business_name
service_area
after_hours_message

Avoid spaces, hyphens, punctuation, or names that differ only by capitalization. The runtime resolves names without regard to case, while some editor warnings compare the written reference more literally. Consistent lower-case names avoid confusing mismatches.

Vox's agent-authoring contract accepts names up to 64 characters, rejects case-insensitive duplicates, and limits a replacement list to 50 variables. Keep the practical list much smaller; every variable should have a clear purpose.

Add a variable in the editor​

  1. Open the voice-agent editor.
  2. Select Configuration.
  3. Expand Variables.
  4. Select + Add Variable.
  5. Enter the name without braces.
  6. Enter the verified text value.
  7. Wait for the draft save state to confirm success.

The value is text. If you enter a number, list, or structured block, the model still receives its textual representation.

Insert a reference​

Place the cursor at the intended location in the Prompt Editor, select {{variable}}, and choose a configured variable.

You can also type the reference directly:

SOURCE OF TRUTH
- Business: {{business_name}}
- Hours: {{business_hours}}
- Service area: {{service_area}}

Use the canonical form without spaces inside the braces. A reference can appear more than once, but repeated large values increase prompt size and make the policy harder to maintain.

Write instructions around the value​

A variable supplies data, not behavior. Explain how the agent should use the value.

Weak:

{{business_hours}}

Better:

Use {{business_hours}} as the approved operating schedule. Do not promise service outside these hours. If the caller requests an unavailable time, offer the approved next step.

Do not let a variable value redefine the agent's role or contain untrusted instructions. Values are inserted into the system prompt and therefore receive high-priority model context.

Update a variable safely​

For a production agent:

  1. Confirm the new value with its authoritative owner or source.
  2. Update the variable in the draft.
  3. Search the prompt for every reference to that name.
  4. Test the relevant normal and edge cases.
  5. Publish a version with a note identifying the fact that changed.
  6. Confirm a new live conversation uses the updated value.

Do not repurpose an existing name for a different concept. Create a clearer name, update its references, test, and then remove the old variable.

Remove or rename a variable​

Before removing or renaming it, search the entire system prompt for its token. Update every reference first.

If the prompt still contains an unresolved token, the editor can show a variable warning. The runtime also replaces unresolved brace placeholders with not provided rather than sending the raw token to the model. That fallback prevents leakage of editor placeholders; it is not a substitute for fixing the draft.

Built-in and legacy names​

The Wirevox prompt compiler recognizes these built-in names when their corresponding configuration exists:

  • {{business_name}};
  • {{business_hours}};
  • {{services}};
  • {{faqs}}; and
  • {{knowledge_base}}.

Templates and newer agents can also configure familiar names such as business_name as custom variables. A custom variable with the same name is resolved first and shadows the corresponding built-in value. Avoid configuring both sources for the same name.

{{knowledge_base}} is special. An attached knowledge base is handled by the knowledge runtime, and its instructions are injected automatically even when this token is omitted. Do not paste raw knowledge content into a variable.

Security and quality rules​

  • Never store passwords, API keys, access tokens, or private credentials.
  • Do not store raw caller messages or other untrusted text as system variables.
  • Do not use a variable to conceal a policy that reviewers need to see clearly.
  • Keep values concise; long repeated context can increase latency and model usage.
  • Verify legal, medical, financial, pricing, warranty, and safety statements with the responsible source.
  • Publish variable changes through the normal draft lifecycle.

Next steps​