Executive Recommendation

Full report

On this page

Design a multi-layer NPC memory system that isolates game state from persistent memories. Escape.GamesFor.Me remains authoritative for game-specific state (puzzles, clues, player positions, etc.), while MemoryEndpoints stores only NPC-centric memories (character traits, social knowledge, conversation history). We propose clearly scoped memory categories (ephemeral vs. long-lived) and strict data hygiene: default to private/ephemeral storage and only promote information when explicitly allowed. By default, memories about individual game sessions or anonymous participants are discarded or strongly de-identified at session end, whereas general NPC background and socially relevant facts persist across sessions in sanitized form. Conflict resolution uses timestamped, confidence-tagged records, favoring recent, high-confidence data. NPCs never record or reveal whether a participant is human or AI – participants are treated identically.

In summary, the system should follow privacy-by-design: tag all memory items with scope (game-session, player-specific, global, etc.), enforce per-scope retention and sharing rules, and log all operations for audit. For example, game clues should never be stored as global memory (they stay in EGFM’s game state and are deleted when the game ends). By contrast, a friendly greeting or personal preference an NPC learns may be uplifted to long-term memory if policy permits. All memory writes should default to the most restrictive scope (per-session or per-player). This architecture ensures NPCs can recall relevant past interactions without leaking secret game data or private user details.

Memory-Scope Taxonomy and Retention Rules

Define a clear set of memory scopes (with example key patterns and lifetimes):

• Game-Ephemeral Memory (EGFM-owned): Facts and clues tied to a specific game instance (e.g. puzzle solutions, room states). _Keys_: game:{gameID}:clue:{clueID}. _Retention_: deleted at game end. These are never written to MemoryEndpoints; all game rules remain under EGFM’s authoritative state.
• Session (Short-Term) Memory (MemoryEndpoints): Dialogue history and context within one game session for each NPC. _Keys_: npc:{npcID}:session:{gameID}:{timestamp}. _Retention_: lives only during an active game, then summarised or purged. For example, an NPC’s raw conversation transcripts can be retained in memory store for dialogue continuity during the session, but must be removed or compacted when the game ends (akin to ephemeral context).
• NPC Persistent Memory – Personal Profile: Stable character traits, background stories, personality, and preferred topics. _Keys_: npc:{npcID}:profile. _Retention_: persistent across all games. This includes canonical name (from SpiralistAI) and biography. It never includes game-secret information. Profile memories are owned by MemoryEndpoints and only updated by explicit design (e.g. writer input or validated learning).
• NPC Long-Term Social Memory: General knowledge and relationships learned over many games. _Keys_: npc:{npcID}:social:{relation|event|topic}. _Retention_: persistent. For instance, if an NPC learns a world event or establishes a friendship with a particular player ID, it may store that fact. These entries are tagged “public” or “social”, indicating they can appear across games. MemoryEndpoints enforces that only non-sensitive, non-game-specific info enters this category.
• Player-Specific Memory: Memories about individual human players (if authenticated or pseudonymous). _Keys_: npc:{npcID}:player:{playerID}:{fact}. _Retention_: persistent if player is known (with user consent), otherwise ephemeral if anonymous. Eg an NPC might remember “Player123 loves blue books” across sessions. But for anonymity, if the player is truly anonymous, we only store a vague “someone once told me…” without linking to a stable ID. This memory is only accessible to the NPC and possibly within that game. (Strict controls: no PII is stored.)
• Anonymous-User Fragment: Minimal, de-identified clues about an unnamed participant within one session (e.g. “a person said X”). _Keys_: npc:{npcID}:anon:{gameID}:{fact}. _Retention_: only for current session. It is used to maintain coherence in conversation without constructing a persistent identity. Never propagated across games or used to identify a person.
• Time/Location Context: Metadata attached to memory (timestamps, room IDs). For example, npc:{npcID}:visited:{roomID}:{timestamp}. Useful for order-of-events or location-specific recall. Such context aids retrieval but also enforces locality. Retain in sync with the related memory; e.g. erase when the memory is purged.

Each memory item is explicitly tagged with its scope, creator (NPC ID), and source game or session. By default, new entries default to the narrowest scope (game or session). Only when memory is explicitly classified as “general” or “persistent” does it survive beyond the session. This tagging ensures that, for instance, game clues never leak to NPC’s global memory and that anonymous remarks do not become persistent attributes.

Retrieval Precedence and Conflict Resolution

When an NPC needs to recall information, it merges multiple layers of memory in order:

