Skip to main content
Variants let you maintain one agent while tailoring its responses for specific contexts—without creating separate projects or forking your build work. Think of a variant as a named configuration profile that can change selected content or settings depending on where or how the agent is being used. Common reasons to use variants:
  • Site/location (different branches, properties, campuses, stores)
  • Brand (same company, different sub-brands with different tone or policies)
  • Region (differences in hours, terminology, supported services, legal language)
  • Channel (Chat vs Call wording; short vs spoken-friendly phrasing)
  • Audience segment (B2B vs B2C, member vs non-member)
What variants are
  • A set of values attached to a variant name (for example: site_name = "Example site"), used to customize how the agent responds in that context.
  • A way to keep shared logic and behavior consistent, while allowing specific fields to differ.
  • Visible during analysis: variants appear in Conversation review/diagnosis so you can confirm which context handled each turn.
What variants are not
  • Not separate agents.
  • Not environments (Sandbox/Staging/Production are about safe promotion; variants are about contextual behavior).
  • Not a replacement for good Knowledge Base structure (variants should refine, not rescue, retrieval).

​
How the Variant UI works

In Variant management, you typically see:
  • An empty state when no variants exist, with a primary Add Variant button.
  • A table/grid view when variants exist:
    • Each row is a variant (for example, Site 1 (default)).
    • Columns represent variant fields/attributes (for example, site_name, plus other fields your org has defined).
    • A search bar for finding variants quickly.
  • An Edit variant panel (often a right-side drawer):
    • Variant name (required): the label you will recognize in testing and reporting.
    • Default variant toggle: marks which variant is used when no other variant is selected.
    • Editable fields such as site_name, and any other attributes your configuration supports.
  • Import / Export controls:
    • Useful for bulk setup (many sites/locations) and sharing configurations across environments or projects.

​
When to introduce variants (and when not to)

Use variants when:
  • You have repeatable structure but different values (different addresses, accessibility info, hours, policies, routing copy).
  • You want to avoid copying the same KB topic content across multiple projects.
  • You need to test and report on performance by context (variants provide a clean audit trail).
Avoid variants when:
  • The differences are so large that you effectively have a different agent (new product line, new workflows, different intents).
  • You are trying to solve a retrieval problem that should be fixed by better topic names and sample questions.

​
Decide what a variant represents

Before creating anything, define one sentence your team agrees on:
“A variant represents ____________________.”
Examples:
  • “A variant represents a single hotel property.”
  • “A variant represents a specific store location.”
  • “A variant represents a brand under a multi-brand umbrella.”
This prevents “variant sprawl,” where variants become an unstructured dumping ground.

​
Create your first variant

Do
  • Open Variant management.
  • Click Add Variant.
  • Set:
    • Variant name: use a naming convention that scales (examples below).
    • Default variant: set one default so testing and production always have a predictable fallback.
    • Key fields: start with 1–3 fields that clearly affect behavior (for example: site_name, address_short, phone_number).
Naming conventions that scale:
  • site_001_downtown (stable and sortable)
  • kansas_city (human-friendly, consistent with internal naming)
  • brand_a_us (if your dimension is brand + region)

​
What to put into variants

Variants are most useful for content that is:
  • Frequently repeated in calls/chats
  • Specific to context
  • Risky if wrong
Examples of good variant fields:
  • Location identifiers: site_name, city, region
  • Customer-facing facts: hours, address, parking_info, accessibility_info
  • Escalation language differences: “connect you to the front desk” vs “connect you to an agent”
  • Channel-specific phrasing (short, spoken-friendly alternatives for Call)
Examples of content you usually should not vary in variants:
  • Broad agent role and overall scope (keep consistent across variants unless you truly operate different agents)
  • Safety policies
  • Core tone guidelines (small adjustments are fine; wholesale tone shifts are not)

​
Test variants (minimum checks)

Do
  • Switch to a non-default variant and run the same smoke tests you used earlier:
    • Simple FAQ (Chat and Call)
    • Multiturn FAQ
    • SMS/handoff topic phrasing (where relevant)
    • Any brand-sensitive language (greeting, disclaimers, closings)
Verify
  • Switching variants changes only what you intended (for example, site_name, hours, location-specific copy).
  • Core behavior remains consistent (no missing topics, no broken escalation language).
  • In Conversation review/diagnosis, you can clearly see which variant handled the interaction.

​
Operational tips

  • Keep the number of variant fields small at first. Add fields only when you have a clear use case.
  • Prefer storing factual, high-impact values (hours, addresses, names) rather than duplicating full KB answers.
  • Use Import/Export when onboarding many variants at once; it reduces manual errors and makes review easier.
  • Always maintain a Default variant so there is a safe fallback when context is missing or misconfigured.