> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Chapter 9 · AgentOps: Running the Fleet on Day 2

> The pilot ends; the fleet remains: version management, model migrations, memory hygiene, and postmortems for a new kind of teammate.

*The pilot ends; the fleet remains. Day 2 is version management, model migrations, memory hygiene, and postmortems for a new kind of teammate.*

## 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.

<Info>
  **IN PRACTICE — THE FLEET, LIVE**

  Day 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.
</Info>

<Tip>
  **KEY TAKEAWAY**

  Day 2 is a discipline: versioned bundles gated by evals, model migrations run as projects with per-class diffs, memory gardened on a cadence with owners, blameless mechanism-classified postmortems that grow the golden set, and a named engineer whose week makes all of it routine. Fleets that institutionalize this compound; fleets that don’t decay into the very toil they replaced.
</Tip>