Skip to main content
Versioning is how you make your trained AI available to users. Each version is an immutable snapshot of your AI’s complete configuration at a specific point in time. Understanding how versions and deployments work ensures smooth, controlled updates without disrupting live customer interactions.

​
Why Versioning Matters

Versioning provides the control and safety you need to manage AI deployments:
  • Safe updates - Test changes before going live
  • Version control - Track what changed and when
  • Easy rollback - Revert to previous versions if needed
  • Consistency - All channels use the same version simultaneously
  • Audit trail - See complete history of your AI’s evolution
Versioning separates development from production. You can continue refining your AI while users interact with a stable, tested version.

​
How Versioning Works

The deployment system has three key concepts:

​
1. Profiles (Your Work in Progress)

A profile represents your AI’s current configuration:
  • Guidance instructions and rules
  • Tool and integration settings
  • LLM model selection and parameters
  • Audience targeting rules
  • General settings and preferences
You can edit guidance, enable tools, and adjust settings which are saved upon “build” into a new snapshot.

​
2. Versions (Immutable Snapshots)

Versions are numbered snapshots (#1, #2, #3…) containing:
  • Profile configuration (guidance, tools, LLM settings)
  • Knowledge snapshots (all sources at build time)
  • Creation timestamp
  • Immutable - never changes after creation
Creation: Building a profile version creates a new deployment automatically. Numbering: Sequential numbers (#1, #2, #3) assigned automatically as you build versions.
Versions are immutable by design. Once built, they never change. This ensures consistency - version #12 behaves identically every time, whether you deploy it today or next month.

​
3. Aliases (Production Pointers)

An alias is a named pointer to a specific version:
  • “Production” alias represents the currently active configuration
  • Can be updated to point to different versions
  • All channels connect to aliases, not directly to versions
  • Allows switching versions without reconfiguring channels
When you update an alias from version #12 to version #13, all channels using that alias switch immediately with no downtime or configuration changes needed.

​
Deployment Architecture

Website Widget ─┐
Zendesk        ─┼─→ Production Alias ─→ Version #5 (Profile v0.5)
Salesforce     ─┤                          ├─ Knowledge Snapshot
Slack          ─┘                          ├─ Guidance Rules
                                           ├─ Tool Configuration
                                           └─ LLM Settings

Available Versions:
├─ Version #5 (active) ← Production points here
├─ Version #4
├─ Version #3
├─ Version #2
└─ Version #1

​
Building and Deploying

The typical workflow for deploying AI changes:

​
Step 1: Make Changes

Edit your AI configuration:
  • Update guidance instructions
  • Add knowledge sources
  • Enable/disable tools
  • Adjust audiences
Changes are not immediately deployed - they’re saved in your editing session.
Work freely in your profile without worrying about affecting live customers. Changes only go live when you explicitly build and deploy a version.

​
Step 2: Test in Preview

Before building a version, test your changes: Use Preview Mode
  1. Navigate to Behavior → Guidance
  2. Click the preview/test interface
  3. Ask sample questions
  4. Verify responses match expectations
  5. Check that tools work correctly
What Preview Shows
  • Current profile configuration (not deployed version)
  • Latest knowledge from data providers
  • All active guidance rules
  • Enabled tools and integrations
For comprehensive testing, use test suites. Learn more in Testing AI Agents.

​
Step 3: Build Version

Navigate to Behavior → [Review your changes] and click Build Version, Set Active This process:
  1. Creates new profile (e.g., v0.5 → v0.6)
  2. Captures knowledge snapshot - Indexes current state of all data providers
  3. Builds deployment - Compiles everything into deployable package
  4. Updates Production Alias - Points to new version
  5. Deploys to all channels - All connected integrations use new version
Build time: 30-60 seconds for most configurations
Building creates an immutable deployment. Once built, versions cannot be modified - you must build a new version for any changes.

​
Build Options Explained

Build Version, Set Active (Recommended)
  • Creates deployment AND sets as production
  • All channels immediately use new version
  • Takes 30-60 seconds
  • Use for: Normal updates
Build Version (Advanced)
  • Creates deployment without setting as production
  • Test version before going live
  • Manually set as active later
  • Use for: Major changes you want to review first
Build Version, Set Active, Get Email (Enterprise)
  • For deployments affecting many channels
  • Runs asynchronously in background
  • Email notification when complete
  • Use for: Large-scale deployments with 10+ channels
Building with “Set Active” deploys changes to all connected channels immediately. Ensure you’ve tested thoroughly before using this option for significant changes.

​
Step 4: Monitor Impact

After deployment:
  1. Check conversations for new version
  2. Monitor metrics (CSAT, resolution rate)
  3. Review for any issues
  4. Rollback if needed (see below)
Immediate Checks (First 5 minutes)
  • Test sample questions in each channel
  • Verify responses match expectations
  • Check that new knowledge is accessible
  • Confirm tools work correctly
Short-term Monitoring (First Hour)
  • Review incoming conversations
  • Watch for error rates or unusual patterns
  • Check customer satisfaction scores
  • Monitor escalation rates
Ongoing Evaluation (First 24 Hours)
  • Compare metrics to previous version
  • Review conversation topics and outcomes
  • Gather team feedback
  • Identify any issues requiring rollback or fixes

​
Managing Versions

View and manage all versions in Behavior → General → Versions

​
Version List

Each version shows:
  • Version number (#1, #2, #3…)
  • Profile name (v0.0, v0.1, v0.2…)
  • Status - “Production” badge if active
  • Creation date - When version was built
  • Description - Build notes (e.g., “Build for profile v0.5”)

​
Setting a Version as Active

To switch production to a different version:
  1. Navigate to Behavior → General → Versions
  2. Find the version you want to activate
  3. Click the ⋮ menu next to the version
  4. Select Set as Active
  5. Confirm the change
What happens:
  • Production Alias updates to new version
  • All channels switch immediately
  • Previous version remains available for rollback
Changing active version affects all connected channels immediately. Users will see the new version in their next interaction.

​
Rolling Back

If a deployment causes issues, roll back quickly:

​
Quick Rollback Process

  1. Identify the problem - Check conversations, metrics, errors
  2. Navigate to Versions - Behavior → General → Versions
  3. Find previous good version - Usually the version before current
  4. Set as Active - Click ⋮ → Set as Active
  5. Verify - Test with sample questions
Rollback Timing: From problem identification to restored service: 2-5 minutes

​
When to Roll Back

Immediate rollback if:
  • CSAT drops significantly (> 0.5 points)
  • High error rates in conversations
  • Knowledge sources missing or incorrect
  • Tools not working as expected
  • User complaints spike
Wait and monitor if:
  • Minor changes in metrics
  • Isolated issues affecting few users
  • Issues can be fixed quickly with knowledge updates

​
Post-Rollback

After rolling back:
  1. Review what changed between versions
  2. Identify root cause
  3. Fix in development
  4. Test thoroughly
  5. Build and deploy again when ready

​
Channels and Production Alias

Understanding how channels connect to deployments helps manage updates effectively.

​
Viewing Connected Channels

Navigate to Behavior → General → Channels to see:
  • All active channels
  • Which alias they’re connected to
  • Current version each is using
  • Links to configure each channel

​
Channel Display

For each channel, you’ll see: 
[Website Widget] ─→ [Production Alias] ─→ [Version #5]
  My Website                                  v0.5
                                              2 days ago

​
Channel-Specific Behavior

Website Widget
  • Updates apply to new chat sessions immediately
  • Existing open chat windows may use previous version until refresh
  • Users who reload page get new version
  • Consider deployment timing around peak traffic
Zendesk
  • Agent assist suggestions use new version immediately
  • Automated responses switch instantly
  • No impact on ticket workflow or history
Salesforce
  • Case deflection uses new version for new cases
  • Agent assist updates immediately
  • Historical case data unaffected
Slack
  • Bot responses use new version immediately
  • Direct messages and channel mentions update instantly
  • Message history shows previous version’s responses
WhatsApp
  • New messages use new version immediately
  • Conversation history preserved
  • No impact on message delivery
While version switches are instant at the platform level, browser caching may cause brief delays (1-2 minutes) for website widgets. Users who refresh get the new version immediately.

​
Adding Channels

Channels are configured outside the Behavior section:
  • Website Widgets: Navigate to Frames
  • Zendesk: Navigate to Integrations → Zendesk
  • Salesforce: Navigate to Integrations → Salesforce
  • Slack: Navigate to Integrations → Slack
  • WhatsApp: Navigate to Integrations → WhatsApp
Once configured, channels automatically appear in Behavior → General → Channels.

​
Knowledge Snapshots

Each deployment includes a knowledge snapshot capturing all sources at build time.

​
What’s Included

When you build a version, the knowledge snapshot includes:
  • All synced data provider sources
  • All snippets from collections
  • Search table data (references, not copies)
  • Current state of all embeddings

​
Why Knowledge is Versioned

Your knowledge sources are constantly evolving. Without versioning, your AI’s behavior would change unpredictably as knowledge updates. This creates problems: Inconsistent Responses - The same question might get different answers depending on when it’s asked. Untested Changes - New knowledge affects responses without validation or review. No Rollback Path - If updated knowledge causes issues, you can’t revert to previous working state. Debugging Nightmares - Impossible to know which knowledge version caused a specific response.

​
Knowledge Staleness Indicator

After data providers sync new content, you’ll see:
  • Orange indicator: “Knowledge sources updated, rebuild needed”
  • Rebuild to update: Build new version to incorporate latest knowledge
  • Automatic syncs: If you have scheduled syncs, periodic rebuilds keep knowledge current
Schedule regular builds (weekly or monthly) if you have frequently updating data providers. This ensures your AI always has the latest knowledge.

​
Keeping Knowledge Current

Establish a rebuild schedule based on update frequency: Daily Updates (e.g., support documentation changes daily)
  • Build new versions daily or multiple times per day
  • Automate builds using API if needed
  • Monitor staleness indicators
Weekly Updates (e.g., product docs update weekly)
  • Build new versions weekly
  • Batch multiple knowledge updates into one version
  • Schedule builds during low-traffic periods
Monthly Updates (e.g., policies update occasionally)
  • Build monthly or as needed
  • Focus builds on significant knowledge additions
  • Combine with guidance improvements

​
Best Practices

​
Version Management

Build frequently for active development
  • During initial setup: Build after each significant change
  • Test each version before setting as production
  • Keep version history clean
Build less frequently for stable deployments
  • Weekly or monthly builds to incorporate knowledge updates
  • Only build for actual improvements, not minor tweaks
  • Batch multiple small changes into one version

​
Naming and Documentation

Profile names (v0.0, v0.1, v0.2):
  • Increment minor version for small changes (v0.5 → v0.6)
  • Increment major version for significant changes (v0.9 → v1.0)
  • Major version = new features, major guidance changes
  • Minor version = refinements, knowledge updates
Tracking changes: Keep notes of what changed in each version: 
v0.6: Added 15 snippets for API questions, updated tone guidance
v0.5: Enabled search_web tool, reorganized guidance priority
v0.4: Fixed billing knowledge gaps, improved escalation criteria

​
Testing Before Production

For major changes:
  1. Build version without setting active
  2. Test using preview frame in Behavior → Guidance
  3. Review with team if available
  4. Deploy to staging channel first (if you have one)
  5. Set as production when confident
Minimum Testing (Small Changes)
  • Preview test with 5-10 sample questions
  • Verify specific change works as intended
  • Quick smoke test across main features
Standard Testing (Normal Updates)
  • Run full test suite (20-50 test cases)
  • Preview test across multiple scenarios
  • Team review if multiple people involved
  • Check for regressions in core functionality
Comprehensive Testing (Major Changes)
  • Multiple test suites covering all features
  • Staging environment validation
  • Team review and sign-off
  • Phased rollout plan prepared
  • Rollback plan documented

​
Monitoring After Deployment

First 30 Minutes
  • Spot-check conversations manually
  • Test in each channel
  • Verify no immediate errors
  • Confirm expected behavior
First 24 Hours
  • Monitor key metrics (CSAT, escalation rate)
  • Review conversation topics
  • Check error logs
  • Gather team feedback
First Week
  • Compare metrics to previous version
  • Identify unexpected patterns
  • Review customer feedback
  • Document learnings

​
Deployment Timing

Deploy during periods that minimize impact:
  • Low traffic hours - Fewer customers affected if issues arise
  • Team availability - Ensure team can monitor and respond
  • Avoid critical periods - Don’t deploy during major events or holidays
  • Consider time zones - If global, choose time when most regions have low activity

​
Frequently Asked Questions

Symptoms: “Build failed” error when creating versionCommon causes:
  • TODO items in advanced configuration
  • No guidance defined (or system prompt)
  • Invalid JSON in tool configuration
  • Missing required fields
Solutions:
  • Review error message for specific issue
  • Check guidance tab has at least one active guidance
  • Verify tools configuration is valid JSON
  • Remove any TODO placeholders
Symptoms: Changes to data providers don’t appear in AI responsesCause: Haven’t rebuilt deployment with new knowledge snapshotSolution:
  1. Verify data provider synced successfully
  2. Build new version to incorporate changes
  3. Set new version as active
  4. Knowledge now available to AI
Symptoms: Some channels show old responses after deploymentCheck:
  • Verify production alias was updated
  • Confirm channels are connected to production alias (not old fixed versions)
  • Clear browser cache (for website widgets)
  • Check channel configuration hasn’t changed
Solution: Usually resolves automatically within 1-2 minutes. If persisting:
  • Rebuild and redeploy
  • Check channel configuration in respective integration settings
  • Contact support if issue continues
Symptoms: Build process shows “Building…” for > 5 minutesSolutions:
  • Wait up to 10 minutes (large knowledge bases take time)
  • Refresh page - may have completed
  • Check if deployment appeared in versions list
  • If still stuck after 15 minutes, try building again
  • Contact support if repeatedly failing

​
Advanced Patterns

For teams with staging/production separation:Staging Environment:
  • Separate project for testing
  • Copy configuration from production
  • Test changes here first
  • No real customer traffic
Production Environment:
  • Main project with real customers
  • Only deploy tested changes
  • Monitor closely after updates
To reduce risk of deploying changes:
  1. Deploy to one channel first:
    • Create separate alias for test channel
    • Set test alias to new version
    • Monitor for issues
    • Update production alias when confident
  2. Use separate projects for A/B testing:
    • Run two versions simultaneously
    • Route percentage of traffic to each
    • Compare metrics
    • Deploy winner to all channels
For advanced teams:
  • Use API to build versions programmatically
  • Trigger builds on knowledge sync completion
  • Integrate with CI/CD pipeline
  • Automated testing before production

​
Next Steps

Now that you understand versioning and deployments: Versioning gives you control over when and how changes reach your users. Use this power to maintain stability while continuously improving your AI.