Skip to main content
Variables are an advanced feature for administrators building custom assistants. They let you inject dynamic values into prompts without hardcoding sensitive data or duplicating snippets across assistants.

​
What are Substitution Variables

Dynamic prompt placeholders. A variable is a named token like ${slack_webhook_url} that Pria replaces with a concrete value every time an assistant runs. Think of it as mail‑merge for prompts: the assistant’s instructions stay clean and reusable, and the actual value lives in one place that you can rotate independently. Here is an example assistant instruction using the variable ${praxis-ai-slack-url}: 
You are the 'Post To Slack' assistant. Your role is to compose a message
based on the user's request, then post it to Praxis‑AI's Slack channel
using the call_rest tool:

POST ${praxis-ai-slack-url}

Body:
{
  "text": "The user or assistant message!"
}
How they work. Just before the assistant’s prompt is sent to the model, Pria scans every system and assistant message for ${...} tokens and substitutes each with the corresponding variable value. The substitution happens server‑side, so the raw value never travels through the browser. Distinction from User Parameters. Variables operate at the instance level (shared across all users in the same Digital Twin). User parameters live in individual user memory and are private to each user. Use variables for shared infrastructure (URLs, IDs, instructions); use parameters for personal context.

​
Syntax

Variables use the form ${key} in any prompt or instruction text. 
Hello ${user_display_name}, your team channel is ${slack_team_url}.
The key must be alphanumeric (dashes and underscores allowed, no spaces). At runtime, every occurrence of ${key} in the system prompt and assistant instructions is replaced. If no variable with that key exists for the current user and instance, the literal ${key} is left in the prompt — useful for spotting typos quickly.
There are no global built‑in variables in Pria. Every variable you reference must be defined as a Variable record (by you, by another admin, or shared by the platform’s defaults). Personalization data like the user’s name, course context, and institution name are already injected into the assistant’s system prompt by Pria — you do not need to template them in.

​
Benefits

  • Single source maintenance — when a Canvas quiz ID changes from 123 to 789, update one ${quiz_id} variable and every dependent assistant picks up the new value automatically.
  • Cross‑assistant instruction reuse — store a shared instruction block as a variable and reference it from multiple assistants for consistency.
  • Security — sensitive data (access tokens, proprietary URLs) lives in the variable store, not inside the static prompt text. If a prompt is leaked or screenshot, the secret is not.
  • Composable workflows — when one assistant calls another (e.g. a teaching bot that calls a grading bot), each step can emit a value that plugs into the next step’s template through a variable.

​
Where Variables Resolve

Variables are substituted in:
  • System prompts and assistant instructions assembled for chat conversations.
  • Convo Mode (voice) sessions — the spoken assistant runs on the same substituted instructions.
  • The Chat Completions API — system/assistant messages sent through the OpenAI-compatible endpoint resolve variables too.
Variables are not substituted in user messages (the user’s typed input is passed verbatim) or in retrieved document content. Substitution is tied to the Digital Twin: variables resolve for conversations inside the instance where they are defined.

​
Variables in Assistants

Variables can be created and edited from within the assistant Edit dialog, or from the Variables section of your Digital Twin admin pages.
Assistant featuring a substitution variable

​
Create or Edit a Variable

Create assistant Variable
When adding a variable, define: Key — alphanumeric characters only, no spaces. Use dashes or underscores for multi‑word names (slack_webhook_url, quiz-id-fall-2026). Choose a name that is meaningful at the call site so prompts read clearly. Value — any text. The value is inserted into the prompt exactly as written, so treat it with the same care as the prompt itself. Best practice is plain text or a URL — avoid embedding unreviewed user‑authored content. Shared — when enabled, other administrators in the same instance can reference this variable in their assistants. Leave unchecked to keep the variable private to your own assistants. Admin Only — restricts who can see the variable’s existence and value in the Variables admin list. End users never see variables either way; this flag controls visibility among other admins. Editable (by Others) — when enabled, other admins can change the value. Leave unchecked for variables you want to own exclusively (e.g. credentials you rotated).

​
Scoping Rules

Variables resolve in this order at runtime:
  1. Variables owned by the current user (user‑scoped) — if a variable with the same key is defined privately for the user, it wins.
  2. Instance‑shared variables — variables marked Shared at the instance level are visible to every assistant run in that instance.
Within an instance, the same key cannot be defined twice as instance‑shared. The shared key is unique per instance. A user‑scoped variable with the same key takes precedence for that user only.

​
Naming Conventions

  • lowercase_underscore or lowercase-dash for keys (course_id, welcome-message). Pick one style and stick with it across your instance.
  • Prefix by purpose when the catalog grows — slack_*, canvas_*, prompt_* make it easy to find related variables.
  • Avoid colliding with internal placeholders — Pria’s own prompts use ordinary English text, but to be safe steer clear of generic words you might also use in prompt body text (name, id, value). Prefer specific names (student_full_name, course_canvas_id).
  • Document the variable in its value, or in a sibling variable, when its meaning isn’t obvious from the key — future admins will thank you.

​
Security Considerations

Variables are powerful because they inject content directly into the model’s system prompt. Treat them with the same care you’d treat any prompt:
  • Do not put true secrets (long‑lived API keys, password equivalents) in variables that are referenced by assistants the user can interact with. A motivated user can sometimes coax the model into echoing parts of its system prompt. Use Pria’s connector and integration features for credentials that must remain hidden.
  • Webhook URLs and quiz IDs are typically safe — they’re already shared with third‑party systems and have their own access controls.
  • Values are substituted verbatim — whatever the variable contains becomes part of the prompt, so a careless or hostile value can change model behaviour. Only mark a variable Editable (by Others) if you trust the other admins.
  • Audit before sharing — when you toggle a variable to Shared, every other admin can reference it in any assistant. Review the value before sharing.

​
Testing Variable Resolution

The fastest way to confirm a variable resolves is to author a tiny test assistant whose instruction is: 
The current value of my variable is: ${my_variable_key}
Run any prompt against this assistant; the response will echo the resolved value. If you see the literal ${my_variable_key} come back, the key is misspelled or the variable is not visible to your user.

​
Common Patterns

Define a shared variable like ${welcome_subject} (“Biology 101” / “Onboarding”) and inject it into the assistant’s intro message so the same assistant feels course‑specific.
Store a Slack webhook, a Canvas quiz endpoint, or a custom API URL in a single variable. Multiple assistants reference it. Rotating the URL is a one‑field edit.
Author a long, refined refusal policy or formatting guideline once as a variable, then reference it from every assistant that needs the same behaviour. Editing the variable updates them all.
Two instances of the same Digital Twin template can each define their own ${institution_short_name}, ${primary_color}, or ${escalation_email} without touching the assistant instructions.
  • Digital Twin Instructions — Authoring the base instructions where variables resolve
  • Assistants — Where assistant‑level variables are most often referenced
  • Configuration — Instance settings (some of which are exposed as variables)
  • Memory & Act As — Per‑user memory and parameters, the personal counterpart to variables