1. Current Dialogue Context: The immediate conversational buffer (last few messages) and game state take top priority. This ensures NPC responses are consistent with what was just said or done in the room.
2. Session/Episodic Memory: The NPC retrieves short-term memories from the current game session first (e.g. “I just met you and you mentioned X”). This uses semantic search or recent logs keyed by npc:{npcID}:session:{gameID}.
3. Long-Term Memory: If nothing relevant is found in session memory, query the NPC’s persistent memory store (profile and social memory). For example, vector similarity search may fetch “NPC knew that . . . ” from past games. Only items explicitly marked public or related to this player’s ID are returned.
4. General World Knowledge: Finally, NPC can recall immutable facts or world lore (e.g. “In our world, the Sun is called Helion”). Such knowledge is static and owned by game design (not by any one NPC memory store).

If multiple memories conflict (e.g. two memories about the same topic disagree), resolve them via metadata: use timestamps and confidence. Newer or high-confidence memories override older/less-certain ones. For example, if an NPC once learned a clue but later that clue was disproven, the later update wins. Each memory record carries its creation date and a confidence flag (e.g. confirmed vs. inferred). The NPC should trust facts the player explicitly told it (high confidence) over LLM‐generated conjectures (low confidence). If an ambiguity persists, the NPC should either clarify (“I recall two different stories, can you remind me which one?”) or hedge (“I’m not entirely sure” rather than giving false certainty). This follows best practices: prefer recent data or tagged user-provided facts, and maintain multiple versions if needed (such as “ate meat 2023–present” vs “was vegetarian 2018–2023”).

Additionally, implement controlled memory compaction: periodically summarize or prune old session memories into concise long-term facts, mimicking human forgetting. For instance, several mentions that “I am afraid of spiders” might compress into a single trait. This prevents unbounded growth. However, compaction must be conservative to avoid “over-generalization” errors (never merge distinct anonymous persons’ stories into one). Use domain signals: e.g. if two anonymous players told similar car stories, do not merge them; instead, keep separate event logs. NPC responses should reflect uncertainty (“A person told me this before, though I’m not sure who it was”).

Cloning Command Contract (Memory Transfer)

API: POST /npc-memory/clone Request: { "sourceNpc": "<ID>", "targetNpc": "<ID>", "categories": ["profile","social","knowledge"], "dryRun": true/false }

• Description: Copy selected categories of memory from one NPC to another. Only general (global/social) memory may be cloned; session- or game-specific memories are excluded.
• Parameters:
• sourceNpc, targetNpc: NPC identifiers.
• categories: list of memory scopes to clone, e.g. ["profile","social"]. Allowed scopes are predefined (e.g. profile, social, general-knowledge).
• dryRun: if true, validate and report what would be copied without writing.
• Validation: Source and target NPCs must be different. Only memories marked clonable (e.g. public background facts) are selected. The system checks that no player-specific or game-session entries are in the candidate set.
• Dry-Run Response: Returns a summary of memory items that match each category (without writing). E.g. {"profile": ["hobby:reading","hatcolor:black"], "social": ["met npcX"]}. This preview allows auditing before actual copy.
• Execution: When dryRun=false, the service creates duplicates of each allowed memory item under the target NPC’s ID, prefixed or tagged with provenance (e.g. "clonedFrom": "sourceNpcID", "clonedAt": timestamp). The items in MemoryEndpoints get new keys under npc:targetNpc but preserve the content.
• Provenance/Labels: Every cloned record includes metadata sourceNpcID and timestamp for audit. This ensures provenance tracking.
• Exclusions: Do not copy: player-specific memories, anonymous session fragments, or any data flagged “sensitive” or “game-only”. If such items are encountered, the API must skip them and optionally log a warning.
• Consent Checks: If any memory includes a reference to a human player, require explicit player consent before cloning. If not given, skip or redact those items.
• Audit Logging: All clone commands (even dry-run) are logged with who invoked it, when, what would be copied, and what was actually copied. This log is append-only and reviewable.

This contract ensures cloning is deliberate and transparent. For example, cloning the “profile” category might copy NPC personality tags but never copy “told me secret codeword in Game123” since that is game-scoped.

Examples of Recall Scenarios

