Skip to main content
Level 2 — Lesson 5 of 6 — Tailor agent responses for different contexts without creating separate projects.
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 use cases

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 (and aren’t)

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.

​
How the Variant UI works

When no variants exist, you’ll see a primary Add Variant button.
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
Often a right-side drawer containing:
  • 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
Useful for bulk setup (many sites/locations) and sharing configurations across environments or projects.

​
When to use variants

Use variants when

  • You have repeatable structure but different values
  • You want to avoid copying the same Managed Topic content across multiple projects
  • You need to test and report on performance by context

Avoid variants when

  • The differences are so large that you effectively have a different agent
  • You are trying to solve a retrieval problem that should be fixed by better topic names

​
Planning your variant strategy

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

1

Open Variant management

Navigate to Variant management in the platform.
2

Click Add Variant

Start the variant creation process.
3

Configure variant settings

Set:
  • Variant name: use a naming convention that scales
  • Default variant: set one default so testing and Live always have a predictable fallback
  • Key fields: start with 1–3 fields that clearly affect behavior

​
Naming conventions that scale

site_001_downtownGood for large deployments with many locations

​
What to put into variants

Variants are most useful for content that is:
  • Frequently repeated in calls/chats
  • Specific to context
  • Risky if wrong
site_name, city, region
hours, address, parking_info, accessibility_info
“connect you to the front desk” vs “connect you to an agent”
Short, spoken-friendly alternatives for Call

​
Testing variants

1

Switch to a non-default variant

Select a variant other than your default
2

Run smoke tests

Execute the same tests you used earlier:
  • Simple FAQ (Chat and Call)
  • Multiturn FAQ
  • SMS/handoff topic phrasing (where relevant)
  • Any brand-sensitive language (greeting, disclaimers, closings)
3

Verify behavior

Confirm:
  • Switching variants changes only what you intended
  • 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

Start small

Keep the number of variant fields small at first. Add fields only when you have a clear use case.

Store facts

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.

Maintain a default

Always maintain a Default variant so there is a safe fallback when context is missing or misconfigured.