Launch Is Not a Switch
An agent is software: version everything, release through gates (offline, shadow, canary, full), roll back when the SLO dips. Flags make gradual rollout and cutoffs possible.
"Deploy finished" is not "shipped". One full cutover turns every user into the treatment group; a team that treats release as a process stops failures at gates before they reach anyone. An agent is software, and not one line of conventional release engineering can be skipped for it — and because prompts, model versions and tool endpoints are all part of the behavior, there is actually more to version, not less.
Version everything first
At least three things belong under version control: prompts, tool schemas and tool servers, and safety switches plus model selection agents-in-action-8. Keeping prompts in the same repository as the code is usually enough; a separate versioning scheme is a legitimate choice, and the point is the same — prompts can be optimized and rolled back without touching code. The one line people miss: pin and record the model version and tool endpoint actually used in each conversation turn. Without it results are not reproducible, and the postmortem cannot answer "which version was running at the time". In a system with no version record, a rollback just pushes a different unknown out the door.
Gates, with automatic rollback on SLO dips
The gradual path is fixed: offline tests, then shadow traffic, then a small canary, then full rollout; if the service-level objective dips, roll back automatically agents-in-action-8. Each gate answers a different question. Offline tests ask "better than the status quo?". Shadow traffic asks "what does it get wrong on real inputs where nobody is affected?". The canary asks "did the experience drop for a small group of real users?". Agents add one special case: a change that trades intelligence for performance — a smaller model, a lower reasoning tier — needs a soak period before scale-up even when every metric is green, because users report "it got dumber" far later than an eval does. The Anthropic rollback in Turn Failures Into Engineering Assets was exactly this kind of default change. And the gate sequence is not something you assemble the week of launch: Online and Offline Evals supplies the measurement for shadow and staged traffic — a gate simply turns that measurement into a pass condition.
Flags are the foundation under the release
Feature flags — turning a capability on or off remotely, with no redeploy — serve three purposes at once: experiments, gradual rollout, emergency cutoff ai-agent-book-7. Without flags, "gradual rollout" degrades into "redeploy an older build" and the emergency cutoff degrades into a paging incident. Two implementation details matter. Compile-time flags physically remove the code from the artifact during the build, so an internal-only feature does not exist at all in an external build and cannot be discovered by reverse engineering — which doubles as a clean ablation mechanism: turning a capability off is not a runtime skip, it is absence. A/B routing requires the change to be reclaimable per population, so it supports either fast rollback or gradual scale-up.
Self-modification goes down the same pipeline
Release engineering applies to continuous evolution as well. An agent modifying itself is not a running process overwriting its own body: create an isolated update branch from the current stable version, have a Coding Agent produce the minimal patch, and only generate a deployable version after it passes static checks, unit tests, security scanning, failing-trace replay and regression on older tasks ai-agent-book-9. Evolution proposals follow the same gates: boundary cases improved, older tasks not degraded, release threshold passed — all three, then staged rollout. This pipeline turns "self-modification" from a science-fiction word into an auditable software release, and it is precisely because the pipeline exists that the next chapter dares to discuss letting the system change itself.