Building an AI Dungeon Master With Real Memory

This post walks through three techniques I used to give an AI Dungeon Master real memory: tiered storage across a NoSQL event log, a vector database, and a knowledge graph; narrative hierarchies that break story goals into smaller pieces; and proactive retrieval that pulls in the right context before the AI needs it, instead of waiting to be asked.

At the start of the year, I started developing an agentic Dungeon and Dragons (DnD) game called Archon. It was conceptualized to be a sort of “true sandbox” text-based game, and also an exercise for myself to get more familiar with various agentic patterns I had limited experience with, like A2A, complex memory systems, and proactive rather than reactive context retrieval. I figured I’d share a few of the patterns and systems I implemented, partly to spark someone else to go build something, and partly for anyone curious to read about an implementation that’s a little more on the fun side.

Here’s the shape of the memory system before I get into the details:

• Tier 1 (NoSQL events): a ground-truth log of everything that happens in the game engine
• Tier 2 (vector database, Qdrant): semantic search over past dialogue and scene text
• Tier 3 (knowledge graph): nodes and edges for characters, factions, locations, and how they relate to each other

The Continuity Problem: Why LLMs Forget Their Own Story

No one wants to play DnD with a Dungeon Master (DM) who can’t remember what plot points they introduced 15 minutes earlier.  Sparing a particularly forgetful DM, this was typically going to be the most prevalent fail mode of the game.  DnD is all about storytelling, having satisfying arcs, and character development, all of which is lost as soon as the context window goes away for an LLM.  This led me to implement a three-tiered memory system to back the proactive recall that I’ll talk about later.

Structuring the Story: Narrative and Time Hierarchies

Goal Hierarchy: Arcs, Milestones, Quests, and Threads

Before talking about the solution to continuity, I feel it is important to first mention the narrative hierarchies implemented.  Similar to how we use epics, stories, and tasks to decompose larger units into smaller units for software development, the game treats narratives as decomposable hierarchies on two fronts, goals and time.  The first hierarchy is that surrounding something your character or party is setting out to do, decomposing from the top level arc into milestones into quests into threads. 

An arc is something that is highly significant to a campaign, and a typical singular campaign may consist of 2-5 arcs, each working towards the overall goal of the campaign (defeat the big bad, save a city, etc.).  Each arc decomposes into milestones, which are major turning points for the arc, like defeating an important enemy, uncovering a twist or plot, etc. 

Milestones decompose into quests, which are bite-sized units of goals, like steal this thing or investigate this place.  Threads are the lowest form of the narrative hierarchy which represent various (usually incomplete) information that presents some way to approach completing a quest (since the game is designed to be sandbox in nature, it doesn’t necessarily require you to complete a quest in a certain way).

Time Hierarchy: Acts, Scenes, and Exchanges

The less important hierarchy is how we constitute the actual time flow.  Acts are made up of 3-5 scenes, and scenes are made up of some amount of exchanges.  Scenes consist of dialogue and combats that occur in a single relative location (one scene may be talking in a tavern, or it may be street chase).  Each exchange is a round of human → llm → response.

All of this hierarchical representation allows the game to represent fairly abstract things like “goals” and “time” into (relatively) easy to work with data models that make retrieval easier to orchestrate.

Tier 1: A NoSQL Event Log for Ground-Truth Game State

This tier of the memory system is closest to what a typical game’s database would be.  Every dice roll, dialogue exchange, scene text, attack swing, damage applied, etc. is emitted as events to maintain a ground truth of “what happened” inside the game engine itself.  This is important because continuity doesn’t only fall apart at the narrative level, but it can just as easily fall apart at the game state level.  Capturing every event that interacts with the game engine ensures that game state is accurately preserved, and also funnels downstream to the more narrative continuity enablers.

Tier 2: Semantic Search With a Qdrant Vector Database

