Why Claude Kept Forgetting My Homebrew (And What I Did About It)

The Chrome Bishop is an ancient AI. He survived the global cataclysm that birthed magic in my homebrew world, and he wants to erase magic from existence. He cannot cast a spell. He cannot wield arcane power. The entire point of him is that he stands outside magic and views it as a corruption to be eliminated.

A few sessions into my World of Geux campaign, I asked Claude to help me prep a scene involving one of the Chrome Bishop’s lieutenants. Claude gave me a beautiful little encounter: atmospheric, dread-soaked, exactly the tone I wanted. Mid-paragraph, it described the lieutenant channeling the Bishop’s magical power against the party.

The Chrome Bishop is not magical. He is the anti-magic entity. He is an ancient AI from before magic existed in the world, and one of my favorite lines in the campaign’s canonical lore, direct from the Bible, is one of his quotes: “Your magic is a lie that reality tells itself. I am the truth.” His whole function in the campaign is to embody a question I was deliberately keeping open at the table: was magic born of the cataclysm, or did the cataclysm awaken something that was always there?

When Claude described the Bishop casting magic, it didn’t just slip on a small canon detail. It collapsed the central thematic tension of my campaign by treating magic as something the Bishop could just use, a tool among tools, instead of the thing the Bishop exists to destroy.

That was the moment my Notion-plus-MCP setup came crashing down. Not because Claude got a god of war wrong. Because Claude had answered, by accident, a question I was holding open for my players to wrestle with for the next year of play.

This post is about what was actually going wrong with that setup, why my obvious fixes didn’t fix it, and what I eventually had to build. I’ll try to be honest about it, including admitting that I was not using somebody else’s bad TTRPG product. I’d built my own AI stack out of available MCPs and a couple of custom servers I wrote myself. The architecture problem I hit wasn’t downstream of a vendor’s design choices. It was structural.

The setup I was running

For about six months my prep stack was roughly this:

Notion              ~80 pages across the "World of Geux Hub":
                    NPCs Database, Locations, Factions, Lore,
                    Sessions, plus a separate Entity Relationships
                    Database for complex bidirectional links.

Claude Pro          Connected to Notion via the official Notion
                    MCP. System prompt instructed Claude to always
                    pull the World of Geux Bible before answering
                    campaign questions.

Custom MCPs         I'd written a couple of my own MCP servers to
                    fill gaps. None of this was a packaged "AI for
                    D&D" product. I was rolling my own.

I want to name that I never tried a TTRPG AI tool off the shelf. I built my own. Which matters, because the failure modes I hit weren’t downstream of some vendor’s bad design; they were what happens structurally when you try to give a language model access to a wiki-shaped data source. That problem doesn’t go away by switching products. It just changes shape.

The three things that were going wrong

1. The system prompt worked. The in-wiki instructions didn’t.

I had told Claude, in the conversation system prompt, to always read the World of Geux Bible first. It did. Reliably. The Bible’s contents would land at the top of every conversation.

I had also written, inside the Bible itself, this opening line:

This document defines the core identity, rules, and constants of the Geux campaign setting. It should be referenced by any AI or creative working on the campaign, from dialogue generation to stat block design, encounter scripting, and narrative structure.

I had a sub-page called “Database Standards & Enum Reference” that opened with:

This document should be the first context provided to any vector database query.

I had a sub-page called “Tag Usage Guide & Discipline Standards” that gave the literal correct tag set for the Chrome Bishop (Technological, Secret, Political) explicitly NOT Magical, with that exact tagging given as a worked example for the AI to learn from.

None of those instructions reached the model unless the search retrieval happened to return the specific text chunk that contained them. And most of the time it didn’t, because Claude was searching for “Chrome Bishop” and getting back NPC database excerpts ranked by relevance, not my standards pages.

This was the realization that hurt: the system prompt could give the AI instructions and they’d be followed. The wiki could give the AI instructions and they’d be ignored. Because the tools doing the retrieval had more authority than the content the tools returned. The tools were too generic to respect the wiki’s own rules about itself.

I had written a beautiful self-documenting world. The AI couldn’t see most of its rules.

2. The duplicate entity problem

