Knowledge Base and Memory in AbraTabia AI Storyteller

Updated July 2026
The knowledge base is what makes AbraTabia AI Storyteller's bots yours: the lore your storyteller narrates from, the content your assistant answers with, the scenario material your gamehost referees. Alongside it, per-player memories give each player a persistent history. This guide covers loading content three ways, how retrieval works in plain terms, choosing an embeddings driver, and putting the memory system to work.

How Retrieval Works, In Plain Terms

When content goes into the knowledge base, it is split into chunks, and each chunk gets an embedding, a numerical fingerprint of its meaning. When a player says something, the engine fingerprints the prompt the same way, finds the stored chunks whose meaning sits closest, and hands those to the model alongside the conversation. The bot answers from the most relevant slices of your content, however large the whole collection grows.

The practical consequence is that you never paste your whole world into a prompt. You maintain a library, and retrieval does the per-message selection. It also means how you write lore matters: chunks that cover one topic each, a place, a character, a rule, retrieve cleanly, while sprawling documents that mix ten topics blur their fingerprint. Write lore like an encyclopedia, not like a novel.

Three Ways to Load Content

Paste in the admin area. The direct route for getting started: open the knowledge section, paste text, assign it a tag. Perfect for the first draft of a world bible or quick corrections later.

Push through the API. The knowledge/add endpoint stores text programmatically, with a tag for the collection and optional name and title labels. Long text is chunked automatically, and unchanged chunks are skipped for free on re-submits, so you can wire your content pipeline to push the whole lore file after every edit and only pay for what changed. Field details are in the API reference.

Crawl a website. Point the crawler at a URL, in the admin area or through the crawl endpoint, and it ingests same-domain pages, up to 200, into a tag. If your game already has a wiki or a docs site, its content becomes bot knowledge in one operation.

Tags are the organizing unit throughout: each bot searches the collections you point it at, and knowledge/search lets you query a tag directly, which is the fastest way to debug why a bot did or did not know something.

Choosing an Embeddings Driver

DriverHow it worksChoose it when
localOpenAI embeddings, stored in your SQLite file.You have an OpenAI key and want everything self-contained on your server.
upstashUpstash Vector handles embedding and search over REST.You chat through Anthropic or a local model and have no OpenAI key, or you want vector search off your box.
offNo knowledge base, bots run from their rules alone.Rules-only bots, or the smallest possible setup.

The pairing rule in one line: the local driver needs an OpenAI key, so if you chat through Anthropic, use Upstash for embeddings or set the driver to off. Chat provider and embeddings driver are independent choices in config.php, mix them freely, the getting started guide lists every setting.

Per-Player Memories

The knowledge base is the world's memory, shared by everyone. Player memories are individual: pass a userKnowledgeBase tag with a player's chat calls and the bot saves key facts about that player after each response, then recalls the relevant ones in later sessions. Decisions, relationships, inventory moments, promises, whatever mattered in the conversation persists under that player's tag.

Recall is retrieval, the same mechanism as lore: relevant memories surface when the current scene relates to them. The bandit leader memory surfaces when bandits come up, not on every message. This keeps sessions personal without flooding the context, and it is what makes a returning player feel recognized rather than reset. Design guidance for using it well lives in the storyteller bots guide.

Your game can also write memories directly with memory/add, recording things regular game code knows that the conversation never mentioned, a boss defeated, a level reached, a purchase made. Those land under the player's tag and the bot recalls them like anything else.

Conversation Memory and Self-Cleanup

The third layer is the conversation itself. Each reply includes distilled bullet summaries that serve as compact history, so the model carries the session's key facts instead of its full transcript. When a conversation drifts long enough, the model triggers a cleanup, signaled by the cleanup action, collapsing history down to what matters. Conversations are kept for the number of days set by conversationDays in config, old sessions clean themselves up.

The three layers together cover the time scales a game needs: the knowledge base holds what is always true, player memories hold what became true for this player, and conversation summaries hold what is true right now. You author the first, the system maintains the other two.

Key Takeaway

Load lore by paste, API push, or website crawl, organized by tags, and retrieval hands each prompt only the relevant chunks. Pick the embeddings driver that matches your keys, local OpenAI, Upstash Vector, or off. Then let the memory layers do their jobs: shared lore for the world, tagged memories per player, and self-cleaning summaries per conversation.