Agent versioning
Agent versioning allows you to experiment with different configurations of your agent without risking your production setup. Create isolated branches, test changes, and gradually roll out updates using traffic percentage deployment.
Overview
The versioning system provides:
- Immutable snapshots of your agent configuration at any point in time
- Isolated branches for testing changes before going live
- Traffic splitting to gradually roll out changes to a percentage of users
- Merging to bring successful experiments back to main
Once versioning is enabled on an agent, it cannot be disabled. Consider this before enabling versioning on existing agents.
Core concepts
Versions
A version is an immutable snapshot of an agent’s configuration at a specific point in time. Each version has a unique ID (format: agtvrsn_xxxx) and contains:
conversation_config- System prompt, LLM settings, voice configuration, tools, knowledge baseplatform_settings- Versioned subset including evaluation, widget, data collection, and safety settingsworkflow- Complete workflow definition with nodes and edges
Versions are created automatically when you save changes to a versioned agent. Once created, a version cannot be modified.
Branches
Branches are named lines of development, similar to git branches. They allow you to work on changes in isolation before merging back to the main branch.
- Every versioned agent has a Main branch that cannot be deleted or archived
- Additional branches can be created from any version on the main branch
- Each branch has: id (
agtbrch_xxxx), name, description, and a list of versions - Branch names can contain: letters, numbers, and
() [] {} - / .(max 140 characters)
Traffic deployment
Traffic can be split across multiple branches by percentage, enabling gradual rollouts and A/B testing.
- Percentages must always total exactly 100%
- Traffic routing is deterministic based on conversation ID (the same user consistently routes to the same branch)
- Only non-archived branches with 0% traffic can be archived
Drafts
Unsaved changes are stored as drafts, allowing you to work on changes without immediately creating a new version.
- Drafts are per-user, per-branch (each team member has their own draft)
- Drafts are automatically discarded when a new version is committed
- Drafts are also discarded when merging into a branch
Enabling versioning
Versioning is opt-in and must be explicitly enabled. You can enable it when creating a new agent or on an existing agent.
Once enabled, versioning cannot be disabled. This is a permanent change to your agent.
Enable when creating an agent
Enable on an existing agent
Enabling versioning creates the initial “Main” branch with the first version containing the current agent configuration.
Working with branches
Creating a branch
Branches can only be created from versions on the main branch. You can optionally include configuration changes that will be applied to the new branch’s initial version.
Listing branches
Getting branch details
Committing changes
When you update an agent with versioning enabled, specify the branch_id to create a new version on that branch.
A new version is automatically created on the specified branch, and any existing draft for that user on that branch is discarded.
Deploying traffic
Use the deployments endpoint to distribute traffic across branches. This enables gradual rollouts and A/B testing.
Traffic routing is deterministic based on the conversation ID, ensuring the same user consistently reaches the same branch across sessions.
Merging branches
When you’re satisfied with changes on a branch, merge them back to the main branch.
Merging:
- Creates a new version on the main branch with the source branch’s configuration
- Optionally archives the source branch (default behavior)
- Automatically transfers traffic from the source branch to main
You can only merge into the main branch. Merging between non-main branches is not supported.
Archiving branches
Archive branches you no longer need. This helps keep your branch list organized.
You cannot archive a branch that has traffic allocated to it. Remove all traffic before archiving.
Archived branches can be unarchived by setting archived=False.
Retrieving specific versions
You can retrieve an agent at a specific version or branch tip.
Get agent at specific version
Get agent at branch tip
Include draft changes
Settings reference
Versioned settings
These settings can differ between versions and branches:
Per-agent settings
These settings are shared across all versions:
Changes to name and tags on non-main branches don’t persist to the agent until merged to main.
Best practices
Create tests before branching
Set up automated tests that capture expected behavior before creating a new branch. This establishes a baseline and helps catch regressions early when iterating on your experiment.
Use descriptive branch names
Choose branch names that clearly communicate the purpose of the experiment. Include the feature
name, hypothesis, or ticket number for easy reference (e.g., feature/new-greeting-flow or
experiment/shorter-responses).
Document branch purposes
Use the branch description field to explain what hypothesis you’re testing, what metrics define success, and any dependencies or considerations. This helps team members understand active experiments.
Use drafts for work-in-progress
Save drafts frequently while iterating on changes. This preserves your work without creating unnecessary versions. Only commit when you’re ready to test or deploy.
Start with small traffic percentages
When deploying a new branch, begin with 5-10% of traffic. This limits exposure if issues arise while still providing meaningful data.
Monitor key metrics before increasing traffic
Use the analytics dashboard to compare branch performance. Look for call completion rates, average conversation duration, success evaluation scores, and tool execution rates. Only increase traffic when metrics meet or exceed your main branch baseline.