The difference between stopping and retiring
The previous lesson established when an agent should be retired — the criteria that tell you an agent has outlived its usefulness or its context. This lesson is about how. And the distinction between stopping an agent and retiring an agent is the difference between abandoning a building and decommissioning it.
When you abandon a building, you walk away. The utilities are still connected. The contracts are still active. The mail still arrives. Other systems that depended on that building — the tenants, the delivery routes, the fire department's inspection schedule — continue to reference something that no longer functions. The building rots. The dependencies rot with it.
When you decommission a building, you disconnect the utilities, terminate the contracts, redirect the mail, notify the tenants, update the fire department's records, and document what the building was used for so that future decisions about the lot are informed by its history. The building is gone. Nothing that depended on it is left dangling.
Most people stop agents. Very few people retire them. And the difference shows up weeks or months later, when something that used to work stops working and nobody can remember why.
Why clean retirement matters: the dependency problem
Every agent you run — every habit, routine, system, or delegation — exists within a web of dependencies. Other agents consume its outputs. Other routines assume its existence. Other decisions rely on the conditions it maintains.
In software engineering, this is the central challenge of application decommissioning. A 2026 guide by Archon Data Store identifies the critical first step of any retirement process: mapping all upstream and downstream dependencies before touching anything. The reason is pragmatic. Even when the core application appears unused, integrations can remain active — downstream data feeds into finance, analytics, or compliance systems that nobody remembers connecting. Without dependency evidence, "turn it off" becomes what engineers call a high-stakes guess.
The same principle applies to personal agents. Your morning journaling routine does not just produce journal entries. It produces a state of mental clarity that your first meeting of the day depends on. It produces a record of commitments that your weekly review references. It produces a decompression period between waking and working that regulates your stress response. If you retire the journaling agent without understanding these downstream effects, you are not just losing a journal. You are disrupting clarity, review integrity, and emotional regulation — and you will not know which one broke first.
Atlassian's dependency mapping framework prescribes the same discipline for team systems: identify which systems, both upstream and downstream, will affect or be affected by the change, and be as comprehensive as possible. The comprehensiveness matters because partial dependency maps produce partial retirements, and partial retirements produce mysterious failures.
The anatomy of a clean retirement
Clean retirement has four components, executed in order. Skip any one of them and the retirement is incomplete.
1. Document what the agent did
Not just the obvious output — the full scope of what the agent produced, maintained, or enabled. This is harder than it sounds because agents accumulate responsibilities over time, and many of those responsibilities become invisible through familiarity.
In organizational knowledge management, researchers have identified this as the core challenge of employee offboarding. A study on organizational memory loss found that when key employees leave without documentation, years of experience and institutional knowledge vanish with them — not just the explicit procedures they followed, but the implicit knowledge of why those procedures existed, which exceptions they handled, and which other processes depended on their judgment. The research recommends capturing how departing employees think, not just what they do, because the reasoning behind actions is often more valuable than the actions themselves.
For your agents, this means documenting three layers:
The visible output. What the agent produces that you consciously use. The meal plan. The journal entry. The weekly status report.
The maintenance functions. What the agent keeps in a certain state as a side effect of its operation. The pantry stays stocked because the meal-prep agent includes a shopping step. The inbox stays at zero because the email-processing agent runs every morning. These maintenance functions are often invisible until the agent stops and the maintained state degrades.
The signaling functions. What the agent's operation tells you about the health of your broader system. If the morning run happens, you know your sleep was adequate, your motivation is intact, and your body is not injured. The run is not just exercise — it is a health signal. When you retire the running agent, you lose the signal along with the activity.
2. Document why it is being retired
This is the record that prevents second-guessing. Six months from now, you will not remember the specific reasoning that led to the retirement. You will remember that you used to do something and stopped, and the absence of reasoning will invite either nostalgia (it was so good, why did I stop?) or guilt (I was so disciplined, what happened to me?).
The nuclear power industry provides the most rigorous model for this documentation practice. The U.S. Nuclear Regulatory Commission requires licensees to submit a Post-Shutdown Decommissioning Activities Report (PSDAR) that describes the planned decommissioning activities, the schedule, the cost estimate, and the environmental impacts. The NRC is currently developing enhanced regulations based on lessons learned from plants that transitioned from operation to decommissioning since 2011, specifically to improve the transparency of the transition process. Transparency means that anyone examining the retirement later can reconstruct the reasoning, not just the outcome.
Your retirement document does not need to be a federal filing. But it needs to answer three questions that your future self will ask: What changed in the circumstances? Why was the agent no longer the right response to those circumstances? And was the decision made deliberately or by drift? That third question matters because many agent retirements happen by neglect — you stop doing something and retroactively decide it was a choice. Documenting the reasoning at the time of retirement prevents that revisionism.
3. Map everything that depends on the agent
This is the dependency audit. For every agent you are retiring, identify every other agent, habit, routine, or outcome that consumes its output or assumes its existence.
The discipline here comes from software engineering's approach to API deprecation. When a software company retires an API endpoint, best practice requires a comprehensive impact analysis before any changes are made. As documented by multiple API governance frameworks, the process begins with identifying all consumers — every system, integration, and workflow that calls the endpoint. The deprecation is not a single event but a phased process: announce the deprecation with a specific timeline, publish migration guidance, track usage of the deprecated endpoint until it reaches zero, and only then execute the final retirement.
The Sunset HTTP header, standardized in RFC 8594, exemplifies this rigor at the protocol level. When a server includes a Sunset header in its API responses, it provides a machine-readable date after which the endpoint will no longer be available. This allows consuming systems to discover the upcoming retirement automatically, rather than relying on human communication alone. The principle is that retirement should be discoverable by everything that depends on the retiring system.
For personal agents, the dependency map is built by asking: if this agent stopped producing its output tomorrow, what would break? Not what would be inconvenient — what would actually fail to function? Your morning planning routine produces a prioritized task list. Your task execution depends on that list. Your end-of-day review references that list to assess completion. Your weekly review aggregates the daily reviews. If you retire the morning planning agent, the entire chain downstream needs to know.
4. Name the replacement for each dependency
This is where retirement becomes succession planning rather than abandonment. For every dependency you identified in step three, you must specify one of three outcomes:
Transferred. Another agent absorbs this responsibility. The new agent is identified, it is capable of handling the responsibility, and the transfer has a specific date.
Consciously dropped. The responsibility is no longer needed. The circumstances that required it have changed along with the circumstances that required the retiring agent. You are not just stopping the work — you are declaring that the work no longer needs to happen. This declaration must be explicit, because unstated assumptions about what is "no longer needed" are the primary source of post-retirement failures.
Temporarily covered. The responsibility still matters but no permanent replacement exists yet. You install an interim measure — a manual check, a simplified version, a reminder — with a specific deadline for establishing the permanent replacement. Interim measures without deadlines become permanent gaps.
The extinction burst: why retirement feels wrong at first
There is a predictable psychological phenomenon that makes clean retirement difficult, and it has nothing to do with whether the retirement decision was correct.
In behavioral psychology, an extinction burst is a temporary increase in the frequency, duration, or intensity of a behavior that occurs immediately after the reinforcement for that behavior is removed. The phenomenon was first documented in operant conditioning research and has been extensively studied since. A 2023 review published in the Journal of the Experimental Analysis of Behavior examined 41 data sets and found that approximately 40 percent of cases showed a response burst — a temporary spike in the extinguished behavior — when extinction procedures were first implemented.
The mechanism is straightforward. When a behavior that has been consistently reinforced suddenly produces no reinforcement, the organism does not immediately conclude that the contingency has changed. Instead, it tries harder. It performs the behavior more frequently, more intensely, or with more variation, as if testing whether the reinforcement can be recovered. This spike is temporary — it precedes the decline — but it feels like evidence that the behavior is needed more than ever.
Applied to agent retirement: when you stop a long-running routine, you will often experience a period where the urge to perform the routine is stronger than it was when you were actually performing it. The retired morning run calls to you more loudly than the active morning run ever did. The abandoned journaling practice feels more essential in its absence than it did in its presence. This is not insight. It is an extinction burst. And if you interpret it as a signal to reverse the retirement, you will never retire any agent, because the burst occurs every time.
The research literature on habit replacement confirms the counterintuitive solution. Dr. Ann Graybiel's neuroscience research at MIT demonstrates that you cannot truly extinguish a habit — both the old and new behaviors remain encoded in the brain. But you can replace it. The old neural pathway remains, but a new pathway can be strengthened to become the dominant response to the same cue. This is why step four of clean retirement — naming the replacement for each dependency — is not just an administrative task. It is a neurological necessity. The replacement behavior gives the brain something to do with the cue that previously triggered the retired agent. Without a replacement, the cue continues to activate the old pathway, and the extinction burst becomes an extinction failure.
Graceful degradation: the phased approach
Not every retirement needs to happen overnight. Software engineering's concept of graceful degradation offers a more sustainable model for complex agent retirements.
Graceful degradation is a design principle that ensures a system continues functioning — with reduced capacity — when components are removed or fail. Rather than an abrupt transition from full operation to nothing, the system moves through stages: full functionality, degraded but functional, minimal operation, and finally complete retirement. Each stage is stable and tested before proceeding to the next.
For agent retirement, this translates to a phased approach:
Phase 1: Announce. Declare the retirement internally — to yourself, in your planning system, in whatever record you maintain. Set a specific retirement date. This is the equivalent of the API deprecation notice: the system still works, but everyone (including your future self) knows it is ending.
Phase 2: Reduce. Scale back the agent's scope or frequency. If it ran daily, run it three times a week. If it covered ten responsibilities, narrow it to the five that are hardest to replace. This phase serves two purposes: it begins the psychological adjustment, and it reveals which dependencies are genuinely load-bearing versus which ones are habits of convenience.
Phase 3: Transfer. Migrate each dependency to its replacement. One at a time, not all at once. Verify that each replacement actually works before moving to the next. This is the equivalent of the migration period in API deprecation — both the old and new systems run in parallel until confidence in the new system is established.
Phase 4: Retire. Remove the agent. The retirement date has arrived, the dependencies have been transferred, and the old agent stops operating. But the documentation remains — the record of what it did, why it was retired, and where its responsibilities went. In API terms, this is the moment the endpoint returns HTTP 410 Gone instead of its previous response: a clear signal that the resource existed, it no longer does, and this is intentional.
Phase 5: Monitor. Watch the downstream effects for a defined period after retirement. Are the replacement agents handling their inherited responsibilities? Are there dependencies you missed? Is there an extinction burst masquerading as a real problem? This monitoring window — two to four weeks is usually sufficient for personal agents — is the safety net that catches the dependencies your mapping missed.
The retirement document
The output of clean retirement is a document. It does not need to be formal. It does not need to be long. But it needs to exist, because the alternative is organizational memory loss — the personal equivalent of what knowledge management researchers describe as institutional knowledge that vanishes when the carrier departs.
The document has five sections:
Agent name and description. What it was, in plain language.
Service period. When it started and when it ended. How long it ran. This contextualizes its role in your history.
Reason for retirement. The specific circumstances that changed. Written in enough detail that you will understand the reasoning a year from now.
Dependency map. Everything that relied on this agent, and where each dependency now lives.
Post-retirement notes. Added after the monitoring period. What happened after the retirement? Did the replacements work? Were there surprises? What would you do differently?
This document is not busywork. It is the institutional memory of your personal system. When you look back in six months and wonder why you stopped doing something, the document answers. When you consider starting a new agent that overlaps with a retired one, the document warns. When you begin to romanticize a past routine, the document provides the context that nostalgia omits.
The cost of dirty retirement
The opposite of clean retirement is what happens by default: you stop doing something, the downstream dependencies fail silently, you experience vague degradation in some area of your life, and you cannot trace the degradation back to the retired agent because you never documented the connection.
This is the personal equivalent of what KPMG identified in a study of enterprise IT: organizations continuing to pay for retired applications because nobody documented the retirement and nobody verified that downstream systems had been migrated. The applications were turned off. The licenses were not canceled. The data feeds were not redirected. The cost continued. In personal systems, the cost is not financial — it is functional. The capability you thought you retired is actually still needed, and you are paying for its absence in reduced effectiveness across the system.
Clean retirement costs twenty minutes of documentation. Dirty retirement costs months of mysterious degradation.
Where this leads
You now have the process for retiring an agent without leaving damage in its wake: document what it did, record why it is leaving, map its dependencies, name the replacements, execute the retirement in phases, and monitor the aftermath. The retirement document ensures that the knowledge survives even when the agent does not.
But documentation is only half of succession. The next lesson — L-0590, Agent Succession — addresses the other half: how to ensure that the agents inheriting the retired agent's responsibilities are genuinely capable of carrying them. A dependency map that says "the weekly review will now handle nutritional planning" is only as good as the weekly review's actual capacity to absorb that function. Succession planning is the discipline of evaluating the inheritors, not just naming them. Your retirement document names the candidates. The next lesson teaches you to vet them.
Sources:
- Lerman, D. C., Iwata, B. A., & Wallace, M. D. (1999). "Side Effects of Extinction: Prevalence of Bursting and Aggression During the Treatment of Self-Injurious Behavior." Journal of Applied Behavior Analysis, 32(1), 1-8.
- Graybiel, A. M. (2008). "Habits, Rituals, and the Evaluative Brain." Annual Review of Neuroscience, 31, 359-387. MIT Department of Brain and Cognitive Sciences.
- U.S. Nuclear Regulatory Commission. (2024). "Backgrounder on Decommissioning Nuclear Power Plants." NRC Fact Sheets.
- Archon Data Store. (2026). "Application Decommissioning & Application Retirement: Guide for 2026."
- Atlassian. (2025). "How to Win at Dependency Mapping: A Step-by-Step Guide." Atlassian Team Playbook.
- Nordic APIs. (2023). "How to Smartly Sunset and Deprecate APIs." RFC 8594 — The Sunset HTTP Header Field.
- KPMG. (2016). "Why Are You Still Paying for Retired Applications?" KPMG Information Technology Services.
- Panopto. (2022). "How to Preserve Institutional Knowledge Amidst the Great Resignation."