How to Build AI Memory You Can Keep When Models Change: Part 2

Five rules for what to remember, what to forget, and how to test whether your company knowledge survives a model switch.

Part 1 ended on a slightly uncomfortable point: the more useful AI gets, the more company knowledge can start collecting around it.

So what do you do with that?

Definitely not save everything.

A lot of AI memory advice gets technical very quickly. Vector stores, graphs, embeddings, retrieval strategies. Those choices matter to engineering. But before any of them, there is a much more ordinary question for the people running the work: what are we actually allowing this system to remember about the company?

Part 2 is our answer. Five rules, one small test, and no requirement that you become a memory researcher first.

1. Do Not Save Everything Just Because You Can

Most AI interactions do not deserve to become durable company memory.

A current policy, an approved correction, an important decision, or a lesson that will matter next time can be worth keeping. A brainstorm, an abandoned draft, a guess, or a one off instruction usually is not.

The useful filter is simple: will this information matter beyond the current task, and would we be comfortable defending it later if the AI used it again?

If the answer is unclear, do not promote it into durable memory yet. Keep it as working context and let it disappear with the task.

2. Keep the Policy and the Exception as Two Different Things

This is the distinction we would protect most aggressively.

Say the standard discount is 10%. A manager approves 15% for one strategic account. The policy is company truth. The 15% approval is a decision about one case.

If the system stores both as the same kind of memory, the exception can quietly start behaving like a rule.

Recent memory research is moving in the same direction, separating objective facts from observations, beliefs, and experience. The labels vary. The operating idea is what matters: what the company says and what happened once should never be indistinguishable.

3. Every Important Memory Needs a Source, Date, and Status

In our data readiness work, we already push for ownership, dates, and a way to tell whether a source is still current. AI memory needs the same discipline after people start teaching the system through use.

If a memory can change a customer answer, approval, price, or business action, someone should be able to ask 4 simple questions: where did this come from, when did it happen, who approved it if a person was involved, and is it still current?

We think of that as the receipt attached to the memory.

The receipt is what stops a confident AI inference from sitting beside an approved company rule with the same weight. It also makes the next correction much easier because you can see what you are replacing instead of guessing how the system got there.

4. Give Old Memory a Way to Stop Being True

Companies change. Memory has to change with them.

A price gets updated. An exception expires. A customer moves to a different contract. A process changes after the team finds a better way to run it.

If the system can only add memory, old information does not disappear. It just gets more company.

This is why current memory research is explicitly testing operations such as add, update, delete, and ignore, while early technical proposals include version, validation, and lifecycle states. The industry is arriving at the same practical conclusion: remembering is only half the job.

5. Keep Company Intelligence Outside the Model

This is the architecture rule that makes the other 4 easier to live with.

The company rules, customer specifics, pricing logic, and approved operating knowledge should live in a company layer that can survive a model change. The model should use that intelligence, not own it.

This is also why Mustang, our AI operating system, is built the way it is. We kept seeing the same pain in client work: models change quickly, while the company cannot keep starting over around them.