Agent Versioning & Deployment

Manage your agent's lifecycle safely with AgenticFlow's explicit versioning system. Versioning allows you to iterate on your agent's design, test new features in a draft state, and only publish changes when they are ready for your users.

Why Use Versioning?

• Safe Experimentation: Make changes to your agent's prompt, tools, or model without affecting live users.

• Release Control: Explicitly "publish" a version only when it's tested and ready.

• History & Rollback: Keep a snapshot of every major change and restore previous versions if something goes wrong.

• Dependency Protection: The system ensures you don't accidentally delete workflows or knowledge bases that your live agent depends on.

Key Concepts

1. Draft (Working Copy)

The Draft is your mutable development environment. All configuration changes happen here first.

• Editable: This is the only state where configuration (prompts, tools, models) can be modified.

• Private: Changes in the Draft are isolated from the production environment. Users interacting with the public agent do not see these changes until they are explicitly published.

• Testable: The Draft environment allows for testing and verification of new behaviors before they are committed to a version.

2. Versions (Snapshots)

A Version is an immutable snapshot of an agent's configuration at a specific point in time.

• Frozen: Once created, a version cannot be modified. It preserves the exact combination of system prompt, model settings, tool definitions, and knowledge base connections that existed when it was created.

• Traceable: Each version serves as a historical record, allowing you to track the evolution of your agent's logic and capabilities.

3. Published Version (Production)

The Published Version is the single active configuration that requests to the agent's public endpoints will use.

• Production Traffic: All interactions via the Public URL, Website Widget, or standard API integrations are routed to this version.

• Stability: The published version remains constant even while you continue to experiment and make changes in the Draft.

• Seamless Updates: Switching the published version updates the agent's behavior instantly for new conversations, without changing the agent's identity or endpoint URL.

---

The Release Lifecycle

The versioning system supports a structured deployment workflow designed for reliability.

Step 1: Iteration (Draft)

Development begins in the Draft state. During this phase, you can freely modify the agent's definition—tuning the prompt, adding or removing tools, or switching AI models. These changes are saved to the Draft but have no impact on the live agent.

Step 2: Snapshotting (Create Version)

When the Draft reaches a stable state or functionality that is ready for release, it can be saved as a Version. This action "freezes" the current Draft configuration into a numbered release (e.g., v1, v2). This snapshot is stored permanently and can be referenced later.

Step 3: Deployment (Publish)

To release changes to end-users, a specific Version is marked as Published. The system updates the live routing to point to this new version. This separation of "creating a version" and "publishing" allows you to maintain multiple historical versions while having control over exactly which one is live.

---

Management & Safety

Restoration (Rollback)

If development in the Draft diverges or introduces issues, the system allows you to Restore a previous version. This action overwrites the current Draft configuration with the settings from the selected version, effectively reverting the "working copy" to a known good state. This does not affect the Published version, ensuring safety during recovery.

Unpublishing

Agents can be Unpublished, which stops the agent from serving public traffic. This is useful for taking an agent offline for maintenance or decommissioning.

Dependency Integrity

The platform enforces referential integrity to prevent "broken" agents. Because a published agent relies on specific external resources (such as specific Workflows, Knowledge Bases, or Credentials), the system prevents the deletion of these dependent resources while they are in use by a published version.

• Deletion Blocking: Attempts to delete a resource used by a live agent will be blocked.

• Impact Analysis: The system identifies exactly which agent versions depend on the resource, requiring you to update or unpublish the agent before the resource can be removed.