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.

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

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

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

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