Decommissioning an AI agent safely means switching off everything that lets it act, while keeping everything you may need to explain what it did. Revoke its credentials and triggers, stop scheduled work, decide what happens to its memory and data, keep its logs and records, and tell the people and systems that depended on it.
Why retiring an agent needs a plan
Most teams plan carefully how an agent goes live and very little about how it stops. Yet agents get retired all the time: a pilot ends, a process changes, a vendor is replaced or a newer agent takes over the work. If nobody owns the shutdown, the agent rarely disappears cleanly. Its API keys stay valid, a scheduled job keeps firing, a webhook still points at it, and a copy of customer data sits in a vector store nobody remembers.
The NIST AI Risk Management Framework treats this as a governance task in its own right. Its GOVERN 1.7 subcategory asks for processes to decommission and phase out AI systems safely, in a way that does not increase risk or reduce trust. An agent that is only half switched off does both: it can still act, and nobody is watching it.
What to switch off
The goal of this half of the work is simple: after shutdown, the agent should have no way to read, write or trigger anything.
Credentials and access
Revoke every credential the agent holds rather than just deleting its configuration. That includes API keys, OAuth grants it obtained on behalf of users, service accounts, database roles and tokens for MCP servers or other tools. If you keep an inventory of every AI agent, it should list these; if you do not, the shutdown is a good moment to find them through your identity provider and secret store. Check that each revocation actually worked by testing a call with the old credential.
Triggers and schedules
Agents often start from something outside themselves: a cron job, a queue, an inbound email address, a chat command or a webhook from another system. Remove each of these, or point them somewhere that fails loudly. A trigger left pointing at a dead endpoint can hide lost work, so callers should get a clear error rather than silence.
Work in flight
Decide what happens to tasks the agent has already started. Let short tasks finish, cancel or hand over long ones, and record which was which. Anything the agent was waiting on a person to approve needs a new owner, or the request should be closed with a note so nobody approves an action for an agent that no longer exists.
What to keep
The other half of the work is deciding what must outlive the agent, because you may still need to answer questions about its decisions after it is gone.
The audit trail
Keep the agent's action logs, tool calls, approvals and the audit trail for as long as your retention policy and any legal or regulatory duties require. Complaints, disputes and investigations can arrive well after an agent stops. Make sure the logs stay readable without the agent itself, for example by exporting them to your central logging or records system.
The version that ran
Record exactly what was running at shutdown: the model and version, prompts, tool definitions, guardrail settings and evaluation results. If you already version an agent for rollback, archive the final release. This lets someone reconstruct why the agent behaved as it did, and gives a replacement agent a baseline to compare against.
Ownership and contacts
Name a person who remains accountable for the retired agent's records and can answer questions about it. Update the inventory entry to "retired" rather than deleting it, with the date, the reason and where the archived material lives.
What to delete or hand over
Memory and data sit between the two lists. The agent's long-term memory, vector stores, caches and working files often hold personal or confidential data, and keeping them without a purpose creates risk. Delete what you no longer need, in line with your retention rules and any right to erasure requests, and confirm that copies held by model or tool providers are covered too. Where a replacement agent takes over, move only the data it needs, and check it rather than copying the old store wholesale.
Tell people before you switch it off
Users, support teams and owners of connected systems should hear about the change before it happens, not discover it when something stops working. Say when the agent will stop, what replaces it, and who to contact. For a customer-facing agent, update help pages, chat entry points and any disclosure text so people are not routed to something that no longer answers.
A shutdown checklist
Turn the steps above into a short checklist that every agent follows, and test it on a low-risk agent first:
- Owner and reason for retirement recorded
- Users and dependent systems told, with a date
- Triggers, schedules and webhooks removed or failing clearly
- In-flight work finished, cancelled or handed over
- All credentials revoked and the revocation tested
- Memory and data deleted or moved, with provider copies covered
- Logs, audit trail and final version archived and readable
- Inventory entry marked retired, with where the records live
If you are planning the lifecycle of agents across your organisation, including how they are retired, talk to CodeDTX about building it into your operating model from the start.
Frequently asked questions
Is switching off the agent's server enough to decommission it?
No. Stopping the process stops the agent's own code, but its credentials, OAuth grants and scheduled triggers can stay valid elsewhere. Another system could still call its endpoint, or someone could restart it with the old keys. A proper decommission revokes access, removes triggers, settles its data and archives its records, so nothing can act in its name and you can still explain what it did.
How long should we keep an AI agent's logs after it is retired?
Keep them for as long as your records retention policy and any legal, regulatory or contractual duties require, which depends on your sector and what the agent did. Logs of actions that affected customers, money or personal data usually need the longest retention. Store them outside the agent, in your central logging or records system, so they stay readable and searchable after the agent and its infrastructure are gone.
What should happen to an agent's memory and vector store?
Treat them like any other data store that may contain personal or confidential information. Delete what has no further purpose, following your retention rules and any erasure requests, and confirm that copies held by model or tool providers are removed too. If a replacement agent needs some of that knowledge, move only the relevant parts after checking them, rather than copying the whole store across unchanged.
Who should own an AI agent's decommissioning?
The agent's business owner should decide when it retires, and the team that operates it should carry out the shutdown. Security should confirm that credentials are revoked, and whoever manages records or compliance should sign off on what is kept or deleted. One named person should stay accountable for the archived records afterwards, so questions about the agent's past decisions always have someone to answer them.
