Most guidance on AI agents is about getting them into production. Far less is written about the other end: the day you decide to replace an agent with a better one, move it to another vendor, or simply stop. Yet this is where companies tend to lose things, such as a duty nobody remembered, an account that stays active for years, or data that nobody is responsible for any more.
This article is for the manager who has decided, or is about to decide, that an agent should go. If you are not sure yet, start with the pilot decision guide or the regular operational review, which describe the triggers that lead here.
Why leaving is riskier than it looks
An agent that has run for a year has accumulated more than its documentation says.
- Hidden duties. It may have been catching duplicate requests, formatting a report a colleague relies on, or flagging unusual cases by habit. None of that was in the original brief.
- Lingering access. Credentials, API tokens and service accounts are easy to create and easy to forget. An unused agent identity with broad permissions is a standing risk.
- Data in many places. Conversation history, retrieved documents, memory stores, logs and vendor-side copies all hold information about customers and staff.
- People who adapted. Colleagues have changed how they work around the agent. A silent switch-off leaves them with a gap and no instructions.
Step 1: Decide and name the reason
Write one or two sentences on why the agent is leaving: quality fell, cost grew, the process changed, a better tool exists, the vendor changed terms. The reason shapes the plan. A replacement for a better model needs a careful transfer of behaviour. A retirement because the process no longer exists needs mostly cleanup.
Name the person accountable for the transition. This is usually the agent's owner from the operational review, with the deputy ready to step in.
Step 2: Inventory what the agent really does
Do not rely on the original specification. Build the list from evidence:
- Read the logs. Sample cases from different weeks and note every action the agent took, not only the main task.
- List its connections. Systems it reads from, systems it writes to, messages it sends, schedules it runs on.
- Ask the people around it. Reviewers and downstream colleagues often know the quiet duties. Our guide on human approval and audit trails shows how to see who relied on what.
- Check the contract. Notice periods, minimum terms and data return clauses sit in your vendor agreement. Find them before you announce a date.
The result is a short table: duty, who depends on it, and what will cover it afterwards.
Step 3: Plan the handover of the process
For each duty, decide who or what takes it over: the replacement agent, an existing system, or a person. If it goes to a person, say who, give them the instructions the agent used to follow, and make sure they have the time.
Keep the old way available. The staged rollout approach applies in reverse: do not remove the old agent until the new setup has proven itself.
Step 4: Run both in parallel
When replacing an agent, let the new one work in shadow mode on the same real cases while the old one stays in charge. Compare outcomes case by case and look closely at the differences, not at averages. Re-use the test set from reliability evaluation and add the odd cases found in Step 2.
Agree in advance what counts as a match, for example: no serious differences over a stated number of cases, and corrections at or below the old level. Then cut over in stages, starting with the lowest-risk cases. Define the rollback in writing: who decides, how quickly the old agent can resume and what happens to cases handled in between.
Step 5: Remove access completely
Retiring an agent means retiring its identity. Work through a checklist and tick each item only after verifying it:
- API keys and tokens revoked at the provider and in your secret store.
- Service accounts and roles disabled, then deleted after the retention window.
- Permissions in connected systems removed, including those granted informally.
- Scheduled jobs, webhooks and integrations switched off.
- Shared channels, mailboxes and tools where the agent was a member updated.
The principle is the one in the guide on identity and least privilege: every permission has an owner, and when the use ends, so does the permission. Test the result by trying to use the old credentials. The OWASP list of risks for LLM applications lists excessive agency among the problems; leftover access is the quiet version of it.
Step 6: Decide what happens to data
Before the switch-off, decide for each data store whether it is kept, moved, anonymised or deleted, and who approves it.
- Logs and audit trails. Keep what your retention rules, audit needs or an open incident require, and no more.
- Memory and retrieval stores. These often contain personal data. Delete them, or move what has lasting business value into a governed system.
- Vendor-side copies. Request deletion or return in writing and keep the confirmation. If personal data is involved, data protection rules such as the right to erasure in Article 17 of the GDPR and the regulator's guidance on AI and data protection are relevant. Ask your data protection contact if you are unsure.
- Knowledge worth keeping. Prompts, test cases and lessons learned are valuable for the next agent. Archive them with a short note on what worked and what did not.
Step 7: Tell people and close the loop
Tell the staff, customers and partners who interacted with the agent what is changing and when, and where to go instead. Update documentation, the agent register and any process descriptions. After the cutover, hold a short check at two and at six weeks: are the quiet duties covered, did complaints rise, did any old credential show activity?
Close with a two-line record: date, reason, what replaced the agent, who confirmed access and data were dealt with. This is the entry that will help the next team that faces the same choice.
A one-page summary
- Name a reason, an owner and a date.
- Build the duty list from logs and conversations, not from the old brief.
- Run old and new side by side with agreed success criteria and a written rollback.
- Revoke and verify every credential and permission.
- Decide per data store: keep, move, anonymise or delete.
- Tell the people affected and review after two and six weeks.
A good retirement is uneventful. Nobody notices the change except the people who planned it.