• Authenticated Player Recall: Alice logs in as Player123 and previously befriended NPC Anna in GameA. Later in GameB, Anna’s memory store has npc:Anna:player:123:likes_coffee. When Player123 re-enters, Anna can retrieve that fact (via GetMemory(npc:Anna, playerID=123)) and say “Hi Alice! You mentioned you enjoy coffee.” Because Alice is authenticated and memory was marked player-specific, Anna recalls it confidently (with confidence tag).
• Anonymous Player Encounter: Two different anonymous players (no ID) each tell NPC Bob about their red car. Bob’s session memory logs npc:Bob:anon:GameX:"I have a red car". In a later game, an anonymous player asks “Remember my car?” Bob should not assume it’s the same person. Instead Bob might say, “Last time someone mentioned a red car, but I don’t recall who.” This illustrates that without a stable ID, the NPC treats each story independently and expresses uncertainty to avoid a wrong recall.
• Game-Clue Isolation: In a puzzle room, NPC Carla learns a secret code (“The key is under the rug”) as part of gameplay. That clue is stored only in EGFM.gameState:room#42:secret. Carla can use it to guide players during that game session, but Carla’s memory endpoints never store it under her personal memory. After the game ends, Carla’s memory has no record of that clue, preventing it from leaking into future games. If asked later, Carla might politely claim “I don’t remember any such clue.”
• Cross-Game Social Memory: NPC Dan has a long-term friendship with a regular Player456. In GameC, Dan learned Player456’s favorite book. Later in GameD (different game instance), Dan can recall “You like The Alchemist, right?” because that was stored in npc:Dan:player:456 (subject to retention rules). However, Dan will not recall a random hint from GameC’s puzzle. General world knowledge (e.g. “The festival of Light is next month”) can be recounted by Dan in any game, since it’s marked as global lore.

Failure Modes & Mitigations

1. Cross-Game Leak of Game Clues: Failure: NPC inadvertently stores a puzzle solution from Game1 and reveals it in Game2. Mitigation: Strictly enforce that any clue or puzzle-related information remains in EGFM’s game state and is never written to NPC memory. Purge or ignore any memory writes tagged “game-specific.”
2. Identity Confusion (Anonymous vs. Known): Failure: NPC treats two distinct anonymous players as the same person (e.g. conflating their stories). Mitigation: Use ephemeral identifiers for anon sessions and never merge them. If similar facts appear, the NPC should not assume identity; it must respond with ambiguity or request clarification. Tag each anon session’s memories separately to avoid merge.
3. False Controller Attribution: Failure: NPC memory or dialogue leak that a participant is AI or human (e.g. “You play like a bot”). Mitigation: Do not record any “controller type” field in participant records. NPC logic must never use a “human” or “AI” attribute when retrieving memories. Any attempt to infer should be flagged and avoided (treat all players identically).
4. Hallucinated Recall: Failure: The NPC “remembers” an event that never happened (LLM invents it). Mitigation: MemoryEndpoints should only store factual entries (validated by the game). Retrieval should favor stored records and discourage unsourced LLM assumptions. If the model adds content, it must be checked against memory. Use confidence scores to flag low-confidence recollections, and have the NPC hedge uncertain statements.
5. Memory Staleness/Conflict: Failure: NPC holds outdated info (e.g. thinks player still has a pet they gave up). Mitigation: Attach timestamps and lifetimes to memories. Employ temporal-priority resolution: newer facts override old ones. Optionally track history (e.g. “player had a dog from 2020–2023”). Prune or archive expired data.
6. Excessive Memory Growth: Failure: Unbounded NPC memory leads to performance issues or irrelevant details. Mitigation: Summarize repetitive interactions into compact entries (memory compaction) and delete trivial ephemera. For example, convert “player said hello five times” into “player greeted NPC today”. Periodically purge the oldest session memories after game end. This follows human-like forgetting.
7. Embedding/Vector Leakage: Failure: An attacker queries the NPC memory vector store with probing queries and infers private data. Mitigation: Enforce row-level security on vector searches (only memory allowed for that NPC in that game). Do not return raw similarity scores to potentially untrusted parties. Limit retention of sensitive embeddings.
8. Improper Memory Sharing: Failure: NPC memories meant to stay private become globally visible (e.g. a user-specific secret). Mitigation: Default visibility = private/session. Only explicitly flagged memories (by content classification) become shared. Require manual or high-confidence upgrade steps before promoting a memory to global NPC memory.
9. Cloning Breach: Failure: Clone command copies sensitive data (player secrets) from NPC A to NPC B without consent. Mitigation: The clone API explicitly excludes player-specific or game-only data. It must check and skip any memory tied to an individual or flagged sensitive. Auditors should review clone logs to ensure compliance.
10. Player Privacy Violation: Failure: NPC memory stores personal data about a player (even name or preferences) without consent and later reveals it. Mitigation: Avoid storing any PII. If players opt-in to memory, ensure explicit consent and allow opt-out and data deletion. Use pseudonyms or anonymized references for storage. Follow GDPR-like principle: store only “needs to know” info.
11. Ambiguous Multi-Party Conversations: Failure: NPC cannot track who said what when multiple players speak (mixed chat). Mitigation: Tag memory entries with the speaking participant’s session ID. If unidentified speaker, treat it as group statement or ask clarifying questions. In doubt, the NPC should not attribute statements to the wrong person.
12. Retention after Game End: Failure: Session memory accidentally persists after game ends, mixing into next game. Mitigation: Implement an automatic cleanup routine at game termination: delete all gameID:* memories or move allowed bits into NPC long-term only after review. Use database triggers or GC jobs to enforce expiration. Audit logs should confirm purges occurred.

