## Definition **Decommission discipline** is the practice of actively retiring automation — agents, skills, hooks, MCP servers, standing rules — that no longer earns its place in the platform. The under-discussed counterpart to building. ## Symptoms an Agent Has Overstayed Its Welcome - **Humans always override its verdict.** A critic overruled 80% of the time is a tax, not a filter. - **It never finds anything.** A security auditor that has passed every PR for two months is either perfect or asleep. Test it; bet on the latter. - **It introduces a new failure mode.** A release manager that occasionally publishes broken versions is worse than no release manager. - **It's a single point of dependency on a brittle prompt.** When the underlying model changes, brittle prompts break. ## The Cure Is Rarely "Delete the Agent" It is usually: **tighten the spec the agent works against**, then re-evaluate. See [[Spec-Driven Development]]. ## Decommission Audit (quarterly) For each component installed (agents, skills, MCP servers, hooks, `AGENTS.md` rules): | Component | What it does | Last earned its keep | Verdict | | --------- | ------------ | -------------------- | ------- | - KEEP — has a recent, concrete event where it added value. - TUNE — is doing the wrong thing or producing too many false positives. - RETIRE — no recent value or actively harmful. ## Why It Matters - Untended automation accumulates as a tax on every session — tokens, false positives, cognitive overhead. - Older prompts were often built around model behaviours that newer models have surpassed; the underlying gap has closed but the cruft remains. - A clean platform is also a measurable one ([[DORA Metrics]]). ## Hard Move Actually delete components marked RETIRE. *No commented-out leftovers.* They rot. ## Related - [[Orchestrator Role]] - [[DORA Metrics]] - [[Specialized Agent]] - [[Hook]]