The pilot ended in March. Someone turned the agent off, the vendor stopped invoicing, and the Slack channel went quiet. Seven months later, its OAuth token to Salesforce is still valid, it still has read access to a shared inbox, and it still holds calendar scope on three AEs who have since changed territories.

Nobody did anything wrong. Nobody did anything at all. That is the problem.

Agents get switched off, not offboarded

When a rep leaves, there is a process. HR triggers it, IT runs it, and by Friday the laptop is wiped and the CRM seat is reclaimed. When an agent leaves, there is usually a toggle.

Security people have noticed. The OWASP Non-Human Identities Top 10 ranks improper offboarding as the number one risk for the credentials that software, rather than people, holds. AI agents are the fastest-growing population of exactly those identities, and GTM is where a lot of them live.

The retirement wave is also coming whether you plan for it or not. Gartner predicts that by 2027, 40% of enterprises will demote or decommission AI agents over governance gaps found only after production incidents. Add the ordinary churn of a GTM stack (pilots that end, vendors that get swapped at renewal, a homegrown agent replaced by one bundled into a tool you already pay for) and every revenue team will be retiring agents on a regular cadence. Most have no runbook for it.

Why GTM agents are harder to offboard than people

A departing employee has one identity. A GTM agent rarely does.

The Cloud Security Alliance, summarizing a January 2026 survey with Aembit of 228 IT and security professionals, found that 43% of organizations run AI agents on shared or generic service accounts, 31% run them under delegated human user identities, and only 36% give agents dedicated identities with their own permission sets.

Translate that into a sales floor and the picture gets specific:

• Borrowed credentials. The agent authenticated as the RevOps admin who set it up. Revoke its access and you lock out a person. Leave it and the agent keeps that admin's reach.

• Scattered grants. It was connected separately to the CRM, the call recorder, the shared drive and the email platform. Four consoles, four sets of scopes, four places to forget.

• Work in flight. A queued sequence, a scheduled enrichment job, a batch of field updates waiting to sync. Switching off the interface does not always stop the jobs behind it.

• Copies of your data. Call notes, account summaries and contact lists cached in a vendor's store, or embedded in an index nobody owns any more.

• Lost lessons. Whatever the team learned through that agent (which drafts got approved, which got rewritten, which plays actually moved a deal) disappears with it if it only ever lived inside the agent.

The first four are a security problem. The fifth is a revenue problem, and nobody's runbook covers it.

The agent offboarding checklist

This belongs to RevOps, not just to security, because RevOps knows which agents touch which records and why. Run it every time an agent is paused, replaced, or retired:

1. Keep an inventory before you need one. Every agent, its owner, the systems it touches, and the identity it uses. If you cannot list it, you cannot offboard it.

2. Name a human owner for the retirement. Someone signs off that each step below is done. Shared ownership means no ownership.

3. Revoke at the source, not in the app. Kill the tokens and connected-app grants inside the CRM, the inbox, and the calendar. Uninstalling the agent's front end often leaves the grants behind.

4. Rotate anything shared. If the agent ran on a service account or a borrowed human login, rotate it. Then give the replacement agent its own identity.

5. Drain the queue. Cancel scheduled jobs, pause sequences, and resolve pending writes, so nothing lands in a live opportunity after the agent is "gone."

6. Reclaim the data. Confirm what the vendor stored, request deletion where your contract allows it, and remove the agent from any shared indexes.

7. Keep the receipts. Archive the audit trail of what the agent read and wrote. If a deal record looks wrong in six months, you will want to know whether a person or a retired agent changed it.

8. Capture what it taught you. Record why it was retired and what worked. The next agent should start from that, not from zero.

None of this is exotic. It is the same discipline you already apply to people, applied to the identities that now outnumber them in your stack.

Offboarding is easy when access was never scattered

The checklist above is long because the access was scattered in the first place. Each agent wired into each system separately means each retirement is a scavenger hunt.

The structural fix is to stop granting agents direct access to everything. Put one governed door between your agents and your stack, give every agent its own identity and permissions at that door, and keep the record of every action there. Retiring an agent then becomes one revocation in one place, with the audit trail already sitting where you need it. The same logic applies to what agents learn: if grounding and outcome feedback live in a shared layer rather than inside each agent, swapping an agent out does not wipe the team's memory.

That is the design behind wysdym, the operating layer for agentic GTM. Not another agent. The layer your agents and your team run on: Cortex holds shared intelligence and memory, Governance sets the rules on every action, and every agent connects through the Gateway, one MCP door to your stack. Agents come and go. The grounding, the rules, and the lessons stay. You can see how the pillars fit together at wysdym.ai/platform, and the wider control set is in our piece on what governance AI agents need on a revenue team.

More agents won't grow revenue. Compounding intelligence will. And compounding only works if the intelligence outlives the agent.