Why is offboarding a process?
Offboarding an AI employee is a process because a Digital FTE accumulates three things over its tenure: connections to your systems, a memory of your business, and a record of everything it proposed and you approved. Each needs a decision when the role ends, and a switch that stops the work does not make those decisions for you.
The good news is that all three live in one place, the workspace, so the process is shorter than offboarding a person and leaves a cleaner record.
How do you revoke access?
Revoke access by disconnecting every integration from the Digital FTE's Setup tab. Each disconnection revokes the credential the platform held for that tool and is logged with who did it and when. If the role used dedicated accounts or tokens at the tools themselves, remove those at the tool as well, which is why the credential guide recommends dedicated ones.
Pause the FTE at the same time so no scheduled work runs. Any connector links that carried a credential, such as one exposing the role to an external assistant, are rotated or removed.
What should you retain?
Retain the audit trail. It is the record of every proposal, approval, publish, and spend during the role's tenure, and it belongs with your other decision records under whatever retention those follow. It is yours, and it should be exported if the vendor's retention is shorter than yours.
Consider retaining the Memory tab's confirmed knowledge, the Brand Brain, if a successor role will need it. Because every item shows its provenance and has been confirmed by you, it is a reviewed asset rather than a cache, and a new Search Visibility FTE or Content FTE can start from it rather than from nothing.
- Retain: audit trail, exported if needed, under your records retention
- Retain if useful: confirmed Brand Brain knowledge for a successor
- Delete: drafts and work product not needed, per the underlying activity's retention
- Delete: anything containing personal data no longer needed
How do you request deletion?
Request deletion of what is not retained. For a single role that is stopped while the organization continues, this is usually the role's drafts and work product; for an organization leaving the platform, it is the organization's data as a whole, requested through the privacy contact on the ftes.ai security page.
Ask for confirmation of deletion and keep it. Under data protection rules the request and the confirmation are part of your processing records, and a future auditor or subject access request may need them.
How do you record it?
Record the offboarding with the date, who performed each step, what was retained and where, what was deleted and the confirmation. Keep it with the role's final review, which the Digital FTE can write in the first person before it is paused: what it delivered over its tenure, what it recommends for a successor, and what remained open.
That final review, the exported trail, and the confirmed memory are the handover. A role that ends this way leaves the organization better informed than it found it, which is not something offboarding usually achieves.
What does the FTE's final review look like, and what does a successor inherit?
The final review is written by the Digital FTE in the first person before it is paused, in the same shape as its monthly report: what it delivered over its tenure against the targets it was set, with the evidence in Targets; what it missed and why; what remained open on the day it stopped, such as exceptions undecided or drafts unapproved; and what it recommends for whoever picks up the function, including the remit rules that took longest to get right and the classes of action that had earned autonomy.
A successor role inherits three things if the organization chooses to keep them: the confirmed Brand Brain for the property, so it starts from reviewed knowledge rather than from nothing; the audit trail, exported or retained, so the history of decisions is readable; and the final review itself. What the successor does not inherit is autonomy. Every class starts again at Level 0 with the new role's own record, because the grants were made to a specific role on a specific record, and the new manager should see that record build before trusting it. Offboarding done this way leaves the function better documented than it was found.