Before retiring an agent, map its three dependency types
Before retiring any agent, map all dependencies by identifying what consumes its output, what constraints it enforces, and what failures it masks—then explicitly reroute, replace, or accept each dependency gap.
When This Fires
- Before removing any behavioral agent, process step, or system component
- When an agent "isn't doing much" and seems ready for retirement — check what it's silently doing
- During agent portfolio pruning when reducing system complexity
- Complements Remove agents gradually — reduce frequency before… (graduated shutdown) with the pre-shutdown audit
Common Failure Mode
Removing agents that seem inactive: "This agent hasn't produced visible output in weeks — let's remove it." But the agent may be enforcing a constraint (preventing you from checking email during deep work) or masking a failure (catching errors that would otherwise propagate). Visible output is only one of three dependency types.
The Protocol
(1) Before removing any agent, audit three dependency categories: Output consumers: what processes, agents, or activities use this agent's output? Will they function without it? Enforced constraints: what behaviors does this agent prevent or limit? If the agent is removed, what previously prevented behaviors could re-emerge? Masked failures: what errors or degradation might this agent be compensating for? What would happen if the compensation stopped? (2) For each identified dependency: Reroute (redirect the dependency to another source), Replace (install a substitute mechanism), or Accept (explicitly acknowledge the gap and its consequences). (3) Only retire the agent after all dependencies are handled. (4) Monitor post-retirement (Remove agents gradually — reduce frequency before…) for hidden dependencies that the audit missed.