---
name: Agent Severance
slug: agent-severance
category: DevOps
description: Agent Severance inventories everything an AI agent knew and touched, revokes its credentials and access, exports or purges its memory, and produces a handover for its successor. Use when decommissioning an agent, switching vendors, or ending a pilot.
github: "https://github.com/mohitagw15856/pm-claude-skills/tree/main/skills/agent-severance"
language: HTML
stars: 1295
forks: 231
install: "npx degit https://github.com/mohitagw15856/pm-claude-skills/tree/main/skills/agent-severance ~/.claude/skills/agent-severance"
installs_to: ~/.claude/skills/agent-severance
source_path: skills/agent-severance/SKILL.md
collection_size: 25
category_size: 798
collection_url: "https://dirskills.com/collections/mohitagw15856/pm-claude-skills"
added: 2026-08-20T07:54:59.927Z
last_synced: 2026-08-20T07:54:59.927Z
canonical_url: "https://dirskills.com/skills/agent-severance"
---

# Agent Severance

Agent Severance inventories everything an AI agent knew and touched, revokes its credentials and access, exports or purges its memory, and produces a handover for its successor. Use when decommissioning an agent, switching vendors, or ending a pilot.

**Install:**

```bash
npx degit https://github.com/mohitagw15856/pm-claude-skills/tree/main/skills/agent-severance ~/.claude/skills/agent-severance
```

## README

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