The problem
Long-form AI play hits a consistency wall. A GM that has to remember 30 sessions of a campaign (character details, plot threads, world rules, NPC personalities) runs into the limits of the underlying AI models. Details slip. Threads drop mid-arc. NPCs feel different scene-to-scene. Solving this is the central design challenge of building an AI GM that lasts.
Every system that wants to solve consistency faces the same dilemma: how do you store your campaign's information, and how does the GM read it back? There's no single correct answer, but the choice you make shapes everything else in the system. Two ends of the spectrum exist, both with real costs:
- Structured data. Store it with a fixed data form: characters, items, NPCs, and locations all become records in a database that follows a strict schema. This data is predictable, easy to display, but your campaign is whatever those forms allow; your imagination has to fit the data model.
- Unstructured data. Free-form prose documents the GM reads. Complete creative freedom, but prone to long chaotic documents that are hard to organize, search, or load efficiently, and the screen has nothing reliable to display from.
The Arcanum System
Our answer rests on three axes:
Axis 1. Hybrid data with light conventions
We use a small bit of fully structured data where the screen has to display things: vitals, HP, conditions, position. However, the majority of our data technically fits into the "unstructured" category but with a little extra: a few tiny formatting conventions and lightweight markers that help the GM navigate and process the data efficiently. Minimal enough to never impose a form on you.
Our engine — Claude Code — is highly effective at navigating and working with these markers. It has built-in tools engineered for this type of task.
Axis 2. Memory architecture
This is how the GM holds the campaign's context across long play without drowning in every word of it. The light conventions from Axis 1 let the GM selectively load the parts of your data that matter for what's happening now. A set of core documents are always-loaded, others are partially loaded or indexed, others are loaded dynamically when relevant, and the rest stays on disk as long-term memory.
Gameplay is handled as discrete sessions; each one operates as a self-contained unit with the selectively loaded data kept as working context. Data compression and synthesis happen at session boundaries, shaping what becomes part of your campaign's official history.
Within a session, the GM's working set stays loaded across every turn rather than getting rebuilt from scratch each message. We lean on prompt caching, where stored content can be re-read at a fraction of the cost of fresh content.
Axis 3. Engine and architecture
We use a smart frontier model as the GM that drives the show: Claude Sonnet 4.6 at the time of writing, with a 200k token context window. Smaller, cheaper models assist on mechanical or simple tasks so the main GM stays focused on narration.
We have a robust array of background scripts that catch various patterns in the GM's responses. When a hit is registered in the GM's narration, a script picks it up and updates your character panel, so routine bookkeeping happens automatically.
Our scripts also detect anti-patterns, so if the GM ever slips up and delivers a malformed response, it gets automatically intercepted and sent back for a re-do before any corrupted data can propagate. This case is extremely rare; the patterns are very natural and simple to follow for the GM, but we keep it as a safety net.
left: markdown file open showing world-info paragraph mid-edit
right: running session, GM weaving the same content into the scene
label: "no schema, no migration, no form to fill out — just read"