Agent Severance

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.