Branches, versions, and iterative release
When iterating communication agent configurations, use branches to isolate modifications and validations, use versions to save published snapshots, and then switch live configurations stably through the review and deployment process to avoid affecting ongoing calls.
Overview
Branches and versions separate "modifications under validation" from "stable configurations running externally." Branches determine which configuration set is live; versions determine which published and reviewed configuration snapshot that branch uses externally.
When creating a call task, you only need to select a communication agent. The system automatically routes each call detail to the latest live version of the agent's current active branch when scheduling, without using inactive branches, drafts, versions under review, rejected versions, or historical versions.
A communication agent can have multiple branches, but only one branch is active at any given time. Each branch can have multiple versions, but calls by default only use the latest live version of the active branch.
Key concepts
Object | Description |
Default branch | The default entry point when a communication agent is created; not equivalent to a permanently active branch. |
Debug branch | An isolated branch copied from an existing configuration or newly created, used to reproduce issues, experiment with changes, and run regression tests. |
Active branch | The only branch currently marked as active. |
Inactive branch | A branch that does not handle default calls and can continue to be edited, debugged, and tested. |
Draft version | The latest unpublished modifications in the current branch; can continue to be edited and used for debugging or testing. |
Historical version | A complete configuration snapshot formed at a publication event; can be viewed, compared, and traced back. |
Latest live version | The most recent published and approved version in the active branch that is available for calls. |
Branch management
A branch is a container for isolating modifications and validations. A communication agent can create multiple branches by business scenario, optimization direction, or bug fix, but there is always only one call entry point.
Core rules
At any given time, only one branch of a communication agent can be in the active state.
After you perform Deploy to live on another branch in the branch management, that branch becomes the new active branch, and the original active branch automatically switches to inactive.
Inactive branches and their drafts do not affect default calls and can be used for independent debugging, testing, and regression.
Switching the active branch changes the default routing for subsequently scheduled calls. Before switching, it is recommended to complete text tests, call tests, and related regression tests.
When to create a new branch
You need to reproduce a production issue without affecting the current stable configuration.
You need to make large-scale modifications to prompts, dialogue flows, variables, or tools.
You need to validate different business strategies or optimization plans in parallel.
When creating a new branch, the configuration from the source branch is cloned to the new branch. Small-scope fixes can be completed in the current branch; for larger-scope changes or multiple rounds of experiments, use a debug branch instead.
Version management and script review
A version is a complete configuration snapshot formed at a publication event within the same branch.
Release process
Edit the draft in the current branch and complete text tests, call tests, or regression validation.
Click Publish and select the qualification information that has passed the voice service review (only required for the first publication; cannot be modified after approval). The system creates a version snapshot and generates a script example based on the version prompt for review submission.
Versions under review or that have been rejected are not used for calls. If rejected, modify the draft based on the rejection reason and republish.
After passing the review, the version becomes the latest live version of the branch. The previous live version is retained in the historical versions for viewing, comparison, and traceability.
Only when the branch itself is active does its latest live version handle default calls. Even if an inactive branch has an approved version, you must first deploy the branch to live.
Publishing is not the same as deploying. Publishing a version generates a configuration snapshot and triggers a script review; deploying to live switches the only active branch.
Call boundaries of versions
Creating or modifying a draft does not immediately affect calls.
After the active branch publishes a new approved version, subsequently scheduled calls use the new latest live version of that branch.
Historical versions are used for reviews, comparisons, and traceability; they are not automatically selected by default calls.
Relationship with call tasks
Call tasks do not require manually selecting a branch and version. Each call detail automatically resolves the active branch and latest live version at the time it enters the scheduler.
Scenario | Routing and version handling |
Creating a task or importing numbers | Only associates the communication agent; does not pre-fix a version for all numbers. |
A call detail is scheduled for a call | Automatically takes the latest live version of the active branch at that time and writes the actual branch and version to the execution record. |
A call is in progress | Continues using the configuration confirmed at call start. Publishing a new version or switching the active branch afterward does not affect the ongoing call. |
The task is paused and the call detail is still pending | Pausing does not rewrite pending call details. After resuming, when the detail re-enters the scheduler, it re-resolves the active branch and latest live version at that time. |
Recommended iteration process
Start with failed test cases or problematic calls, and clearly document the issue symptoms and expected behavior.
Make the minimal fix in the current branch. For larger-scope changes or multiple rounds of experiments, create a debug branch.
Only modify the smallest scope each time, such as one node condition, one prompt section, or one variable rule.
First run the original failed test cases, then run the associated regression suite, and compare configurations, pass rates, and key call performance before and after the change.
After passing, publish the version and wait for the script review result. After approval, confirm whether the version is in the active branch.
When you need to use the debug branch for calls, deploy the branch to live. For unsuccessful attempts, discard the debug branch and retain the issue records.
After publishing or switching the active branch, validate with a small-sample task first before expanding the task scale.
Notes
Test retries or AI self-iteration typically use the latest draft of the current branch; this is test behavior. Actual calls use the latest live version of the active branch. Do not confuse the two.
Do not equate the "default branch" directly with the "active branch"; rely on the active status shown on the branch management page.
Version comparison involves more than just one prompt section; it also includes differences in dialogue flows, variables, notes, knowledge bases, tools, and call configurations.
When reviewing a production issue, first confirm the branch and version actually used for that call before identifying configuration differences.
Next steps
After completing the publication and deployment, validate the actual call performance using a small-sample call task. For more information, see Call task: create, execute, and analyze.