Traditional NoSQL or SQL databases are great for the much more structured data that they are meant to capture, but if a DM needs information like “how did the player character treat this character last time they talked” or “did the king mention the bandits for this quest”, semantic querying over structured databases is non-trivial.  This led to implementing a vector database, Qdrant (OSS, highly recommend for any personal projects), to house the embedded and vectorized text that would be able to answer these types of questions. 

Every scene dialogue (consisting of all player responses and LLM responses) is embedded, vectorized, and then stored in Qdrant for retrieval.  The top-level DM agent has access to a query_memory tool that can take semantic search targets and kick off a memory agent that interfaces with our memory stores.  This memory agent will perform various semantic searches over Qdrant to find the information for the DM, then return a structured Memory Packet to the DM for easy consumption.

Tier 3: A Knowledge Graph for Characters, Factions, and Locations

Fundamentally, almost all (if not all) information about a DnD game can be represented as a graph structure, which is a data structure that consists of nodes and edges.  It is a relationship-driven data structure commonly used for things like recommendation systems or fraud detection, but fits perfectly for modeling the topology of a fantasy world that is narrative driven.  Nodes in our case can represent anything like characters, factions, locations, information (like secrets), or quests. 

Edges can represent pure factual relationships between nodes, such as tavern ⤚ located in → city, or narrative devices, like NPC ⤚ distrusts → player.

Within each node, information can be stored depending on node type.  A character node type can include things like bonds, flaws, backstory, race, and class, or an information node type can include things like known to player, confidence level (NPCs may lie!), or saliency (recency in our case).  Additionally, edges can hold information similarly to nodes.  Following the population of the vector database, an agent takes the scene text and updates the graph database by adding new nodes and edges, updating existing nodes and edges, or reconciling nodes/edges (in the case where an unnamed hooded man turns out to be a previously named character, the agent will do a deduplication and merge these two nodes, maintaining an “alias node” for the merged node). 

This data representation allows us to answer even more important questions for the narrative, like “does this character trust the player?” (by querying the edge between the character→player) or “where is this key location located?” (by fetching all edges from the key location to any other location node).

Proactive vs. Reactive Retrieval: Fetching Memory Before You Need It

Most current agentic or LLM systems operate primarily on reactive retrieval, meaning a user query comes in or the agent is working on a task, and an LLM decides that it does not know that answer and queries some memory source.  This works well for chatbots or automated workflows where the information needed is a matter of fact or well defined, but this translates poorly to something that is essentially being made up as the LLM goes (to some extent, creating arcs, milestones, and quests ahead of time helps this). 

When the agent DM goes into a new scene, it doesn’t have all the information about the narrative, but the most important thing is it does not know what it does not know.  In my evaluations, this was particularly degrading to long-term continuity, as something from 6 scenes ago could have narrative prevalence to the current scene, but since the DM is a storyteller, it often figured the best thing to do in the moment was to create new narratives (even if they conflicted with old ones).  This led to implementing systems I coined “proactive” retrieval (there is some research on pre-fetch RAG, but I haven’t found much literature on this exact pattern). 

The idea behind proactive retrieval is to find all the potentially important narrative elements for a given scene, fetch those, and inject all of that before an LLM can ever narrate a scene.  These things can include characters that should probably be in this scene along with their character doc (they came with you from the last scene, you’re waiting in someone’s office, etc), important information about the current thread, quest, or milestone that the player is currently pursuing, along with some pregenerated goals of the scene.

What Building an AI Dungeon Master Taught Me About Agent Memory

Combining all of these systems overall led to a continuity-rich experience in my plays.  I have been able to achieve 20+ hours of campaign time across a couple different campaigns where the worst continuity breaks were minor.  Developing this was an interesting experience, as it tested the bounds of RAG in ways I had not seen in typical enterprise systems, since this system focused much more on the memory aspect rather than the tooling/harness that most enterprise agentic solutions live or die on.

If you’re interested in chatting more about it, maybe trying it out, or want to see any of the code, let me know!  Always happy to talk about topics like this with anyone.

✨ AI Post Recap