Day-2 Operations
Keeping an agent alive after launch: the six drift sources, SLOs that measure the product instead of the server, the maintenance calendar, incident response for silent quality failures, runbooks you can run at 3am, the model-deprecation migration, and cost governance.
Last updated
After this section you can
- Name the six things that drift underneath a working agent
- Define agent SLOs and error budgets, and explain why uptime is a useless one
- Run a daily, weekly, monthly, and quarterly maintenance calendar
- Detect and respond to a silent quality failure that never pages anyone
- Write a runbook an on-call engineer can execute at 3am without a deploy
- Migrate off a deprecated model without a quality cliff
- Set up ownership and a weekly cost review that actually changes decisions
Day-2 Operations: Keeping Agents Alive
Deploy a web service and change nothing, and in six months it does exactly what it did on day one. Deploy an agent and change nothing, and in six months it is worse. This is the part nobody writes down.
Everything so far has been about getting an agent live and keeping it fast. This section is about the eighteen months after that: what drifts underneath a working agent, which four numbers tell you whether it is still good, the calendar that catches problems before customers do, and what you do at 3am when the pager rings for a system that is returning 200 OK and confidently wrong answers. Layered as always: plain English first, then the mechanics, then the staff-level detail.
A normal service is a closed system: its behaviour comes from code you control. An agent’s comes from a model you do not control, a prompt someone will edit, tools whose APIs will change, documents someone will update, and users who keep finding new ways to ask. Five of those six change without a deploy from you. Teams that treat an agent as done at launch do not get a dramatic failure — they get a slow slide they only notice when a customer escalates.