{"course":{"slug":"agents-and-automation","title":"Agents and Automation","url":"https://addaly.com/learn/agents-and-automation","level":"intermediate","track":"build"},"lesson":{"slug":"retiring-an-automation","title":"Switching it off, on purpose","url":"https://addaly.com/learn/agents-and-automation/retiring-an-automation","position":72,"of":72,"minutes":9,"answer":"Revoke the credentials before you delete the code, because once the code is gone nobody remembers the key existed and it stays valid for years.","keyIdea":"Revoke the credentials before you delete the code, because once the code is gone nobody remembers the key existed and it stays valid for years."},"body":{"format":"markdown","text":"## Nothing is built to be switched off\n\nEvery automation is designed, deployed and defended. Almost none is designed to end, so they accumulate: jobs running against processes that no longer exist, reports emailed to distribution lists where half the addresses bounce, a scraper watching a site that was redesigned in 2024 and has quietly returned nothing since.\n\nRetirement is a normal part of the lifecycle and it needs a procedure, or it does not happen.\n\n## Review on a schedule, with five questions\n\nQuarterly, for every entry on the register, ask:\n\n1. **Is it still running?** You will be surprised more than once.\n2. **Does anybody read the output?** Check, do not assume. Open the report and look at who opened it. A weekly digest with no readers for four months is an answer.\n3. **What did it cost this quarter?** Including the maintenance hours, not just the bill.\n4. **What is its error rate, and who is checking?**\n5. **Would we build this today?**\n\nThe fifth is the strongest question in the whole review, because it strips out sunk cost. The answer is frequently no: the process changed, a vendor shipped the feature natively, volume collapsed, the team it served was reorganised. A no is a decision to make, not an embarrassment to avoid.\n\n> Figure: Decommissioning, in the order that matters. Steps: 1. Announce it, with a date (To whoever reads the output, whoever depends on the rows it writes, and the on-call rota.); 2. Turn it off, leave it deployed (Two weeks. People notice an absence late, and usually through a second-order effect.); 3. Revoke the credentials (Before the code goes. Once the repository is deleted nobody remembers the key existed, and it stays valid for years.); 4. Remove the triggers (The cron entry, the scheduled task, the webhook registered at the vendor's end, the queue subscription.); 5. Archive to the retention policy (Decision records for their stated period; payloads deleted on schedule, not on sentiment.); 6. Write down what replaced it (Or that nothing did and the work went back to being manual. In two years somebody will ask.); 7. Remove it from the register (With the date and the reason, so the list stays something you can trust.). The failure state this prevents is a job with no owner, an active credential and a live schedule, still writing into production where nobody reads the output.\n\n## The decommission checklist, in this order\n\n**Announce it**, with a date, to everyone downstream, including whoever receives the output, whoever depends on the rows it writes, and the on-call rota.\n\n**Turn it off, but leave it deployed for two weeks.** People notice the absence of something late, and often through a second-order effect: a report that no longer arrives, a field that stopped being filled in. Two weeks of \"off but restorable\" converts a possible incident into a one-line rollback.\n\n**Revoke the credentials before you delete the code.** This is the ordering that matters. Once the repository is gone, nobody remembers which service account existed, which API key was issued or which webhook is still registered, and an unused key remains valid indefinitely, attached to nothing, waiting to appear in a breach report years later. Revoke first, then remove the schedule, then delete the code.\n\n**Remove the trigger properly.** The cron entry, the scheduled task, the webhook registration at the vendor's end, the queue subscription. A dead consumer leaves a queue growing until it fills a disk somebody else owns.\n\n**Export and archive the data**, according to the retention policy rather than to sentiment. Keep the decision records for their stated period, delete the payloads on schedule, and note where the archive lives.\n\n**Write down what replaced it**, or that nothing did and the work went back to being manual. In two years somebody will ask why this is done by hand, and the answer should be findable.\n\n**Remove it from the register**, with the date and the reason.\n\n## The zombie you are preventing\n\nThe failure state is a job with no owner, an active credential and a live schedule. It writes into production. Nobody reads its output. Nobody would notice if it started writing nonsense, and eventually it will, because the world it was built for has moved on.\n\nEvery element of the checklist above exists to prevent that specific outcome, and the ordering (credentials first) is the part most often got wrong.\n\n## Ending well is a good outcome\n\nAn automation retired because the process changed is a success. An automation retired because it never delivered what was claimed is also, in its way, a success, for the team that measured honestly and said so rather than defending it for another year.\n\nThat is the disposition this whole course has been arguing for. The valuable skill is not building agents. It is looking at a piece of work and choosing the smallest machine that does it, pricing that machine honestly, watching what it actually does in the world, and being willing to turn it off. Everything technical here (the loop, the schemas, the validators, the budgets, the traces) exists to make that judgement possible on evidence rather than on enthusiasm.\n\nThe last thing to build is the habit of asking, once a quarter, whether the thing you built should still exist."},"check":{"question":"A team decommissions an automation by deleting the repository, removing the cron entry and archiving the data. Six months later a leaked key from that system appears in a breach report. What did the order of operations cost them?","options":[{"text":"The archived data should have been deleted rather than kept, which is what exposed it.","correct":false,"tempting":"Retention discipline matters, but the archive is not what leaked here: a credential was still valid and attached to nothing."},{"text":"Removing the cron entry before the code meant the final run never completed cleanly, leaving state behind.","correct":false,"tempting":"An untidy shutdown can leave partial state, but that would surface as data problems, not as a live credential months later."},{"text":"They should have rotated the key on a schedule while the system was live, which would have limited the window.","correct":false,"tempting":"Rotation shortens exposure generally, but a key attached to a retired system needs revoking outright rather than replacing."},{"text":"Once the code was gone, no record remained of which credentials existed, so nothing was revoked and the key stayed valid indefinitely.","correct":true}]},"prev":{"slug":"what-it-keeps-and-what-it-must-forget","title":"Retention: the duty to keep and the duty to delete","url":"https://addaly.com/learn/agents-and-automation/what-it-keeps-and-what-it-must-forget"},"next":null,"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Switching it off, on purpose', in Agents and Automation. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/agents-and-automation/retiring-an-automation (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Switching it off, on purpose","courseTitle":"Agents and Automation","module":{"index":8,"slug":"living-with-it","title":"The year after it ships"},"answer":null,"keyIdea":"Revoke the credentials before you delete the code, because once the code is gone nobody remembers the key existed and it stays valid for years.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"flow","steps":[{"label":"Announce it, with a date","detail":"To whoever reads the output, whoever depends on the rows it writes, and the on-call rota."},{"label":"Turn it off, leave it deployed","detail":"Two weeks. People notice an absence late, and usually through a second-order effect."},{"label":"Revoke the credentials","detail":"Before the code goes. Once the repository is deleted nobody remembers the key existed, and it stays valid for years."},{"label":"Remove the triggers","detail":"The cron entry, the scheduled task, the webhook registered at the vendor’s end, the queue subscription."},{"label":"Archive to the retention policy","detail":"Decision records for their stated period; payloads deleted on schedule, not on sentiment."},{"label":"Write down what replaced it","detail":"Or that nothing did and the work went back to being manual. In two years somebody will ask."},{"label":"Remove it from the register","detail":"With the date and the reason, so the list stays something you can trust."}],"title":"Decommissioning, in the order that matters","caption":"The failure state this prevents is a job with no owner, an active credential and a live schedule, still writing into production where nobody reads the output."},"alt":"Figure: Decommissioning, in the order that matters. Steps: 1. Announce it, with a date (To whoever reads the output, whoever depends on the rows it writes, and the on-call rota.); 2. Turn it off, leave it deployed (Two weeks. People notice an absence late, and usually through a second-order effect.); 3. Revoke the credentials (Before the code goes. Once the repository is deleted nobody remembers the key existed, and it stays valid for years.); 4. Remove the triggers (The cron entry, the scheduled task, the webhook registered at the vendor’s end, the queue subscription.); 5. Archive to the retention policy (Decision records for their stated period; payloads deleted on schedule, not on sentiment.); 6. Write down what replaced it (Or that nothing did and the work went back to being manual. In two years somebody will ask.); 7. Remove it from the register (With the date and the reason, so the list stays something you can trust.). The failure state this prevents is a job with no owner, an active credential and a live schedule, still writing into production where nobody reads the output."}},"blocks":[{"t":"h2","id":"nothing-is-built-to-be-switched-off","runs":[{"text":"Nothing is built to be switched off"}]},{"t":"p","runs":[{"text":"Every automation is designed, deployed and defended. Almost none is designed to end, so they accumulate: jobs running against processes that no longer exist, reports emailed to distribution lists where half the addresses bounce, a scraper watching a site that was redesigned in 2024 and has quietly returned nothing since."}]},{"t":"p","runs":[{"text":"Retirement is a normal part of the lifecycle and it needs a procedure, or it does not happen."}]},{"t":"h2","id":"review-on-a-schedule-with-five-questions","runs":[{"text":"Review on a schedule, with five questions"}]},{"t":"p","runs":[{"text":"Quarterly, for every entry on the register, ask:"}]},{"t":"ol","start":1,"items":[[{"text":"Is it still running?","b":true},{"text":" You will be surprised more than once."}],[{"text":"Does anybody read the output?","b":true},{"text":" Check, do not assume. Open the report and look at who opened it. A weekly digest with no readers for four months is an answer."}],[{"text":"What did it cost this quarter?","b":true},{"text":" Including the maintenance hours, not just the bill."}],[{"text":"What is its error rate, and who is checking?","b":true}],[{"text":"Would we build this today?","b":true}]]},{"t":"p","runs":[{"text":"The fifth is the strongest question in the whole review, because it strips out sunk cost. The answer is frequently no: the process changed, a vendor shipped the feature natively, volume collapsed, the team it served was reorganised. A no is a decision to make, not an embarrassment to avoid."}]},{"t":"h2","id":"the-decommission-checklist-in-this-order","runs":[{"text":"The decommission checklist, in this order"}]},{"t":"p","runs":[{"text":"Announce it","b":true},{"text":", with a date, to everyone downstream, including whoever receives the output, whoever depends on the rows it writes, and the on-call rota."}]},{"t":"p","runs":[{"text":"Turn it off, but leave it deployed for two weeks.","b":true},{"text":" People notice the absence of something late, and often through a second-order effect: a report that no longer arrives, a field that stopped being filled in. Two weeks of “off but restorable” converts a possible incident into a one-line rollback."}]},{"t":"p","runs":[{"text":"Revoke the credentials before you delete the code.","b":true},{"text":" This is the ordering that matters. Once the repository is gone, nobody remembers which service account existed, which API key was issued or which webhook is still registered, and an unused key remains valid indefinitely, attached to nothing, waiting to appear in a breach report years later. Revoke first, then remove the schedule, then delete the code."}]},{"t":"p","runs":[{"text":"Remove the trigger properly.","b":true},{"text":" The cron entry, the scheduled task, the webhook registration at the vendor’s end, the queue subscription. A dead consumer leaves a queue growing until it fills a disk somebody else owns."}]},{"t":"p","runs":[{"text":"Export and archive the data","b":true},{"text":", according to the retention policy rather than to sentiment. Keep the decision records for their stated period, delete the payloads on schedule, and note where the archive lives."}]},{"t":"p","runs":[{"text":"Write down what replaced it","b":true},{"text":", or that nothing did and the work went back to being manual. In two years somebody will ask why this is done by hand, and the answer should be findable."}]},{"t":"p","runs":[{"text":"Remove it from the register","b":true},{"text":", with the date and the reason."}]},{"t":"h2","id":"the-zombie-you-are-preventing","runs":[{"text":"The zombie you are preventing"}]},{"t":"p","runs":[{"text":"The failure state is a job with no owner, an active credential and a live schedule. It writes into production. Nobody reads its output. Nobody would notice if it started writing nonsense, and eventually it will, because the world it was built for has moved on."}]},{"t":"p","runs":[{"text":"Every element of the checklist above exists to prevent that specific outcome, and the ordering (credentials first) is the part most often got wrong."}]},{"t":"h2","id":"ending-well-is-a-good-outcome","runs":[{"text":"Ending well is a good outcome"}]},{"t":"p","runs":[{"text":"An automation retired because the process changed is a success. An automation retired because it never delivered what was claimed is also, in its way, a success, for the team that measured honestly and said so rather than defending it for another year."}]},{"t":"p","runs":[{"text":"That is the disposition this whole course has been arguing for. The valuable skill is not building agents. It is looking at a piece of work and choosing the smallest machine that does it, pricing that machine honestly, watching what it actually does in the world, and being willing to turn it off. Everything technical here (the loop, the schemas, the validators, the budgets, the traces) exists to make that judgement possible on evidence rather than on enthusiasm."}]},{"t":"p","runs":[{"text":"The last thing to build is the habit of asking, once a quarter, whether the thing you built should still exist."}]}],"check":{"question":[{"text":"A team decommissions an automation by deleting the repository, removing the cron entry and archiving the data. Six months later a leaked key from that system appears in a breach report. What did the order of operations cost them?"}],"options":[{"text":[{"text":"The archived data should have been deleted rather than kept, which is what exposed it."}],"correct":false,"tempting":[{"text":"Retention discipline matters, but the archive is not what leaked here: a credential was still valid and attached to nothing."}]},{"text":[{"text":"Removing the cron entry before the code meant the final run never completed cleanly, leaving state behind."}],"correct":false,"tempting":[{"text":"An untidy shutdown can leave partial state, but that would surface as data problems, not as a live credential months later."}]},{"text":[{"text":"They should have rotated the key on a schedule while the system was live, which would have limited the window."}],"correct":false,"tempting":[{"text":"Rotation shortens exposure generally, but a key attached to a retired system needs revoking outright rather than replacing."}]},{"text":[{"text":"Once the code was gone, no record remained of which credentials existed, so nothing was revoked and the key stayed valid indefinitely."}],"correct":true,"tempting":null}],"order":[2,0,3,1],"why":null},"prev":{"slug":"what-it-keeps-and-what-it-must-forget","title":"Retention: the duty to keep and the duty to delete","minutes":9},"next":null}}