---

name: agent-severance description: "Offboard an AI agent the way you'd offboard an employee — inventory what it knew and touched, export then purge its memory, revoke every credential and access grant, and write the handover for its successor (human or agent). Use when decommissioning an agent or bot, switching agent vendors, ending an AI pilot, or when someone asks 'what did this thing have access to?'. Produces a severance checklist, an access-revocation table, a memory disposition record, and a successor handover."

Agent Severance Skill

Orgs learned employee offboarding the hard way: the contractor whose VPN worked for a year after the contract, the shared password nobody rotated. Long-lived agents recreate every one of those failure modes with worse logging — an agent accumulates credentials, memory, integrations, scheduled jobs, and undocumented responsibilities, and then one day it's "turned off" by deleting a chat window while its API keys live on. This skill runs the severance properly: know what it had, keep what's valuable, kill what's live, and hand over what it did.

What This Skill Produces

• An inventory: everything the agent could touch (credentials, tools, data stores, channels), everything it knew (memory, context files, fine-tuning or instructions), and everything it did on a schedule
• An access-revocation table with owner and verification step per row — revoked isn't revoked until someone confirmed the key is dead
• A memory disposition record: exported / retained (where, why, how long) / purged (how verified) — the part compliance will ask about in 2027
• A successor handover: the agent's actual duties, including the undocumented ones users discovered, for whoever inherits them

Required Inputs

Ask for (if not already provided):

• The agent: platform, what it was for, how long it ran, who owned it
• Known integrations and credentials (then treat the list as incomplete on principle — the inventory step hunts for the rest)
• Why it's being offboarded (vendor switch, pilot ended, incident, cost) — incident-driven severance changes the order: revoke first, inventory second
• What must survive: memory worth exporting, workflows someone still needs

Process

1. Inventory before touching anything (unless incident — then revoke first). Hunt beyond the known list: API keys and OAuth grants · service accounts · webhook URLs pointing at it · scheduled/cron jobs it ran · channels it posted in · data stores it read or wrote · other agents that called it (the A2A dependencies nobody documented) · what its memory contains, including personal data.
2. Decide memory disposition per store, not wholesale. Export what has value (decisions log, learned context) to an owned location; name a retention owner and period for anything kept; purge the rest and record how purged (vendor deletion request ≠ deleted — note what the vendor actually promises). Personal data follows your privacy policy's deletion rules, flagged explicitly.
3. Revoke with verification. Every row gets: the credential, who revokes it, and the test that proves it's dead (the call that now fails). Rotate any shared secrets the agent ever held — its copy dying doesn't kill the copies.
4. Write the honest handover. What it was supposed to do, what it actually did (ask its users — there are always undocumented duties), open threads mid-flight, and the workflows that will silently break next Tuesday when it stops.
5. Announce the death. One message to the channels it served: it's gone, here's who/what replaces it, here's where its exported memory lives.

Output Format

## Severance summary
[Agent, tenure, reason, severance owner, target date]

## Inventory
Access: [table — system, grant, discovered-how] · Knowledge: [stores + contents]
Duties: [scheduled + reactive + undocumented] · Dependents: [who/what calls it]

## Memory disposition
| Store | Export → where | Retain (owner, period) | Purge (method, verified how) |

## Revocation
| Credential/grant | Revoked by | Dead-key test | Status |

## Handover to successor
[Duties with enough detail to actually run them · open threads · will-break list]

## Announcement
[The message to its channels]

Quality Checks

• [ ] The inventory includes at least one category the user didn't mention — scheduled jobs and agent-to-agent callers are the usual blind spots
• [ ] Every revocation row has a verification test, not just an action
• [ ] Shared secrets the agent held are rotated, not just revoked
• [ ] Memory disposition distinguishes vendor-promised deletion from verified deletion, and flags personal data
• [ ] The handover names what breaks when the agent stops — if the answer is "nothing", the duties inventory probably isn't done

Anti-Patterns

• [ ] Do not equate "deleted the chat/app" with offboarded — the checklist exists because credentials outlive interfaces
• [ ] Do not purge memory before the export decision — severance is irreversible in exactly one direction
• [ ] Do not skip the users interview; the undocumented duties are the ones that page someone at 2am after shutdown
• [ ] Do not write this as a vendor grudge document — it's an operational record compliance and the successor will both read

Related

[[agent-hiring-panel]] is the front door this is the back door of; [[context-bankruptcy]] when the agent stays but its memory shouldn't; [[agent-incident-postmortem]] if an incident triggered this.