How to Give AI NPCs Memory of the Player

An NPC that greets you like a stranger after you saved their village breaks the spell faster than any bad line. Language models don't recall anything on their own: each request starts empty. This guide shows how to give AI NPCs memory that works in a real game, what to store where, and what to let them forget.

The three kinds of NPC memory

It helps to split "memory" into three jobs, because each one lives in a different place:

Most do-it-yourself setups try to put all three into one growing prompt, and that is where the trouble starts: the prompt gets long, slow and expensive, and the model starts mixing old details with new ones.

Conversation memory: keep the session

In Neocortex every conversation is a session. The first reply gives you a sessionId. Send it back with the next message and the character continues where it left off.

For memory across play sessions, save that id per player and per character:

• When the player first talks to Brannoch the smith, store the sessionId in your save data under brannoch.
• Next time they meet, send the saved id with the first message.
• Brannoch picks up from the last conversation instead of introducing himself again.

If you want a character to forget, start a new session by leaving the id out. A guard who meets hundreds of travellers probably shouldn't recall each chat. A companion should.

The engine SDKs handle the saving for you. The Unity and Godot SDKs store each character's session id on the player's device, and the Unreal plugin keeps it in the project's config, so the conversation picks up where it left off. To start fresh, call CleanSessionID in Unity, clean_session_id() in Godot, or Clear Session Id in Unreal.

Facts about the player: your save file is the source of truth

Some things the player did matter to gameplay whether or not anyone mentions them: quests finished, debts paid, people hurt. Your game already tracks those, so keep them there and tell the character about them as events.

Neocortex chat requests take an events list. Each entry is a plain sentence with a priority:

{
  "characterIds": ["BRANNOCH_ID"],
  "sessionId": "SAVED_SESSION_ID",
  "message": "Morning. Any work for me?",
  "events": [
    { "priority": 2, "content": "The player returned Brannoch's stolen hammer." },
    { "priority": 1, "content": "The player sold ore to the rival smith.", "date": "last week" }
  ]
}

Brannoch now answers with both in mind: grateful for the hammer, a little sour about the ore. The priority tells the character what weighs most, from low (0) to high (2), and the optional date says when it happened. Keep the list short: up to 20 events, each a sentence of 64 characters or fewer, which is plenty if you send only what matters now.

In the engines you don't build this JSON yourself. In Unity and Godot, NeocortexEventLogger pushes an event that goes with every request until you clear it, which suits lasting facts. In Unreal, Push Event sends it with the next message only, which suits one-off news.

This split also keeps your game in charge. The character can talk about the hammer, but only your code decides whether the hammer was returned.

World knowledge: a knowledge base, not memory

Lore isn't memory, but it is often confused with it. The history of the mine, the prices in the market and the names of the baron's children belong in the character's knowledge base: files you upload in the editor that the character answers from. Every character who should know something gets the same file, so their stories match.

Deciding what NPCs forget

Perfect recall is creepy and expensive. Good NPC memory is selective:

• Keep the turning points. Saved a life, broke a promise, stole something. These are permanent.
• Summarize the middle. Ten trades become "a regular customer who pays on time".
• Drop the noise. Small talk about the weather doesn't need to survive the night.
• Let it fade with distance. A shopkeeper in another city has heard rumours, not details. Send them a vaguer event, or none.

A simple rule we use: if the fact would change how the character treats the player, keep it. If not, let it go.

Shared memory: gossip and reputation

In a living world, characters talk to each other. Two ways to do it:

• Broadcast events. When the player burns down the granary, send that event to every character in town. Each one reacts in their own way.
• Group chat. In a Neocortex group chat (Pro and Team plans, up to six characters), the characters share one conversation. Whatever the player told the innkeeper, the bard at the next table heard it too.

Common mistakes

• Sending the whole history every time. Long prompts are slow and costly. Keep the session for the conversation and send only the facts that matter now.
• Letting the model decide what happened. If the character says "you already paid me", that must come from your game state, not from the model's guess.
• One memory for every NPC. A stranger shouldn't know what the player told their companion in private.

Next steps

Memory works best with a clear personality underneath it, so read how to give NPCs unique personalities, and see how characters stay in character when players test them. To build it in an engine, start with the Unity, Unreal or Godot guide, or browse the full guide to building AI NPCs.

Frequently Asked Questions