To track relationships properly, I’d built an Entity Relationships Database in addition to the NPC database. The thought was that complex, weighted, sometimes-secret relationships shouldn’t be reduced to a simple link field on the NPC. They should be first-class rows. (Anyone who’s done database modeling knows the pattern: separate junction tables for relationships once they get rich enough.)

So one of the Bishop’s Ascendants, Altus, has a page in the NPCs Database. AND there’s a row in the Entity Relationships Database titled “Altus Member of Chrome Bishop” with its own Description, its own Tags, its own DM Notes. Two separate places where the Altus-Bishop connection is described. Hundreds of relationship rows like that across the campaign.

The AI consistently failed to understand the Entity Relationships Database even existed. When asked about Altus, it found the NPC page and stopped. When the NPC page conflicted with the relationship row, it picked whichever excerpt surfaced first in search. When the relationship row was the only place I’d updated a detail, the AI never saw it.

I’d built proper data modeling (separate tables for entities and relationships, junction-style) and the retrieval pattern just couldn’t handle it. I was modeling like a database and being read like a wiki.

3. When the model can’t find something, it invents

This is the failure mode that produced the Chrome Bishop magic moment. The model couldn’t find a clean canonical answer to “what does the Chrome Bishop’s lieutenant do in this encounter,” so it generated something convincing. In the same confident voice it uses when it DOES know the answer.

A model with no way to distinguish “I have this in canon” from “I am inventing this” treats both the same way. Which means I, the GM, had to manually fact-check every NPC behavior, every motivation claim, every relationship assertion the model produced. The model was generating about 80% useful content and 20% silently-hallucinated canon, and I had to read carefully enough to catch the 20% before it touched my campaign.

That’s not an assistant. That’s a copy-editor’s job dressed up as an assistant.

My escalation, and why it didn’t fix it either

I knew the problem was the retrieval shape. Notion’s MCP was giving the model fuzzy text search over my wiki. The model needed something more structured.

So I installed an open-source knowledge graph MCP server. The kind that stores typed entities with typed edges, queryable as a graph. I started modeling relationships there instead of in the Notion Entity Relationships Database. The graph gave the model a broader, more efficient view of how everything connected: Altus is a Member Of the Chrome Bishop, the Chrome Bishop founded the Mechanist Order, the Mechanist Order Opposes Magic-Wielders, and so on. Walking the graph gave the model real relational understanding instead of search excerpts.

The graph data lived in a local folder on my computer, a directory I’d literally named Claude's Brain. Notion lived in Notion. The two were completely segmented.

It mostly worked. For about a week.

Then the sync drift started. I’d add a new NPC to Notion during prep, forget to mirror it into the knowledge graph, and Claude would still hit the old graph during the next session and tell me a now-dead NPC was alive. Or I’d update a relationship in the knowledge graph, forget to back-fill the Notion page, and end up with two sources of truth that disagreed. The graph let the AI reason better, but it was reasoning over stale data.

The duplicate entity problem hadn’t gone away. It had multiplied. Now there were THREE places an entity might live (NPCs Database, Entity Relationships Database, knowledge graph) and they all had to be kept in sync manually.

Within a few weeks I was spending more time managing the data layer than running the campaign. The whole point of having an AI assistant was to save prep time. I was paying for it back in synchronization overhead, and I still couldn’t trust the output.

The realization

AI forgets your campaign because it’s searching text, not querying structured state. A model that searches text will always have to guess at canon. A model that walks a graph will always be out of sync with the source of truth, unless the graph IS the source of truth. And no general-purpose wiki tool was going to natively treat my campaign canon as a typed graph the AI could query directly.

The fix wasn’t a smarter model. The fix wasn’t a richer wiki. The fix wasn’t a better knowledge graph layered on top. The fix was a single structured source of truth that the AI queries directly, with no shadow copies, no junction tables I had to maintain by hand, no sync drift between wiki and graph.

That meant building it.

A few months after I built it, I sat down and measured what was actually happening. To assemble equivalent working understanding of a campaign, my Notion + MCP setup was burning roughly 50,000 tokens across 30-plus fetches. Grimoire was returning the same coverage in about 6,800 tokens across 5 structured calls. Roughly a 7x ratio, and the tokens carried structured AI guidance the model could act on directly instead of prose it had to interpret.

