9.1 Everything is an artifact; every change is a deploy
The operable unit of an agent system is a versioned bundle: prompts and personas, tool schemas, skill implementations, policy files, retrieval configuration, judge rubrics, and model pins. Treat the bundle exactly like a service release — reviewed in pull requests, evaluated by the Chapter 7 gates, deployed progressively, rolled back atomically. The anti-pattern to hunt down is invisible change: a prompt edited in a console, a vendor-side model update, a tool description tweaked in place. If a change cannot be diffed, gated, and reverted, it will eventually be the root cause you cannot find — in a system whose entire pitch is finding root causes.9.2 The model migration playbook
Models will change under you on someone else’s schedule — deprecations, upgrades, price moves — and model swaps are the highest-variance change class in the stack. The playbook: pin versions explicitly (never “latest” in production); on a candidate model, run the full golden set and diff per incident class; canary on low-risk classes with online metrics watched (acceptance, rollback, step counts, cost — drift in step counts is the classic tell of a behavioral shift); keep dual-run capability so sensitive classes can shadow-compare old and new; and pre-negotiate deprecation windows with vendors so migrations are projects, not emergencies. Fleets that mix models — small fine-tuned models on routine classes, frontier models on novel investigation — apply the same playbook per lane, and gain a second benefit: a price shock or regression in any one model is a lane problem, not a fleet problem.9.3 Memory and knowledge hygiene
Chapter 2 designed memory; day 2 must garden it. A monthly hygiene cadence that works: review new memories written since last cycle (sampled, prioritizing high-impact classes); resolve contradiction flags where fresh evidence disputed stored conclusions; prune or decay memories referencing decommissioned topology; and re-index the knowledge layer after major estate changes. Assign ownership — the knowledge layer is a production dependency with an owner, not a wiki with good intentions. And close the loop the Field Guide promised: every resolved incident should end with an explicit “what did we teach the system?” line in its postmortem.9.4 Postmortems for agents
Agents will be wrong. The organizational reflex you want is the one SRE culture already knows: blameless, mechanism-focused postmortems — for software teammates. When an agent errs consequentially, reconstruct from the trace and audit record: what did it know (context audit), what did it conclude (reasoning audit), what did policy allow (governance audit), what did verification catch or miss (safety audit)? Classify the mechanism — context gap, retrieval miss, injection, tool defect, policy gap, judge blind spot, model regression — because each mechanism has a different fix, and “the AI made a mistake” is not a mechanism. Feed every event into the golden set as a new scenario. Then hold the symmetric line publicly: agent errors get engineered away with the same discipline as human errors, and neither gets a witch hunt. Nothing kills an agentic program faster than one bad incident handled as a betrayal instead of a defect.9.5 The role, made concrete
The Field Guide named the agent operations engineer; here is the week. Monday: review the weekend’s autonomous actions and any interventions; triage drift alerts. Tuesday: golden-set run for the pending bundle release; per-class diff review. Wednesday: memory hygiene block; retrieval-quality spot checks. Thursday: policy review with the autonomy owner — graduation candidates (acceptance >95%, clean rollbacks) and demotion candidates; approval-latency report to the on-call leads. Friday: red-team seed check (Chapter 5), cost report at the two-engine seam, and the monthly business dashboard when it falls due. It is a real engineering role with real leverage — one person operating the system that operates the estate — and it is the career path the category creates rather than the one it threatens.IN PRACTICE — THE FLEET, LIVEDay 2 is not hypothetical for us: CloudThinker runs as a fleet by construction — Anna orchestrates; Alex (cloud), Oliver (security), Tony (database), and Kai (Kubernetes) specialize — over a shared CloudSkills registry (325+), so a skill fix or a model change is a fleet event, not five separate ones. The living usage pattern is instructive too: among the largest sources of daily agent work we observe across customers are scheduled missions — the unglamorous nightly and weekly passes — which is exactly the traffic that makes Day-2 discipline pay for itself. Ask any vendor what their usage mix looks like; if it is all interactive chat, nobody is trusting the loop yet.