Every deploy to an agent creates a new, immutable version. This makes it possible to roll back instantly if a new version misbehaves, without losing the history of what changed and when.
How versioning works
Each time you run sublayr deploy against an existing agent, Sublayr creates a new version (e.g. v1.4.0) rather than overwriting the previous one. The previous version remains available and can be reactivated at any time. Versions are immutable — once created, a version's config cannot be changed, only superseded by a new one.
Listing versions
This returns every version of the agent, in order, with its creation timestamp, the config diff from the previous version, and whether it's currently active.
Rolling back
If a new version causes problems — failed runs, unexpected costs, incorrect tool calls — roll back to the last known-good version immediately:
Rollback takes effect within seconds and does not require a new deploy or config change. The rolled-back version becomes the active one, and any in-flight runs on the previous (bad) version are allowed to complete or fail gracefully depending on their current step.
Automatic rollback on failure spikes
You can configure automatic rollback if a new version's failure rate exceeds a threshold within its first N runs:
With this set, Sublayr monitors the first 10 runs of any new version and automatically reverts to the previous version if more than 20% fail.
Comparing versions
To see exactly what changed between two versions:
This shows a structured diff of the config — which fields changed, were added, or were removed.
Best practices
Always deploy to staging before production, even for small config changes
Use descriptive commit-style messages when deploying, so version history is meaningful:
sublayr deploy --config agent.yaml --message "add refund approval gate"Set up automatic rollback thresholds for any agent handling customer-facing or financial actions
Review the diff before promoting staging changes to production
