What should stay in an assistant's memory, and what has to leave it?
The rule fits in one line. A person's working preferences stay in their assistant's memory. Company facts have to leave it, because they concern people other than whoever dictated them, because they must stay true after that person resigns, and because somebody has to be able to say who is allowed to read them. An assistant's memory does none of the three.
When someone leaves, what their assistant knew leaves too
Someone at your company has worked with the same assistant for two years. It knows their accounts, the deals in flight, the arguments that land and the ones to stop using. That person resigns, the account closes, and everything the assistant had learned goes with them. Nothing was stolen. None of it had ever belonged to the company.
What stays behind is the mirror problem. Facts about the company sit in personal accounts nobody has inventoried. The day one of those facts turns false, nobody corrects it, because nobody knows it is there. The day it surfaces in an answer, nobody can say where it came from.
That accumulation is exactly what makes changing tools expensive. The more each assistant learns, the dearer it becomes to leave, and the expense is not the subscription. It is that the knowledge lives inside the tool, with a vendor who can change terms, prices or the offering itself without consulting you.
What has to exist somewhere other than inside a tool
An assistant's memory is not a bad object, and this page is not asking you to switch it off. It does the thing it exists for, which is to remember how one person likes to work. It simply cannot answer the question of who in your company is allowed to see a piece of information, because that is not its job.
The company's shared reference is a different object, and the gap between the two is one of nature. You recognise it by three properties, which the product builds and maintains.
It is built from the sources that carry authority
An assistant's memory keeps whatever crosses the conversation, at the moment it crosses. The company reference is built from the real reporting lines, the processes actually in force and the decisions actually taken, each part with somebody answerable for it. What enters has been validated by whoever is responsible for it, and what turns false is corrected at the source.
Each person gets their own scope inside it
A fact can belong to the whole company without being visible to everyone in it. The read scope follows each person's responsibility, and the AI working for them reads only what they are allowed to read. You decide what each AI is allowed to see, and every access decision enters a sealed chain that keeps who made it and who approved it.
It outlives tools as well as people
The reference lives outside the assistants, which come and read it over MCP, the standard socket an AI plugs into. When somebody leaves, it stays. When you change tools, you unplug and plug back in with nothing to rebuild, which is precisely the condition for switching providers without paying twice.
The moments where the difference gets paid for
The two objects coexist perfectly well, and the useful question is not which one is better. It is where each fact belongs. These five situations answer it, and the last one is a limit of Kastel's.
The flagged line does not favour us. A context layer governs what leaves your side towards an AI, not what a tool has already committed to memory.
The test that answers in one evening
Kastel's core is free and installs on your own infrastructure, with your own AI keys. Build a small reference from your sources, then connect two assistants from two different vendors to it. Ask them the same question. Both answer from the same reference, and neither had to learn it first.
Now unplug the first and connect a third. Nothing needs rebuilding, because nothing that mattered lived inside the tool you just removed. Finally, export the lot: your context follows you if you leave, and that is checkable with one command rather than by taking our word for it.
What Kastel cannot do on your assistant's behalf
Kastel does not control your assistants' internal memory and does not replace it. What each tool retains from its conversations belongs to that tool and to the settings you make there. Kastel does not make it forget, and no context layer can: whatever has already entered a model or a product's memory stays there until its vendor gives you a way to get it out.
What Kastel gives you is a reference complete enough and safe enough that company facts no longer have any reason to go and live in those memories. If you work alone, or if nothing at your end is confidential towards an internal reader, this separation does not concern you yet.
Nobody knows which AI knows what?
At the scale of an organisation, that stops being a setting and becomes a governance question. Let us talk about what yours needs to be able to establish, and what Kastel records on your behalf.
See Kastel Enterprise