Whatever was written down in the company's tools stays; whatever only existed in someone's head goes with them, and no tool recovers it. The difference is settled before the leaving date: a governed company memory attaches every page to a department and a named owner, so the successor inherits the read scope, and the AI working for them keeps answering.
The people whose departure frightens everyone
Every company has a handful of people whose departure frightens everyone, and they are almost never the ones the org chart puts forward. It is the person who knows why that one customer has had an unusual discount for years, who knows which suppliers stopped being called and why, the one you message with “can you take a quick look?” before sending anything that matters.
The day they hand in their notice, they are asked to document. In good faith they write a handover note that covers the procedures and not the exceptions, the files and not the judgement calls. Their successor then inherits a shared drive, a history of conversations they were not part of, and one sentence that comes back in every answer they get: “they would have known”.
A layer has been added since everyone works alongside an assistant. Theirs had come to know them well: their formats, their turns of phrase, the files they reopened every Monday. That memory is personal and it leaves with the account, which is right: it was never meant to become the company's context. We cover that boundary in company context and an assistant's personal memory.
The question nobody asks until the notice is in
“What did they know?” has no answer. “Which subjects were they actually keeping up to date?” has one, and that answer is not obtained by asking people. It is read off the work already done.
A governed company memory sets out two registers without merging them. The first is what is written down: who owns which department, who decides what. The second is what the work shows: who wrote and maintained the pages of a subject. The two do not always agree, and the gap is often the first thing a managing director discovers about their own organisation. These are counts, never a score: nobody is being rated, and someone whose work sits outside your read scope does not appear at all. It is one of the most useful questions context governance makes possible, and it can be asked from the console or straight from a connected AI.
Asked during the notice period rather than after it, that question changes what a handover is. You stop asking someone to document everything, which never works and which nobody does seriously in their final weeks. You ask them to fill in the few subjects where they are the only person who left a trace. That is bounded work, it ends, and they can see the point of it.
Filing knowledge under a responsibility, not under a person
A departure hurts first because knowledge is filed under people. It lives in a personal folder, in a mailbox, in a notebook, in the drafts of an assistant that belongs to one person only. None of it transfers, for a simple reason: none of it ever had an owner in the company sense.
A company memory reverses that filing. Every page belongs to a department, every department has a named owner, and every person carries a read scope attached to their responsibility. A connected AI never holds rights of its own: it sees no more than the person it is working for. We walk through that mechanism in who can see what when an AI plugs in.
The consequence fits in one sentence: whoever takes over the responsibility takes over the scope that goes with it. The AI working for them answers on day one, on the same subjects, from the same documents, with nobody having had to reconstruct anything. The knowledge did not move when the person left, because it was never filed under the person leaving.
Leaving day: what a removal cuts, and what it does not
Cutting access is the other half of the subject, and it is the half an outsider will examine. The removal is a single gesture. It cuts the AIs the person had connected in their name, their session at their next action, any sign-in link they had not used yet, and any export download in progress. It frees their seat on your plan. And it is written as a sealed event on your organisation's audit chain, which is what lets you establish the date of the cut months later without asking anyone to take your word for it.
One exception remains, and it is better said than discovered: an access an AI already holds stays valid until it expires, for at most a quarter of an hour. It cannot obtain a new one. A quarter of an hour is an answer anyone will accept; being caught not having mentioned it is not.
Two things, though, do not fall with the departure, because they belong to the company rather than to the person. The tool connections they had authorised, storage, email, CRM, keep working, which is what stops a departure from breaking your syncs overnight. And if your company once created a shared read key, in nobody's name, that survives too: this kind of access can no longer be created, but one that already exists can be reviewed, cut or rotated. The steps are on the When someone leaves page. The history of those decisions is precisely what you need in order to prove to an auditor what an AI was allowed to read.
Run the test on the last departure you lived through
None of this asks you to take our word for it, or to wait for the next resignation. The core of Kastel installs free of charge on your own infrastructure, and you plug your own AI keys into it. Take the most recent departure, load the documents of the subject that person held, then ask who wrote and maintained those pages. You will see whether the answer names the person you would have named from memory.
Then work in the other direction: open an access in your own name, close it again, and ask what the chain recorded. The date, the author and the approver are there. Finally, export your context in full: what you carry out has to be readable without us. That is the test of this article turned on the people who wrote it.