How to Build Version-Aware Memory for Persistent AI NPCs

If your NPCs need to remember players, follow current lore, and still preserve older story decisions, you need more than a chatbot with a document search box behind it.

The question that keeps coming up on RAG forums is a good one: what happens when your knowledge base contains a current rulebook, a superseded version of that rulebook, and a designer's proposal that has not been approved yet? Plain similarity search will happily quote all three. The proposal is often the most specific and best-written document in the pile, which means it is exactly the one that wins.

The fix is a version-aware memory system: one that separates current canon, historical context, experimental material, and per-player relationship state, and knows which of them is allowed to speak.

Who it's for: Game developers, narrative designers, and technical founders building persistent NPCs, living worlds, or AI companions that must stay consistent across sessions.

Step 1: Separate the kinds of memory your NPC actually needs

• Do not treat every fact the same. A persistent NPC usually needs at least four buckets: current lore, historical lore, experimental or proposed content, and player-specific memory.
• Current lore drives what the NPC says today. Historical lore explains why the current rule exists. Experimental material should be visible to you but never treated as canon. Player memory should be scoped per player so two people can have genuinely different relationships with the same character.
• The buckets matter more than the storage. You can implement all four in one table with a column, but you cannot implement them with no distinction at all.

Step 2: Give every source a version and an authority level

• A newer document is not automatically more authoritative. Tag each source with status, version, effective date, what it supersedes, and its scope.
• A design note may be newer than the rulebook and still lose to it, because the note is a proposal and the rulebook is canon. Your retrieval layer needs to know that before it answers, not after a player screenshots the reply.
• If you are not ready to build metadata plumbing, the cheap version of this is folder discipline: one document per authority level, and never edit canon and drafts into the same file.

Step 3: Build retrieval around precedence, not just similarity

• Classic RAG finds relevant text. Version-aware memory also has to decide which relevant text is allowed to speak first.
• Prefer current canonical sources during normal play, historical sources when the player is asking why something used to be different, and experimental sources only when someone explicitly asks about drafts or tests.
• A similarity floor helps here but does not solve it. Filtering out weak matches stops off-topic chunks from posing as fact; it does nothing about a strong match from the wrong document.

Step 4: Keep operational memory separate from raw chat logs

• A transcript is not memory. Transcripts are evidence. What the NPC should store is distilled: relationship changes, promises made, preferences learned, questions left open.
• This keeps memory compact, keeps prompts small, and stops the system from treating every passing exchange as durable truth.
• It also makes memory reviewable. You can read a list of twenty facts a character believes about a player. You cannot review nine thousand lines of dialogue.

Step 5: Add a claim-checking step before the NPC speaks

• Before a specific fact reaches the player, check whether it can be traced to approved memory or lore. If it cannot, rewrite it into something the character can honestly say, or have them decline.
• This matters most for the details players repeat: numbers, names, dates, distances, prices. A vague answer is recoverable. An invented garrison size becomes canon the moment someone posts it.
• "I never counted" is in character for almost every NPC ever written. Let the character be honest instead of forcing the model to be impressive.

Step 6: Make player relationships persistent and separate per user

• If one player insulted the blacksmith and another helped her, the character should carry those two histories independently.
• Store relationship state as a first-class object: trust, warmth, hostility, favours owed, recent topics, and a mood that drifts gradually rather than snapping.
• This is the part players actually notice. Lore consistency keeps a world from breaking. Per-player relationship state is what makes it feel inhabited.

Step 7: Preserve traceability when the knowledge base changes

• When a rule changes, do not overwrite the history. Mark the old rule as historical and record what replaced it.
• Retire documents by superseding them, not by editing them in place. If you rewrite the canonical file, whatever explained the old behaviour is gone, and deleting a source usually takes its indexed content with it.
• Done properly, the character can answer both "what is true now" and "why did it used to work that way" without mixing the two.

What MistScale does here today, and what it does not

Worth being precise, because this is the part most platform pages get vague about.

What the platform gives you:

• Per-player memory and relationships. Trust, patience, mood, and personality drift are tracked separately for every player against every character, and they persist across sessions.
• Claim checking before the line ships. Specific claims are checked against memory, your uploaded lore, and the character brief. Anything the character cannot source is rewritten or declined rather than invented.
• Draft and live staging with scoped access. World knowledge documents are unpublished by default, access grants can be staged as pending, and a Deploy action flips a whole batch live at once. Documents can be visible to every NPC or restricted to named audiences and individual characters.

What it does not do:

• There is no version, supersedes, or effective-date field on a document, and retrieval does not rank by authority. Relevance is similarity-based with a floor.

So the practical pattern today is to express precedence through what is published and who can read it. Keep current canon published and visible. Keep historical lore as its own document, published if you want characters to be able to explain the past, restricted to the NPCs who should know it. Keep experimental material unpublished, where it stays a draft that no character can read until you deploy it. That covers the case the thread was actually worried about, which is a proposal leaking into play as fact, without pretending the platform models a version graph it does not.

Common mistakes

• Using a long context window as a substitute for memory. It works right up until the conversation gets too large or too old, and then it fails silently.
• Treating RAG as a search engine rather than a governed retrieval layer with authority rules.
• Mixing current canon, historical notes, and experimental drafts into one bucket and hoping relevance sorts it out.
• Storing only raw transcripts and expecting the model to infer a durable relationship from them.
• Shipping with no claim-checking or refusal step, so the model is free to answer anything at any confidence.

FAQ

Is RAG enough for a persistent NPC?

RAG solves retrieval. It does not solve memory governance. For a persistent character you also need source authority, some notion of versioning, per-player state, and a claim-checking step before the line reaches a player.

Should I put all NPC memory into the prompt?

No. Prompts are the wrong place for anything that has to survive. Keep stable memory in structured storage and inject only the relevant current facts, the relationship state, and the approved lore at response time.

How do I stop an NPC from using outdated lore?

Tag sources by status and authority and make current canon outrank historical or experimental content during retrieval. On MistScale specifically, where retrieval does not rank by authority, do it by controlling publication: unpublished drafts are unreadable, and restricted documents reach only the characters you name.

Where should I start?

One NPC, one lore set, one persistent relationship loop. Talk to the character, come back the next session, and check three things: does it remember you, does it stay inside the lore you gave it, and does it decline when you ask something the documents do not cover. That takes an afternoon and tells you more than any architecture diagram.