One of us went back to DeepSeek's desktop app last week, half expecting to find a memory feature, and found the same blank slate as always. Every other major assistant has shipped some version of it by now. ChatGPT has saved memories and custom instructions. Claude has memory and project knowledge. Gemini carries things across conversations. Grok has its own take. DeepSeek, which publishes open-weight models and built its reputation on price, still starts every conversation from zero.
The surprise is not that a company skipped a feature. The surprise is which feature. Memory is not a hard engineering problem for a team that shipped these models. Anyone who has wired a retrieval layer around a language model has watched it work in an afternoon. So if the capability is sitting right there, the reason it is missing is not technical. That should interest anybody who is buying AI for a business, because it tells you what these tools are actually built to do.
What memory means when we say it
Memory shows up in three forms, and businesses tend to mix them up.
The first is the saved fact. Your name, your company, the way you like an answer structured, the fact that your fiscal year does not match the calendar. Small stuff that removes friction.
The second is standing instructions. How the assistant should write for you, what it should never do, which of your products it should never confuse with another. This is the difference between a tool that sounds like your business and one that sounds like a press release.
The third is the one that matters most and gets discussed least. Knowledge of the actual work. The client who pays late and needs a different tone in a reminder. The three questions customers ask before they buy. The way your service is priced and why. The decisions you made last quarter and the reasons behind them.
Only the third one has real value in a business, and only the third one is genuinely hard to buy. The first two are settings. The third is your context, and context is the thing that turns a general model into something that can be trusted with real work.
The tax you pay when nothing is remembered
An assistant that forgets everything is not useless. It is just permanently new.
That means every task starts with an explanation. Every new person on your team gets a different version of the explanation. Every conversation recreates the same background, and whatever gets left out is where the mistakes come from. You end up with a tool that is fast at producing a first draft and slow at being right, because all of the knowledge that makes a draft correct still lives in your head.
There is a sharper version of this. When an assistant has no memory of your business, it has no way to notice that it is contradicting you. It will happily write a proposal with a payment term you stopped offering, describe a service you retired, or invent a client reference you would never use, and it will do all of it in a confident voice. The absence of memory is the absence of a check.
We have watched teams build genuinely good workflows around a model with no memory at all. They make it work by keeping the context outside the tool: a folder of business documents, a page of standard answers, a short brief they paste in at the start. It works. It is also manual, and manual processes decay the moment the person who set them up gets busy.
Why the vendor may not be in a hurry
We do not know DeepSeek's reasoning, and we are not going to guess at their roadmap. But the tradeoffs are visible from the outside, and they are the same tradeoffs any business faces when it decides to remember something about its customers.
Memory means storing personal and commercial information for a long time. It means deciding how long, who can read it, whether it trains a model, what happens when a customer asks for it to be deleted, and what you do when a lawyer asks for it. It also means your users become harder to lose, because the value of the tool grows the longer they stay. That last part is a business decision, not a technical one, and it cuts in a direction most vendors like.
When a feature is missing in one place and present in another, the question worth asking is who benefits from each arrangement. That question has a better track record than any roadmap.
What we do instead of waiting
The businesses we work with cannot wait for a vendor to decide that remembering them is a priority. So we build the memory layer, and we build it outside the assistant.
The core of it is a business context file that belongs to the client. One document, in a plain format they can read without us: what the business sells, who buys it, the language customers use, the offers that are current, the things that must never appear in customer-facing writing. It is not a prompt trick. It is a written description of the business, kept current, that any model can be pointed at.
Around that file we put the documents that already existed and were never usable. Standard replies. The pricing sheet. The onboarding checklist. The answers to the questions the front desk gets forty times a month. When those live in a folder with sensible names instead of in someone's memory, an assistant can be pointed at them, and every answer it gives has a source a human can check.
Then we test whether it actually helps, against real tasks from the week before, with a person reading the output. That test is boring and it is the only reason we know a setup works rather than merely runs.
There is a version of this that goes further and skips the vendor entirely. If your context sits in files you own, the same files work with a model running on a machine in your office. For businesses handling client confidentiality, that arrangement changes the conversation, because the data never leaves the building. The memory becomes a fact of your own hardware rather than a policy someone else wrote. We use that approach ourselves and we set it up for clients who need it. We wrote about how AI fits into real operations here on the site, and the short version is that the interesting work happens before the model is chosen, in deciding what it should know.
Questions worth asking before you trust a memory feature
Any assistant that claims it remembers you is making a promise about data. Four questions settle most of it.
Where does the memory live, in your account or in a shared pool, and can you see it? If you cannot read what the system believes about your business, you cannot correct it, and a wrong memory is worse than no memory.
Can you export it and move it? The useful test is whether that knowledge survives a change of model. If it does not, you are not building context, you are renting it.
Who else can see it? Retention periods, training use, human review, and legal exposure all belong in the answer. So does the simpler question of which of your employees' accounts are holding fragments of the same knowledge.
What happens when you leave? Deletion timing, and whether deleting is truly deleting, tells you how much of your own institutional knowledge you are handing over.
We are not asking vendors to be saints. We are pointing out that a memory feature is a data relationship, and data relationships deserve the same attention you give a contract.
Where this leaves business owners
Memory is not a nice-to-have that will arrive later. It is the part of the stack that decides whether AI is a faster version of your business or a faster version of a search engine. Once you accept that, the plan stops depending on any vendor's release notes.
Write the context down. Keep the documents where anyone can point a model at them. Put one person in charge of keeping it current. Test the output against work you have already done. Then, when the assistant you like finally ships a memory feature, you can turn it on without betting the business on it, because the knowledge was never the vendor's in the first place.
That is the work we do with clients who want AI to be useful on day one and not just impressive in a demo. If you want that built for your business, start here.