Unlike traditional software, AI agents operate in real time, and interact directly with users and systems. This makes version control critical: even small changes can impact customer experience. Operator’s versioning system ensures safe, structured iteration, enabling confident testing, controlled rollouts, and easy rollbacks when needed.

​
Versioning model

Revisions of your agent are numbered sequentially as v0, v1, v2, etc. Each revision represents a complete snapshot of your agent’s configuration at a specific point in time. At any given time, your agent will have:
  • One released revision that runs in production by default
  • Optionally, one draft revision that you’re actively working on
  • Multiple archived revisions (previous versions)
All revisions except for the draft are immutable. When you want to make changes:
  1. The system creates a draft based on your currently released version
  2. You can freely edit the draft, making changes to:
    • Prompt content: Instructions, templates, or conversation flow
    • Tool configurations: Adding or removing access to tools
    • Settings: Voice, knowledge bases, or channel configurations
You can save your draft as many times as needed while iterating. When you’re satisfied with your changes, clicking Release will promote your draft to the released version, making it immutable and active in production.
If you need to revert to a previous version of your agent, the process is simple: just release one of your archived revisions. Every previously released version remains available in your version history, allowing you to quickly restore any prior state of your agent with a single click. This makes it easy to recover from unexpected issues or return to a known good configuration at any time.

​
IDs

Identifiers follow a structured format:
  • Agent ID: ca_xxxx (points to the currently released version)
  • Pinned version: ca_xxxx@v3 (refers to a specific immutable version)
When you reference an agent without specifying a version, Operator defaults to the released version. This guarantees that production always runs on the intended config, while allowing developers to test against specific versions as needed.

​
Version binding

When a conversation starts, the platform locks in a specific agent version for the entire session:
  • Default behavior: New conversations automatically use the currently released version
  • Override behavior: When creating a conversation via API, you can specify a pinned version ID (e.g. ca_xxxx@v3) to bind the session to a specific version.
This ensures version consistency from start to finish, even if newer versions are released during the conversation.

​
Development workflow

1

Edit

Make prompts, tool, or configuration changes in the dashboard
2

Test

Validate the unreleased version using dashboard previews, API calls or evals
3

Release

Deploy the version to production when you’re ready
We designed the versioning system to accomodate both simple use-cases as well as complex deployments that require more vetting before pushing the changes to production. If you are just starting out, we recommend iterating quickly, making many small changes and hitting Release often. As you grow and your deployment scales, we recommend building up a robust evals set and metrics to ensure the quality of your agents as the behavior instructions evolve.

​
Testing

Use any of the following methods to test versions before release:
  • Dashboard: Make test calls directly from the agent editor
  • API: Target specific versions in your test API requests
  • Evals: (coming soon) run automated evaluations on a version for quality and regression tracking

​
Rollbacks

If a released version causes issues, you can quickly rollback by releasing a previous version:
  1. Navigate to the version history
  2. Select a stable previous version
  3. Click Release to restore previous functionality
You can also roll back via the API by specifying the desired version.

​
Advanced features

The following features are currently in development and will be available soon.

​
Partial rollouts

  • Traffic splitting: Route percentages of conversations to different versions
  • Gradual rollouts: Ramp up gradually to a new version while monitoring performance

​
Version comparison

  • Side-by-side metrics: Compare success rates, latency, and satisfaction
  • A/B testing tools: Evaluate different agent versions
  • Regression alerts: Flag underperforming versions automatically