That number wasn’t an accident. Part of why I built it this way was to fit inside an AI’s free tier limits without burning through the daily message budget. Most of the GMs I know aren’t paying $20/mo for Claude Pro or ChatGPT Plus; they want to use the free tier sustainably for session prep, not get rate-limited out by lunchtime. The bundled-AI tools that assume you’re on a paid plan sit outside what my friends can actually afford. If the structural fix only worked at Pro-tier pricing, it wasn’t really a fix.

And here’s the part that surprised me most about building on MCP: the protocol is client-agnostic by design. Hit Claude’s free-tier limit mid-prep? Close that tab, open ChatGPT, and pick up exactly where you left off. Your campaign canon doesn’t move because the canon doesn’t live in the AI client; it lives in Grimoire, and any MCP-compatible AI can read it. End-to-end free across two free tiers, not just one.

What Grimoire is, and what it isn’t

Grimoire is a campaign manager built around the idea that your world is a structured state machine, not a wiki. Fourteen typed entity types (NPC, Location, Faction, Quest, PlayerCharacter, Creature, LoreEntry, WorldRule, PlanarForce, SessionRecap, SessionPrep, CustomMechanic, Item, Vehicle, plus knowledge graph projections). Each entity has typed fields and explicit relationships to other entities. The relationships are first-class, queryable, and live in the same database as the entities. No junction tables you have to maintain by hand. No second graph to keep in sync.

There’s a Constitution: a set of canonical facts and World Rules that anchors the whole campaign. The AI gets this first, before anything else. If I’d had this for World of Geux, the Chrome Bishop’s anti-magic identity would have been a top-level fact the model couldn’t accidentally violate, because every query would be grounded against it.

There’s an MCP server, so any MCP client (Claude.ai, Claude Desktop, ChatGPT via connector, others) can query the structured state directly. Not fuzzy-search text. Structured queries that return canonical answers.

A few things Grimoire is NOT:

• Not an AI co-DM. The model proposes; you approve. Nothing gets written to your canon until you say so.
• Not AI-required. A lot of GMs use Grimoire as a typed-entity campaign manager and never connect an AI client. The structured-state value holds independently.
• Not 5e-specific. World of Geux runs on heavily homebrewed mechanics. Pathfinder, Call of Cthulhu, Blades in the Dark, any homebrew system: the entity model is system-agnostic.
• Not a VTT. Foundry, Roll20, and Owlbear Rodeo do combat and dice and the live table. Grimoire is the canon-aware layer beneath whichever VTT you use.
• Not a tool that assumes you’re paying for AI. The token efficiency was a deliberate design constraint. Grimoire is built to fit inside free-tier Claude.ai and ChatGPT message and context budgets, because that’s where most GMs actually live.

The honest caveat

This post is a sales pitch, sort of. I built the thing, so I have an interest in telling you the architecture matters.

Here’s what I’d tell you if I weren’t selling it: the canon-drift problem is real, the structural fix is real, and you can engineer it yourself. Obsidian plus careful templates plus a custom MCP server you write can get you 70% of the way there if you’re a developer. Kanka’s entity model gets you halfway and you can graft AI onto it manually. The open-source knowledge graph MCP servers will give you the relationship layer if you’re willing to keep them in sync with your wiki yourself, which is exactly the failure mode I just described, so probably don’t.

What Grimoire does is give you the structural fix without the engineering work and without the sync drift. That’s it. That’s the value prop. If you’d rather build your own version, the architectural idea is free. Go build it.

But if you’ve been frustrated by AI getting your campaign’s biggest, most thematically-important details wrong, and you don’t want to spend three weekends architecting a typed-entity system from scratch, that’s why I built this.

---

The Chrome Bishop is an ancient AI who exists to erase magic from the world. A few sessions in, Claude told me he could cast spells.

A few months later, I had a tool that meant the next Claude conversation would know who the Chrome Bishop is, and so would the conversation after that, and the one after that.

It wasn’t a smarter model. It was a different shape of memory.

---

Try it: grimoire.ttrpg.bot/signup

Read more:

• Why AI keeps forgetting your D&D campaign: the architectural explainer
• Connect Grimoire to Claude or ChatGPT: the MCP setup guide
• AI tools for Dungeon Masters: how Grimoire compares