What is typed memory in AI

Most AI memory today is chat history. A long log of every conversation you have ever had with an assistant, kept in a database somewhere, retrieved by similarity search when the model decides it needs context.

Typed memory is something different. It is memory that carries a category. The medication is typed as "medication". The renewal date is typed as "renewal date". The supplier contact is typed as "supplier contact". The category is part of the data, not inferred from it.

This is not a technical curiosity. It changes three things that matter to the person using the memory layer.

It changes retrieval precision

Untyped memory works by similarity. When the assistant decides it needs context, it searches the chat log for passages that look related to the current question. The result is whatever the embedding model thinks is closest. Some of it is relevant. Some of it is conversational noise that happens to share vocabulary.

Typed memory works by category. When the assistant needs to know about your medications, it asks for memories of type "medication" instead of doing a fuzzy search across everything you have ever said. Less noise, less hallucination, more relevant context.

The difference is concrete. An untyped memory layer asked "what medications am I on" might return a year-old conversation in which you mentioned considering a supplement, and a six-month- old chat where you were researching side effects of a drug for a friend. The model has to reason its way through the noise to an answer. Sometimes it gets there. Sometimes it does not.

A typed memory layer returns the structured medication record: name, dose, frequency, prescriber. The model has the answer without having to interpret the database. The difference compounds across hundreds of interactions. A user who asks ten questions a day for a year is asking 3,650 questions in which the cost of imprecise retrieval has been paid one way or another.

It changes what the user can review

Typed memory is reviewable in a way chat-log memory is not. A user can ask "show me everything you have stored about my finances" and get a clean list. They can review individual entries. They can edit anything that is wrong. They can revoke specific items they no longer want stored.

With chat-log memory, the same request returns a wall of conversational text that may or may not contain financial information. The user has to read every passage to find what was actually stored about them. Most users will not do this. The ones that do will find that the line between "the assistant knows this" and "the assistant once heard this" is genuinely unclear.

Typed memory makes the user's right to see what is stored a usable right. Without typing, the right exists in principle and is unusable in practice.

It changes the consent model

Consent at the level of a type is meaningfully different from consent at the level of a string. A user can revoke consent for "health data" as a category and have the system reliably remove the relevant memories. The action is precise. The outcome is verifiable.

With chat-log memory, the same revocation requires the system to interpret which conversations contained health discussion. The interpretation can be done by another model, but it is probabilistic. Some health-related context will be missed. Some non-health context will be removed. The user has no way to check whether the request was honoured precisely.

Typed memory makes consent operational. The user grants permission for a category, revokes it for a category, and audits at the category level. This matters more under UK GDPR and the EU AI Act than it did when AI memory was a novelty. The right to erasure becomes a real-time UI control rather than a 30-day data subject request.

Typed memory makes the user's right to see what is stored a usable right, not a theoretical one.

What this costs

Typed memory is harder to capture than chat-log memory. Someone or something has to assign the type. The product can infer types from the context of a conversation, but inference is imperfect. The user often has to confirm or correct the type, especially in the early weeks of using the product.

Onboarding does more work upfront. The user is asked questions the chat-log alternative does not ask. The product is slower to feel useful, because the structure has to exist before the retrieval can be precise. Two weeks in, the experience flips: the typed product becomes more useful per interaction, while the chat-log product plateaus at the precision of similarity search.

The trade-off is honest. More setup, more useful and more controllable after. The product has to choose which side of that trade-off it wants to live on, and the choice cannot be retrofitted later. A product built around chat-log memory cannot be re-grounded as a typed memory product without rewriting most of the storage layer.

Where the category will end up

Chat-log memory is what the AI industry built first because it was the easiest thing to build. Typed memory is what people will increasingly expect once they have lived with the alternative.

The longer-term question is whether AI memory will be predominantly typed or predominantly logged. The answer probably comes down to whether the people building memory layers think of them as developer infrastructure or as something a person will actually want to live with.