Why does removing agents cleanly fail?

The most common reason removing agents cleanly fails: Removing an agent by simply stopping it without tracing what depended on it. This is the most common failure mode in personal systems, and it mirrors the most expensive failure mode in software engineering: deleting a service without checking its consumers. The agent you retired might have been producing outputs that three other agents consumed, enforcing a constraint that kept two processes from conflicting, or providing a fallback that masked a weakness elsewhere. When you remove it by neglect rather than by design, you do not notice the damage immediately — you notice it weeks later, when downstream systems degrade in ways that seem unrelated to the change you made.

The fix: Identify one cognitive agent — a habit, routine, process, or tool — that you have stopped using in the past year, or that you are considering retiring. Map its dependencies: list every other process, habit, or system that consumed its output, relied on its side effects, or assumed its existence. For each dependency, write one sentence describing what happened (or would happen) when the retired agent stopped producing. Then, for each broken dependency, write one sentence describing how you could reroute, replace, or explicitly acknowledge the gap. You have just performed a dependency audit — the minimum prerequisite for clean agent removal.

The underlying principle is straightforward: When retiring an agent update everything that depended on it.