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. Take that one step further and there is something to think about. You are about to put your company’s working memory (every client relationship, decision and promise) in one place.

Keeping it in one place is the right call. What matters 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. Export, if it exists at all, gives you a chat log rather than a working memory. So in practice you stay, because leaving would mean losing what your company has built up. You are renting your own brain, and rent on things you cannot do without tends to go up.

Compare that with the other systems 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. So one of the most valuable things your company builds up is kept in the one place you cannot get it out of.

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 still apply when the processing happens inside an AI product.

”But you are a hosted vendor too”

We are, and it is a fair objection. 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 the tests below, the same as 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 is the most useful 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; someone else is storing it for you.

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 state it openly: 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 hold information and leave the acting to tools you control. 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. From a security point of view, this also means the memory has no way to send itself anywhere.

5. You can end it. Leaving should be something you can do yourself. 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

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 tells you something too. Weak answers do not mean a vendor is malicious. But over a long enough time, a company’s incentives win out over its intentions, and the only answers you can rely on are the ones built into how the system works.

The asset framing

Ownership is also about what you gain. A memory you can export, read and move is an asset: a structured record of how your company runs, used by your team and your AI tools alike, that grows more useful with every day of use and survives tool changes and departures. It can even change hands: an engine can be handed over to a new owner, who accepts it and takes over its 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. The technology is similar, but one is an asset and the other is a cost. 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 piece of the foundations track. From here, put the layer to work: connect your AI tools, give your first engine a purpose, then start with the decision log or pre-meeting briefs.