Remove agents gradually — reduce frequency before elimination, monitoring for hidden dependencies during the transition

Why This Is a Rule

Instant removal of a system component is the operational equivalent of pulling a random wire from an electronics board — you might get lucky, or you might cause a cascade failure from a dependency you didn't map. Graduated shutdown reduces this risk by making the removal incremental, giving you observation windows to detect hidden dependencies before full removal commits you to the consequences.

The graduated sequence mirrors Design three operating modes for every important process: full, reduced, and minimal — degrade fidelity but never lose continuity's three-mode design in reverse: instead of full → reduced → minimal → off (degradation), you go full → reduced frequency → minimal scope → fully off (retirement). At each step, you observe: does anything break? Does any downstream process starve? Does any previously masked failure surface? If nothing breaks at reduced frequency, reduce further. If something breaks, you've found a hidden dependency — address it before continuing the shutdown.

This is the agent-retirement analog of canary deployments in software: instead of deploying (removing) to all users (all contexts) simultaneously, you deploy to a subset and observe before expanding.

When This Fires

• When retiring any agent after completing the dependency audit (Before retiring an agent, map its three dependency types: output consumers, enforced constraints, and masked failures)
• When reducing system complexity by removing agents that seem low-value
• When an agent has been in degraded mode for extended periods and full retirement is considered
• When you want to test whether an agent is actually needed before permanently removing it

Common Failure Mode

Instant removal: "I don't need this agent anymore — deleted." Two weeks later, you discover the agent was compensating for a scheduling weakness that now produces missed commitments. By then, the behavioral chain is broken and reinstallation requires the full The first five consecutive executions of a new trigger are non-negotiable — this is the window where automaticity lives or dies (first five executions) process. Graduated shutdown would have revealed the dependency at reduced frequency, allowing you to address it before full removal.

The Protocol

(1) After dependency audit (Before retiring an agent, map its three dependency types: output consumers, enforced constraints, and masked failures), begin graduated shutdown: Week 1: reduce frequency by 50% (if daily → every other day; if weekly → biweekly). Monitor: does anything degrade? Week 2: if no degradation, reduce scope to minimal version. Monitor: does anything break at minimal scope? Week 3: if no degradation, fully suspend (don't delete — just stop executing). Monitor for one more week. Week 4: if no issues emerged during suspension → retire permanently. (2) At each stage, watch for: downstream processes producing lower quality, previously prevented behaviors re-emerging, or errors increasing in areas the agent touched. (3) If issues emerge at any stage → halt the shutdown, address the revealed dependency, then resume graduated removal after the fix is in place.