Who Owns Your Company's AI Memory?

This track has built a picture piece by piece: your AI tools fail because they lack memory, the fix is a context layer, and once it exists, every agent you run draws from it. Follow that logic one step further and something should make you pause. You are about to concentrate your company’s working memory, every client relationship, every decision, every promise, in one place.

Concentrating it is correct. The question is who holds it, and on what terms.

”Renting your own brain”

Most AI products answer that question quietly, in the terms of service. Your prompts, your uploaded documents, the “memory” the tool builds up about your company all live inside their product, in their format, under their rules. You can use it. You cannot take it with you.

Consider what that means three years in. The tool now embodies thousands of hours of your company’s context. The vendor raises prices, gets acquired, changes direction, or simply becomes worse than a competitor. What is your move? Export, if it exists at all, gives you a chat log, not a working memory. In practice you stay, because leaving means lobotomizing your own company. You are renting your own brain, and rent on essential things only ever goes up.

Notice the asymmetry with every other system you run. If your email host disappoints, you move the mailboxes. If your CRM disappoints, you migrate the records, painfully, but possible, because the data has a shape other tools understand. AI memory as most vendors build it has no such shape: it is entangled with their product on purpose. The stickiest asset your company produces is being accumulated in the one place you cannot retrieve it from.

For some tools that trade is fine; nobody needs ownership of their grammar checker. For the layer that holds everything, it is a strategic error, and for law firms, finance, healthcare and anyone with confidentiality obligations, it may not even be an option: privilege, professional secrecy and data protection duties do not evaporate because the processing happens inside an AI product.

”But you are a hosted vendor too”

We are, and it is a fair objection, so let us be plain about it. Context Engine is a hosted service. We run it; you do not run servers. We think that is the right trade for most companies, because almost nobody wants to operate infrastructure for their memory. But it means you should judge us by exactly the tests below, and so should you judge anyone else.

Ownership, for a hosted memory, does not mean the machine is in your building. It means the memory is separable from the vendor: you can read it without them, nobody at the vendor reads it without your say (and you are told at once if a legal duty ever overrides that), it is never turned into something else, and you can end it. How we hold ourselves to that, and where the limits are, is in Your AI Vendor Can Read Everything. Ours Has to Ask.

The five tests

1. You can read it without the vendor. This one is underrated, and it is the sharpest test on the list. Your memory should come out in a format a human can open. In Context Engine, an owner can export any engine at any time as one ZIP of Markdown files with YAML frontmatter, plus JSON. A text editor opens it; grep searches it; a notes app that reads Markdown can open the folder as it is. Try the thought experiment on any AI product you use today: if the company folded tonight, what would you actually hold tomorrow? If the answer is “a proprietary blob” or “nothing,” you do not own your data. You store it with someone.

2. It is isolated, physically. Most hosted software keeps every customer in one shared database and relies on a filter to keep them apart. That is how data ends up one authorization bug away from someone else’s. In Context Engine every engine gets its own database, its own search index and its own Worker. Isolation is physical, not a filter on a shared table. That also lets you draw boundaries inside your own company: one engine per client, so a client’s memory lives in its own box. If location matters, you can choose the EU when you set an engine up, which keeps its database and stored files in the EU.

3. Nobody reads it without your say. Ask any vendor whether their staff can read your content, and under what controls. Our answer: Context Engine support opens an engine only when an owner or admin approves a request, for the time the request names, and every visit is logged. There is one exception, and we would rather name it than hide it: a legal or safety duty. Then access opens at once, the owner is told at once, and it is logged. Your content is sent to models only to answer you. It is never used to train models, never sold and never used for advertising.

4. It cannot act behind your back. Memory should be a library, not an actor. Context Engine does not run your agents and does not reach into your other apps. Everything that reads or saves is a connection you created, reaching only the engines you ticked, at Can read or Can read and save. Owners and admins see every connection with its access and last use, and can cut any of them off. Every change to a memory records who made it and with which tool. The same property, viewed from the security side, means the memory has no way of its own to send itself anywhere.

5. You can end it. An exit is not a promise in a sales call. It is a button. Deleting an engine is scheduled a day ahead, so you have time to export, and then it is gone. An export can be restored into a new, empty engine, so a copy is a working memory again rather than an archive.

Five questions to ask any vendor

If you take nothing else from this piece, take the checklist. Ask these before adopting anything that will hold your company’s memory:

1. Can we export everything, in a format we can open without your software?
2. Is our data physically separate from other customers’, or kept apart by a filter?
3. Can your staff read our content? Under what controls, who approves it, and is every access logged?
4. Is any of it used to train models, sold or used for advertising?
5. When we delete it, when is it actually gone?

Vendors with good answers give them quickly and in writing. Hesitation is an answer too. And one calibration note: the point is not that every vendor with weak answers is malicious. It is that on a long enough timeline, incentives beat intentions, and the answers that survive incentive drift are the ones built into how the system works.

The asset framing

Here is the positive version of the argument, because ownership is not only defense. A memory you can export, read and move is an asset: an accumulating, structured record of how your company runs, that appreciates with every day of use and survives every tool change and every departure. It can even change hands: an engine can be handed over to a new owner, who accepts it onto their own plan, with the record of who wrote what intact. A memory locked inside one vendor’s chatbot is an operating dependency: a monthly fee for access to your own accumulated past. Similar technology, opposite sides of the ledger. Owners get to choose which one they are building.

Build this yourself

1. Create an engine for something sensitive, one client say, with a purpose that says what belongs there and what does not. Choose the EU at setup if that matters to you.
2. Connect only the AI tools that need it, and give each the least access that works: Can read for tools that only look.
3. Run the exit drill on day one: export the engine and open the ZIP in a text editor. Then you know what you hold.

Start free, or see plans.

Ownership is the last conceptual piece of this track. What remains is practical: what actually happens, week by week, when a company puts this layer in place and rebuilds its work on top. That is the final piece.