How to retire an AI agent

Retiring an agent is a controlled sequence, not a switch. The process owner sets a date; depth is frozen, then lowered to drafting; held and in-flight work goes to people or a successor; every credential is revoked; its brief, sources and bounds are archived; and its verdict records are kept. The retirement record proves each step.

When should an agent be retired?

Agents are retired for ordinary reasons. The process they served has changed or ended. A successor does the job better. The agent's certification was not renewed and no one thinks it is worth the effort. The work has moved to another team or system. Sometimes an agent is retired after a failure that showed the job was never suitable for it.

Whatever the reason, an agent that is no longer needed but still has access is a risk. Its service accounts can be misused, its brief drifts out of date, and staff may still send it work. Retirement should be as deliberate as deployment, and reverses the same steps described in train, shadow, certify, widen.

The process owner, who answers for the agent's work, makes the decision. The agent operations team runs the sequence. IT and system owners revoke access. Records management confirms retention.

What is the method?

1. Process owner: decides to retire and sets a date. The decision records the reason and who will do the work afterwards: people, a successor agent or no one, if the work has ended.
2. Agent operations: freezes depth. No widening, no new capabilities, no new users from the decision onwards.
3. Process owner: tells the people affected: staff who work with the agent, approvers of its held work, and any team that sends it work.
4. Agent operations: lowers every capability to depth 2 a set period before the date. The agent drafts; people act. This tests that the receiving team can carry the work.
5. Agent, depth 1: lists all work in flight: held items, drafts awaiting review, cases it has started, scheduled jobs.
6. Process owner: reassigns each item to a named person or the successor.
7. IT and system owners: revoke every credential on the date: service accounts, tokens, delegated mailbox and calendar access, channel memberships, scheduled triggers. Each revocation is confirmed by the system that holds it.
8. Agent operations: archives the final brief, sources list, bounds, certification files and register entry.
9. Records management: confirms retention of the verdict records and audit trail for the period your rules require.
10. Agent operations: closes the register entry with the retirement record attached.

Why lower to drafting before switching off?

Because the receiving team needs to prove it can do the work before the agent is gone. If the agent handled a capability at depth 3 for a year, the people who used to do that work may have moved on or lost practice. Running at depth 2 for a short period puts the work back in people's hands while the agent's drafts are still there as support. If the team struggles, you find out while you can still delay.

How do you make sure every credential is revoked?

Agents accumulate access. A service account in the core system, a token for the e-signature platform, membership of three team channels, delegated access to a shared mailbox, a scheduled job on a server. The register should list all of these, but in practice some were added later and not recorded.

Two checks help. First, ask each system owner to list every account and token associated with the agent, not just the ones on the register. Second, after revocation, watch the agent's verdict records and the target systems' access logs for a period: any attempted action means something was missed.

Revocation requests usually flow through the IT service desk. If you have an agent resolving IT tickets in your ITSM platform, it can raise and track those tickets, but the revocations themselves are performed and confirmed by people with the right authority. If the retiring agent is itself the one resolving tickets, reassign its open tickets first.

What must be kept?

Retiring an agent does not retire its record. Every verdict it reached, every action it took and every held item it raised may be needed later: to answer a complaint, to support an audit, or to respond to a regulator. Keep the verdict records and audit trail for as long as the underlying records they relate to must be kept.

Keep the brief, sources and bounds too, with their versions. A complaint about a decision the agent made a year ago can only be answered by knowing what the agent was told to do at the time. Take, for example, an operations leader in consumer lending in the United Arab Emirates retiring an agent that drafted arrears letters: supervisors and customers may ask about those letters long after the agent is gone, and the archived brief is what explains them.

What does the retirement record contain?

• The decision: reason, date, owner.
• Notifications sent and to whom.
• The in-flight work list and the new owner of each item.
• Each revocation, with the system owner's confirmation.
• The archive location of the brief, sources, bounds and certification files.
• The retention period for the verdict records, confirmed by records management.
• The post-retirement check: no attempted actions after the date.

Where does it usually go wrong?

The agent is just switched off. Held items are lost, scheduled jobs fail quietly, and nobody knows what happened to the work.

Access is left behind. A token in one system survives for months. Revocation needs a confirmation per system.

Records are deleted with the agent. Teams think of the logs as the agent's data. They are the firm's records.

The successor inherits nothing. A replacement agent starts from scratch when the retired one's brief and certification cases would have saved weeks. Pass them on.