Managing Versions

Agentria manages an Ability's or Agent's change history through deploy versions (Version). To deploy a workflow as an API, you first need to create this deploy version, which makes version management an essential prerequisite for API release.

Good version management gives you the following benefits.

• Track changes clearly.

• Reduce confusion among team members when collaborating.

• Roll back to a stable earlier version if something goes wrong.

• Provide reliable updates to your users.

This guide walks you through when to bump each part of the version number, how to create a version, how to check version history, and how to roll back to a previous version.

Version Numbering Rules

Agentria projects follow Semantic Versioning. (See 🔗semver.org)

A version number is made up of Major.Minor.Patch, and each part is bumped according to the rules below.

For example, a version might be bumped like this.

• 1.4.2 → 1.4.3 (bug fix)

• 1.4.2 → 1.5.0 (feature added)

• 1.4.2 → 2.0.0 (breaking change)

Step 1: Creating a Version

Click the Version button at the top-right corner of the canvas, then click the + icon (Save Version, i.e. Create Version).

Create version popup

Create a deploy version in the popup. Following the versioning rules above, enter a version number and description, then click Create.

Step 2: Checking Version History

Each version you create can be found in the History tab.

Step 3: Rolling Back

Selecting a version in the history shows you the node configuration at that point in time. Click Rollback to this version to revert to it.

Rolling back without first creating a version for your current work permanently deletes all unsaved changes and test history — this cannot be undone. Always create a version of your current state before rolling back.

Next Steps

Once you've created a version, you can deploy it as an API.

• 🔗API Release Guide — Learn how to deploy the version you created as an API service.

Frequently Asked Questions

When should I create a new version?

Create a new version after changing your workflow's node configuration or logic, when you want to deploy that state as an API or leave a point you can return to later. In particular, always create a version of your current state before rolling back so you don't lose your work.

How do I know whether to bump the major, minor, or patch version?

First check whether the change breaks existing users' workflows or API calls. If it does, bump the major version. If it only adds a feature while keeping existing behavior intact, bump the minor version. If it only fixes a bug without changing behavior, bump the patch version.

What gets lost when I roll back?

Everything you changed on the canvas after the rollback point — that is, after the last version you created — along with the test history from that period, is lost and cannot be recovered. Saving your current state as a version before rolling back prevents this.

How should I write a version description?

Keep it concise so teammates — or you, in the future — can immediately understand what changed and why. Writing something specific like "Added retry logic for failed payments" or "Improved summary generation prompt" makes it easy to find the version you're looking for in the history later.