Agent releases rarely change one thing. A deployment can include application code, a system prompt, tool schemas, routing logic, and a model selection. Rollback only works when those parts share a release identity.
Define the release boundary
Store immutable references for code, prompts, configuration, tools, and model policy. The release record should be sufficient to reproduce the behavior that served a production run.
Compare canary and stable traffic
Send a small, representative slice of traffic to the candidate release. Compare outcome rate, latency, errors, retries, and unit cost with the stable version using the same time window and customer segments.
Automate the stop condition
A rollback policy should state what happens when an objective is breached: halt the rollout, restore the stable release, preserve affected traces, and notify the owning team.
Keep the history readable
Deployment history should show who changed what, when traffic shifted, which alerts fired, and why a rollback happened. That record is more valuable than a list of container hashes with no product context.