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
- 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.
- 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.
- 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.
- 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.
- 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.
