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.
Looking to run A/B tests? See Experiments for the recommended workflow for testing agent changes against live traffic.
The versioning system provides:
Once versioning is enabled on an agent, it cannot be disabled. Consider this before enabling versioning on existing agents.
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 edgesVersions are created automatically when you save changes to a versioned agent. Once created, a version cannot be modified.
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.
agtbrch_xxxx), name, description, and a list of versions() [] {} - / . (max 140 characters)Traffic can be split across multiple branches by percentage, enabling gradual rollouts and A/B testing.
Unsaved changes are stored as drafts, allowing you to work on changes without immediately creating a new version.
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.
Open your agent in the dashboard, go to Settings, and enable versioning. Once enabled, the Versioning tab becomes available for managing branches, drafts, versions, and traffic deployment.
Open your agent in the dashboard, navigate to Settings, and toggle versioning on.
Enabling versioning creates the initial “Main” branch with the first version containing the current agent configuration.
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.
When you update an agent with versioning enabled, specify the branch_id to create a new version on that branch.
Open your agent’s Versioning tab, switch to the target branch, edit the configuration, and save to create a new version.
A new version is automatically created on the specified branch, and any existing draft for that user on that branch is discarded.
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.
When you’re satisfied with changes on a branch, merge them back to the main branch.
Merging:
You can only merge into the main branch. Merging between non-main branches is not supported.
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.
You can retrieve an agent at a specific version or branch tip.
These settings can differ between versions and branches:
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.
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.
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).
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.
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.
When deploying a new branch, begin with 5-10% of traffic. This limits exposure if issues arise while still providing meaningful data.
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.