Anyone who has experimented with commercial AI chatbots to write multi-chapter fiction has observed the exact same failure pattern: Chapter 1 is charming, Chapter 2 is coherent, Chapter 3 begins to loosen, and by Chapter 4 or 5 the entire story descends into amnesia, personality inversion, and glaring plot contradictions.
1. The Three Naive Approaches in Modern Consumer Apps
A. The Sliding Window (Rolling Context)
The simplest method used by generic wrappers is the sliding window. When generating Chapter 4, the developer takes the last 4,000 tokens of Chapter 3 and passes them into the prompt.
Why it fails: The model has literally zero memory of Chapter 1 or 2. If the protagonist broke their arm in Chapter 1, or discovered a secret talisman in Chapter 2, that information no longer exists in the transformer's active attention window. The character will draw a two-handed bow in Chapter 4 as if their arm was never shattered.
B. Pure Vector RAG (Semantic Search)
Many developers attempt to solve this by dumping past chapters into a vector database (e.g. Pinecone, Chroma) and using cosine similarity to retrieve relevant paragraphs.
Why it fails for fiction: Vector databases match semantic similarity, not temporal causality. If Chapter 4 asks for scenes involving "Gerald in the tavern", vector search retrieves paragraphs from Chapter 1 where Gerald was drinking happily—completely oblivious to the fact that Gerald was betrayed and imprisoned in Chapter 3. Injecting out-of-order historical paragraphs hallucinates massive plot retcons.
C. Recursive Rolling Summaries (The Telephone Game)
In this approach, Chapter 1 is summarized. Then Chapter 2 is appended and summarized together. By Chapter 7, the summary has undergone five recursive abstraction passes.
Why it fails: LLM summarizers ruthlessly discard minor sensory details, side-character names, and subtle foreshadowing to hit target word counts. Crucial setup details disappear, leaving the AI with a dry, hollow skeleton.
2. The MythMaker Solution: Event-Sourced Dynamic State Engine
To conquer this, MythMaker separates World Truth from LLM Prose. The LLM is never the canonical database.
- Narrative Database as Truth: Character inventories, physical injuries, emotional states, and location coordinates reside in a dedicated relational schema.
- Sparse Entity Snapshots: Every time a character's state changes in a
NarrativeUnit, a sparse snapshot is committed. If Bob is wounded in Chapter 2, that state remains active until an explicit mutation occurs. - Deterministic Prompt Assembler: When writing Chapter 5, the prompt compiler retrieves only the latest active states of characters involved in that specific beat—guaranteeing 100% temporal continuity without token overflow.
We celebrate and credit systems like Novelcrafter's Codex and HoloAI for exploring structured character bibles. MythMaker takes this forward by creating a fully automated, event-driven state machine that updates itself chapter by chapter.