;
};
**Level 2 – Lesson 7 of 8** – Tailor agent responses for different contexts without creating separate projects.
[Variants](/knowledge/variants/introduction) let you maintain **one agent** while tailoring responses for different contexts – no separate projects needed. A variant is a **named configuration profile** that changes selected content or settings depending on where or how the agent is used.
## Common use cases
Different branches, properties, campuses, stores
Same company, different sub-brands with different tone or policies
Differences in hours, terminology, supported services, legal language
Chat vs Call wording; short vs spoken-friendly phrasing
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, showing which context handled each turn.
* **Not separate agents** - They share the same core configuration
* **Not environments** - Sandbox/Pre-release/Live are about safe promotion; variants are about contextual behavior
* **Not a retrieval fix** - Variants should refine, not rescue, retrieval
## 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
* 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
* 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
## Check your understanding
## 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
Navigate to **Knowledge > Variants** in the platform.
Start the variant creation process.
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_downtown`
Good for large deployments with many locations
`kansas_city`
Consistent with your existing naming conventions
`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
`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
**Content you usually should NOT vary:**
* 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)
## Testing variants
Select a variant other than your default
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)
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
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.
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.
## Check your understanding
## Try it yourself
You are deploying one agent for three hotel properties: The Linden (London), The Linden (New York), and The Linden (Tokyo).
Answer:
1. Write your one-sentence variant strategy statement.
2. List **3 fields** that belong in variants.
3. List **1 field** that should NOT be in variants – and explain why.
Think about what changes per property (hours, address, local phone number) vs what should stay the same (core agent role, safety rules, overall tone).
1. **Strategy:** "A variant represents a single Linden Hotel property."
2. **Fields in variants:**
* `hotel_name` (e.g., "The Linden London")
* `check_in_time` / `check_out_time`
* `front_desk_phone`
3. **Should NOT be in variants:** Safety policies (e.g., "Never share guest information"). These are non-negotiable constraints that should apply identically across all properties.
## Check your understanding
Lesson 6 of 8
Lesson 8 of 8