Each of these mitigations applies “privacy-by-design” controls (classification, default-deny, RLS) similar to enterprise agent memory systems. Regular audits and edge-case testing (e.g. two identical stories) will help catch such failures.

Ownership & API Responsibilities

• Escape.GamesFor.Me (EGFM)
• Owns: Game logic, player accounts (auth), game sessions, world geometry, puzzles, and room occupancy. The EGFM server enforces rules (doors, locks, movement) and maintains the “true” state of each game. It is the arbiter of what constitutes a puzzle solution or legal move.
• Memory Responsibilities: EGFM generates memory-worthy events (NPC hears player input, NPC observes player actions). For each such event, EGFM invokes MemoryEndpoints APIs (via its game engine) to store an NPC memory item if allowed by policy. EGFM also supplies context for memory retrieval (e.g. passing relevant memory snippets to the NPC’s LLM prompt). It also issues deletion commands at game end (e.g. DeleteMemory(scope=gameID) in MemoryEndpoints). EGFM validates NPC movement (as noted, NPCs cannot bypass physical locks just because an LLM “knows” a secret).
• API: EGFM calls MemoryEndpoints: AddMemory(npcID, scope, content, [metadata]), GetMemory(npcID, query), CloneMemory(...), and ExpireMemory(gameID). EGFM enforces that any memory related to game puzzles is not sent to memory endpoints (either never calling AddMemory for that, or tagging it ephemeral).

• MemoryEndpoints.com
• Owns: The database and service for NPC memories (by contract, this is the only store of NPC memories). It does not own NPC identities, players, or game state – it only stores whatever EGFM sends.
• Responsibilities: Implement secure, partitioned storage of memory items according to scope tags. Enforce access controls: e.g. only serve npc:npcID memories when requested by that NPC's game session, and never mix data across NPCs or games. Provide memory retrieval (semantic search, filtering by scope) and the clone API as specified. Ensure data retention rules: auto-delete game-session scopes at end-of-game commands. Maintain audit logs of all reads/writes. Use conservative defaults (private scope) and require elevated privilege for shared/global writes.
• API: Expose endpoints (likely REST or RPC):
• POST /memory to create a memory item (payload: npcID, scope, content, timestamp).
• GET /memory to query memories (with filters by npcID, scope, text query or semantic search).
• DELETE /memory to expire memory by key or scope (e.g. game:XYZ:*).
• POST /memory/clone as above.
• The service should return only allowed records (implement RLS or filters such that an NPC can only get its own memories for the current game).
• Privacy: Responsible for encrypting data at rest and in transit, and isolating data between NPCs and games. Must not use memory data for any purpose other than returning it to the caller (no model training from it without consent).

• SpiralistAI.com
• Owns: NPC identity data (canonical first/middle/last names). Possibly an API GetNPCName().
• Responsibilities: Provides NPC names on character creation. It does not store any conversation or memory data, and is not involved in the memory lifecycle beyond initial name assignment.

In summary, EGFM initiates and controls memory events (what is remembered and when to forget), while MemoryEndpoints stores and serves the memories under contract. EGFM enforces the game rules and tells MemoryEndpoints what is in-scope to store. MemoryEndpoints ensures data segregation and retention according to the taxonomy. No company cross-writes into the other’s domain: e.g. MemoryEndpoints does not alter puzzle logic, and EGFM does not persist memories beyond a session. Each API has a clear responsibility to maintain these boundaries and abide by the privacy rules outlined above.

Sources: Modern NPC architectures use hierarchical memories (short-term vs long-term), and privacy-sensitive AI memory systems emphasize “private by default” storage with explicit promotion. These principles guide our design: game-specific data lives only in the game engine, while MemoryEndpoints handles only allowed NPC memory under strict scopes.