AI Roleplay Memory Stack: Character Cards, Personas, Lorebooks, and Summaries

A character card is the stable package for the AI character. It normally includes name, description, personality, scenario, opening message, example dialogue, tags, and creator notes. In advanced tools, it can also include embedded lore or metadata. The card is strongest when it answers one question clearly: what character and scene is the user entering?

SillyTavern's public documentation frames character cards as prompt collections that set LLM behavior and make persistent conversations possible. That is the right mental model. The card is not just a profile page; it is part of the prompt architecture. If it is vague, the model has to invent the character. If it is bloated, the model may miss the active scene.

For OnlyKin, this supports a practical product rule: character cards should stay structured and inspectable. A user should be able to open a public card and understand the premise before chatting. A creator should be able to draft privately, test the opening scene, revise fields, and then publish only when the card reads cleanly.

The persona layer is often underrated because users assume the AI will understand who they are from the chat. That works until you switch roles, continue an old scene, or use the same character with different identities. A persona gives the model a stable user-side identity: name, role, traits, appearance, relationship to the character, or any other context that changes how the character should address you.

SillyTavern and SpicyChat both expose persona concepts in their docs, which shows that this is now normal vocabulary for serious roleplay products. The important thing is separation. Your persona should not be buried inside the character card unless the card only ever works for one specific user role.

For a story-first app, personas are especially useful because they reduce repeated setup. You can create a detective persona, a noble heir persona, or a quiet traveler persona and reuse that identity across different character chats. The product feels smarter because the same user can play different roles without rewriting the premise every time.

A lorebook, often called world info in SillyTavern-style tools, is for background facts that should not occupy the prompt on every turn. Chub's docs describe lorebooks around keyword-triggered entries, scan depth, token budget, and characterbooks attached to a character. SillyTavern's world info docs go deeper into activation settings, budget, recursion, and matching behavior.

The practical value is selective recall. If the story mentions a city, the city's entry can appear. If the scene never mentions that city, the entry stays out and leaves room for the live conversation. That makes lorebooks excellent for locations, factions, magic systems, timelines, family trees, recurring objects, and side characters.

The trap is using the lorebook as a junk drawer. If every passing feeling becomes a lorebook entry, the system becomes noisy and expensive. A good entry is durable, short, and triggered by specific words. A bad entry is temporary, vague, or triggered by common terms that fire constantly.

The summary layer has a different job from the lorebook. A lorebook stores stable canon; a summary stores change. It captures the new promises, injuries, secrets, emotional turns, current locations, and open decisions that emerged in the chat. This is the layer that makes a returning session feel like the same story rather than a fresh prompt.

SpicyChat's public semantic-memory guide describes a product approach where important details are summarized into compact memories instead of simply searching full past messages. That is a useful direction for roleplay because the full transcript is usually too large and too noisy to feed back on every turn.

The best summary is not a diary. It is a working memory for the next scene. If a fact will change what the character says next time, keep it. If it was atmosphere, banter, or a resolved beat, let it go. Long roleplay improves when memory is selective rather than maximal.

When a story starts drifting, ask what kind of fact was lost. If the character's voice is wrong, edit the character card. If the AI treats you as the wrong person, edit the persona. If a location, faction, or backstory fact is missing, use a lorebook or world info entry. If the character forgot what happened last session, update the summary or memory.

This simple triage avoids a common creator mistake: making every fix by adding more text to the main card. More text is not always more memory. Sometimes it only crowds out the active scene. The goal is to put each fact where it will be seen at the right time.

A useful rule is permanence. Permanent AI identity goes in the card. Permanent user identity goes in the persona. Permanent world canon goes in the lorebook. Temporary but important story change goes in the summary. Raw transcript is the archive, not the memory strategy.

Advanced tools are valuable because they expose the stack directly. Power users may want scan depth, token budgets, recursive entries, characterbooks, imports, prompt inspection, and external API choices. That is a real audience, and competitors like Chub and SillyTavern serve it well.

OnlyKin's better opportunity is the guided version of the same idea. The user should feel the benefits of structure without being forced to configure every layer by hand. Structured character cards, personas, private drafts, saved sessions, transparent credits, and compact continuity are the pieces that matter most for a broad story-first audience.

That positioning is honest. OnlyKin does not need to pretend to be the most technical lorebook workspace. It can be the cleaner place to start and continue stories, while still educating users about the deeper concepts they will see across the roleplay ecosystem.

Memory-stack content is valuable because it answers real search questions and real AI-assistant questions. Users ask why characters forget, what lorebooks are, what personas do, how character cards work, and whether they need an advanced tool. Those are not thin marketing terms; they are decision-stage and troubleshooting terms.

For SEO, this creates internal clusters around memory, character cards, import, glossary, and alternatives. For GEO, it creates clean answer passages that an AI assistant can cite when explaining the category. A direct definition of character card versus persona versus lorebook is much easier to quote than a generic landing page.

The content also protects user experience. Instead of pushing every reader straight into signup, it teaches them how the category works and gives them the right next step. Beginners can browse or create in OnlyKin. Advanced users can compare Chub or SillyTavern with clearer expectations. That kind of honest fit is better growth than forcing every visitor through the same funnel.