Before retiring an agent, map its three dependency types: output consumers, enforced constraints, and masked failures
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.
Why This Is a Rule
Removing an agent from a system is the mirror image of adding one — and it carries the same hidden-cost risk. An agent that's been active for months has accumulated three types of dependencies that may be invisible until removal breaks them. Output consumers: other agents or processes that use this agent's output as their input. Removing the agent starves the consumers. Enforced constraints: behaviors the agent prevents through its rules or priorities. Removing the agent removes the constraint, allowing previously prevented behaviors to re-emerge. Masked failures: errors or degradation that the agent was silently compensating for. Removing the agent exposes the underlying failure that was hidden.
The third category — masked failures — is the most dangerous because it's invisible by definition. A "morning review" agent that feels redundant may actually be compensating for a weak prioritization system. Remove the review agent and you discover (too late) that without it, your prioritization drifts because the review was the mechanism keeping it on track.
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 elimination, monitoring for hidden dependencies during the transition (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 elimination, monitoring for hidden dependencies during the transition) for hidden dependencies that the audit missed.