Storyteller Bots: AI Narration With Memory and Action Signals

Updated July 2026
A storyteller bot is an immersive narrator that treats your knowledge base as canonical story lore, tracks each player's personal journey with long-term memories, and signals story events to your game through an action field. It is the bot type behind AI text adventures, narrative layers on top of existing games, and living-world NPC storytelling. This guide covers how storytellers use lore, how per-player memory works, and how to build a game UI around the action signals from the chat API.

Narration Grounded in Your Lore

The defining difference between a storyteller bot and a raw LLM chat is where the world comes from. A raw model invents freely, which reads impressively for five minutes and then contradicts itself, your setting, and last session's events. A storyteller bot retrieves from your knowledge base on every prompt and treats what it finds as canon. The geography, the factions, the history, the tone, all come from content you wrote and can edit.

This changes how you author a game world. Instead of programming every scene, you write lore documents: places, characters, events, rules of the world. The storyteller improvises scenes inside that canon. Adding a region to your world is writing a few paragraphs and pushing them to the knowledge base, no new dialogue trees, no new scripting.

The bot's rules, set in the admin area, control the narration itself: perspective, tone, pacing, how much the narrator describes versus asks, and the boundaries it must not cross. The rules are the director, the knowledge base is the script bible, and the player provides the plot.

Per-Player Memory Across Sessions

Pass a userKnowledgeBase tag with each player's requests and the storyteller gains long-term memory for that player. After each response, the bot saves key facts, decisions made, characters met, items gained, grudges earned, under that tag, and recalls the relevant ones in later sessions. The player who spared the bandit leader in week one gets recognized by him in week four, without your game storing or replaying any of it.

The tag is yours to define, typically a player account ID. Use one tag per player per world: if the same player runs two separate campaigns, give each campaign its own tag so the memories do not bleed between stories. You can also write memories directly through the memory/add endpoint when your game wants to record something specific, a quest completion from regular game code, for example.

Alongside player memories, the conversation itself self-manages. Each reply includes distilled bullet summaries used as compact history, and when a long conversation drifts, the model can trigger a cleanup that collapses it down to its important facts, signaled by the cleanup action. Long sessions stay coherent and your token costs stay flat instead of growing with every message.

The Action Signals

Every response carries an action field so your UI can react to story structure without parsing prose:

ActionWhen it firesWhat games do with it
choiceThe player faces a real decision point.Show a choice overlay, pause ambient timers, highlight the input box.
chapterA scene or chapter break.Chapter title card, autosave, music transition.
encounterSomeone or something important appeared.Character portrait, combat mode, sound cue.
cleanupConversation history was compacted.Nothing player-facing, useful for logging.

The pattern that works: render message as narration, then switch on action for presentation. Even a minimal text adventure feels dramatically more like a game when chapters get title cards and encounters get portraits, and the signals cost you one switch statement.

Shaping a Session

Open with context, not a blank page. Send the player's name in userInfo so the narrator can use it, and consider making your game's first message set the scene: "Begin the story at the gates of Veldharrow at dusk" gives the storyteller a launch point consistent with your lore.

Use passedRules for temporary state. The per-request rules string is the clean way to inject the current situation from your game code: "the player is wounded and cannot fight", "it is the festival of lanterns tonight". The bot honors it for that request without permanently changing the bot's rules.

Watch billing during development. Each response reports rough token usage. A session that costs more than you expect usually means your knowledge chunks are longer than they need to be or your bot rules have grown bloated. Our latency and cost guide covers the budgeting mindset.

Prototype in the demo page first. The built-in demo chat is the fastest place to tune narrator voice and test how your lore retrieves. Iterate there, then wire the game UI once the storytelling already feels right, the getting started guide shows the loop.

Assistant Bots: The Quiet Sibling

The assistant type shares the storyteller's grounding but none of its theatrics: it answers questions strictly from the knowledge base, making it right for an in-game help NPC, a tutorial guide, or an FAQ character. It signals angry when the user sounds frustrated, which your game can use to escalate to different help. If you find yourself fighting a storyteller to stop narrating and just answer, you wanted an assistant.

Key Takeaway

A storyteller bot narrates inside a canon you author: lore from the knowledge base, per-player history through memory tags, and story structure surfaced as choice, chapter, and encounter signals your UI can stage. Write the world as documents, let the bot improvise the scenes, and key your presentation off actions rather than prose.