Nobody Writes About Retiring an Agent. Here's the Checklist.

We have onboarding docs for agents. We have runbooks, evaluation suites, even certification gates. Nothing covers the end.

An agent that stops being useful does not die cleanly. It leaves credentials with scopes nobody remembers, state nobody exported, and a team that kept trusting its outputs out of habit. The graveyard is invisible, and it is growing.

Every agent you deploy has an end-of-life date you have not scheduled. Here is the checklist for that day, the hard half and the soft half, so the retirement is a decision instead of a slow fade into a security finding.

Why Agents Are Harder to Retire Than Services

A service that gets decommissioned takes its behavior with it. Requests fail loudly, an alert fires, someone notices.

An agent is different in two ways that make retirement uniquely dangerous.

First, agents hold credentials in more places than services do. Config files, keychains, harness settings, integration tokens, webhooks. Each one is a live capability that outlives the agent's usefulness.

Second, and this is the part nobody plans for: agents train humans. Your team built habits around the outputs. The agent's summaries get skimmed, its recommendations get weight, its silences get interpreted. When you retire the agent, the habits stay, and they now point at nothing. That is a people problem wearing an ops costume, and it is the reason retired agents linger for years instead of months.

The Hard Checklist

Five items. Do them in order, and none of them is optional.

1. Revoke every credential. All of them, including the ones baked into config files and the ones you forgot were created. Tokens, integration grants, webhook subscriptions, SSH keys, service accounts. Rotate rather than just revoke where the credential was shared. If the checklist item cannot be checked off with a name and a date, you are not done.

2. Export and archive the state. Conversation logs, decision records, memory files, whatever the agent accumulated. The archive is not sentimentality. It is the evidence base for the day someone asks "why did the agent do X back in March," and that question arrives months after you stopped expecting it.

3. Handle the data. Where did the agent's outputs land, and who still has them? Reports it wrote, rows it touched, tickets it filed. Some of it needs retention, some of it needs correction, and all of it needs one owner who says what happens to it.

4. Drain the queues. In-flight work, scheduled runs, pending approvals. A retired agent with a scheduled run is not retired. Check the cron, the scheduler, the harness's task list, and the approval inbox, because the agent you forgot about is the one that fires at 3 AM.

5. Notify the dependents. Every system and every person that consumed the agent's outputs. Dashboards that will show stale data, pipelines that will hang waiting on a response, humans who will keep asking it things. Silence is not a notification.

The Soft Checklist

The half nobody writes down, which is why retired agents haunt teams longer than they should.

Audit the habituated trust. Where did people rely on the agent's judgment? Those workflows now run on human habits tuned to a system that no longer exists. Name the top three, and decide what replaces them, because "people will figure it out" is how you get two quarters of quiet errors.

Write the replacement behavior down. What does the team do now, specifically, in the situations where they used to check the agent? One paragraph in the runbook. Without it, the vacancy gets filled by whoever is most confident in the room, which is not a governance model.

Schedule the after-check. Thirty days after retirement, one person spends an hour looking for signs of life: stale credentials that survived revocation, calls to the dead agent, dashboards still rendering its last outputs. The after-check is what catches the checklist's misses, and every checklist has misses.

tip: If the honest answer to "who owns this agent" is "nobody," that agent is already retired and nobody told it. Retirement checklists are cheaper than the undead version.

The Decommission Drill

You do not want your first agent retirement to happen during an incident.

Retire a low-stakes agent on purpose. Pick one that is barely used, or one you built as a demo, and run the full checklist, both halves. Time it. Find out which items take longer than expected, because revocation and dependency discovery always do. Write down what the checklist missed.

The drill converts the checklist from a document into a capability, and the difference matters the first time a real retirement has urgency behind it. Decommissioning under pressure, without a drill, is how a credential survives that should not have, and that surviving credential is the incident you will be explaining later.

The Honest Limitation

This checklist comes from practice, not from a case study of a flawless retirement. The drill exists precisely because nobody gets all five hard items on the first pass, and the soft half is closer to art than process. Scale it to stakes: a demo agent needs items 1 and 4, an agent with production credentials and human habits needs everything, twice.

But the direction is not in doubt. Every team is deploying more agents than it is retiring, which means the graveyard is compounding, and the graveyard is full of tokens.

So here is the question: how many agents does your team run today, and for how many of them could you name, right now, every credential they hold?

If the second number is smaller than the first, you have found next quarter's quiet security project, and this checklist is the plan for it.