Executive Leadership
Retiring an AI Agent: The Offboarding Discipline Nobody Puts in the Plan
When an employee leaves, someone collects the laptop and turns off the badge by five o’clock. When an agent leaves, it usually keeps its keys.
Every AI governance framework I have read is about beginnings. Who approves a new agent, what it may touch, how much it can spend, who reviews its first hundred outputs. All good questions.
Almost none of them say what happens at the end.
That gap matters more each quarter, because agents get retired constantly. A team reorganizes and the agent that drafted its weekly report has no reader. Two agents get merged into one. A vendor sunsets a product and the integration built around it goes quiet. In my own fleet I have retired more agents this year than I launched, and I learned the hard way that “we stopped using it” and “it stopped running” are two different facts that can sit months apart.
The agent that wouldn’t leave
Here is the version I lived through. An agent I had replaced in the spring was still waking up on its old schedule in late summer, pulling data with credentials nobody had revoked, and writing a status file that one other system still read every morning. Nothing dramatic broke. It just quietly fed stale numbers into a dashboard I trusted, and it held an API token with far more access than its replacement needed, sitting in a config file under the name of a project that no longer existed.
I found it because the machine ran out of process headroom and I went looking for what was eating it.
That is a lucky way to discover a security exposure. Most companies will not get the warning.
Why agents are harder to offboard than people
A person has one identity, one laptop, one manager, and an HR system that fires a checklist the day they resign. An agent has none of that by default. Its access is spread across whatever tokens it was handed during setup, often by an engineer who has since moved teams. Its schedule lives in a cron file or a workflow tool. And its output may be consumed by people and systems its builder never knew about, because useful work gets copied, forwarded, and wired into other things without anyone filing a ticket.
So someone has to design the offboarding. Attrition never finishes the job.
What I require before an agent is called retired
I keep this short, and the order matters.
- Find its consumers first. Before anything is turned off, list every person and system that reads what the agent produces. Check the logs for who opened its files in the last ninety days. Ask in the channel where its output lands. This step is slow and it is the one that prevents a Monday morning surprise in some other department.
- Revoke every credential, then confirm the revocation. Rotating a shared key the agent used counts. Deleting the config file does not, since the key is still valid wherever else it was pasted.
- Remove the schedule at the source, and watch for one full cycle to make sure nothing wakes up.
- Decide what happens to its memory. Agents accumulate notes, embeddings, and conversation logs that may contain customer data. Keep them under your normal retention policy or delete them on purpose. Leaving them in a bucket labeled “old” is neither.
The fourth item is where legal will eventually ask questions, so it is worth having an answer before they do.
The register
Underneath all of this sits one boring artifact: a fleet register. Each agent gets a row with its owner, what it can access, where it runs, and a status field that can only say active, paused, or retired with a date. The delegation of authority matrix tells you what an agent is allowed to do. The register tells you whether it still exists.
I check mine against what is actually running about once a month. There is almost always a discrepancy, and almost always in the same direction. The register says fewer agents than the machines do.
An agent with no owner on the register is retired on the spot.
Retire on a trigger, not a feeling
The other half of the discipline is deciding when. Agents rarely fail loudly enough to get shut down; they fade, their outputs read by fewer people each month, until they are running purely out of inertia and burning compute and holding live keys for work nobody would miss. I set the trigger in advance: if no human has acted on the agent’s output in thirty days, or its owner has changed roles, a retirement review starts automatically. A newer agent covering the same job counts too, though that case usually gets caught on its own. The review takes fifteen minutes. Most of the time the answer is obvious once someone is forced to ask.
What the board should see
Directors do not need the register itself. They need to know it exists and that it reconciles. One line in the quarterly technology report will do: the count of active agents, and whether the last reconciliation found anything running that the register did not list. If that last number is ever above zero, the follow-up is what it could access.
This sits naturally with the vendor and concentration questions in what boards should ask about AI, and it is an easy question for a technology board advisor to bring up before an auditor does.
The CEO’s part is small. Say out loud that an agent is retired only when its keys are dead and its consumers have been told, then ask, once, at the next staff meeting, who owns the register. If the room goes quiet, you have found this quarter’s work.
This article is part of the Executive Leadership cluster, focused on board governance and the operating discipline required to run AI systems responsibly at the executive level.