AI Character Backstory, Memory, and Lorebooks: What Each One Does
Backstory, memory, and lorebooks each do a different job in AI character design. Learn what belongs where and why longer instructions are not always better.
Maya Chen
AI Research Writer
By the Kissable Team
If you've spent time building an AI companion or roleplay character, you've probably run into all three: a backstory field where you describe who the character is, a memory layer that grows from your conversations, and a lorebook (sometimes called a world info or knowledge base) that holds facts the character can reference when they become relevant. They sound like variations on the same thing. They aren't.
These are useful information roles, but apps implement and name them differently. Some combine them, let you edit all three, or load their contents in different ways. Treat the distinctions below as a design guide, then check the controls your app actually provides.
The short version: backstory defines the character, memory records what happened between you, and a lorebook organizes reference facts for a world, setting, or character. The rest of this article explains each one, shows you where different types of content belong, and covers a few things that trip up even experienced users.
The Three Layers at a Glance
Before getting into each one individually, here is how they compare across the dimensions that actually matter for building a consistent character.
| Layer | What it defines | When it's active | Who writes it | Grows over time? |
|---|---|---|---|---|
| Backstory | Character identity, style, and established history | Often part of standing character context; varies by app | Creator, user, or app | May be edited or updated |
| Memory | Shared history and learned facts | Recent context, summaries, or retrieved facts | App and/or user, depending on controls | Can grow or change |
| Lorebook | Organized world and character reference | Keywords, relevance retrieval, fixed inclusion, or other rules | Creator, user, or automated tooling | Depends on the app |
The activation column is implementation-dependent. Stored information and information available to the next response are different things. Check whether the app documents character-context limits, retrieval rules, or entry controls rather than assuming an item is always active.
Backstory: The Character’s Starting Definition
A backstory establishes who the fictional character is: name, history, communication style, and traits. It can provide a stable starting point without making the character incapable of development. A past event stays in the history; a current job or relationship may change as a story develops.
What belongs in a backstory
- Core personality traits and communication style ("speaks with dry wit, rarely gives direct compliments")
- Established biographical facts (name, age, profession, origin, defining past events)
- Relationship type and dynamic ("a longtime friend, warm but willing to disagree")
- Hard rules about behavior ("uses a formal voice in the historical setting")
- Physical description if appearance needs to inform how the character describes themselves
World details that matter only in certain scenes may fit a lorebook. A preference learned during conversation may fit memory or a dedicated user-profile field. Those are starting points, not rigid rules: use the app’s supported controls and keep changing facts current.
Memory: Shared History
Memory is the layer that grows. Memory may include conversation history, summaries, extracted facts, or user-maintained notes. An app may use several of these. Check what persists and what can be corrected rather than assuming everything is automatically stored.
MemGPT describes managing different memory tiers around a limited context window. Generative Agents combines memory, reflection, and planning in a simulated environment. Both provide related design ideas; neither establishes Kissable’s recall or the right location for every field in a consumer app.
Names, preferences, shared events, and corrections are all useful candidates. Keep their origin clear: a fictional character’s backstory and a real user’s preference are different kinds of information.
What memory does not guarantee
A stored fact may be omitted from the next response, and a retrieved fact may still be misused. Selection can involve deterministic rules, model-based decisions, or a combination. Placing a critical detail in a supported standing-instruction field can make its intended role clearer, but no field guarantees perfect compliance.
For a deeper look at how AI companions handle long-term recall, see Can AI Girlfriends Remember Conversations?
Lorebook: Conditional World Reference
A lorebook organizes information about a fictional world or cast. Some implementations use keywords to select entries; others use relevance search, fixed entries, or a mixture. The term alone does not tell you when an entry reaches the model.
Conditional loading can help keep a detailed city history out of unrelated scenes. It also introduces questions to check: did the entry activate, was it included within the available budget, and did the answer use it correctly?
World rules, geography, factions, supporting characters, and scenario-specific terminology can fit here. Keep central character instructions consistent with those entries, and check activation rules before relying on a conditional entry for something essential.
For a practical guide to building lorebook entries from scratch, see The Complete AI Lorebook Guide. If you are designing NPCs for a roleplay scenario, How to Create NPCs for AI Roleplay covers how to structure individual character entries.
Where to Put a Specific Piece of Information
The sorting question comes up constantly. Here is a practical reference for common types of content.
| Content type | Suggested starting point | Why |
|---|---|---|
| Character's name and age | Backstory | Part of the starting identity |
| Character's personality traits | Backstory | Defines intended behavior |
| Hard behavioral rules | Backstory | Clarifies intended constraints; activation still varies |
| Your name, job, city | Memory | Learned from conversation |
| Your relationship milestones | Memory | Grows over time |
| Your emotional preferences | Memory | Emerges through interaction |
| A fictional kingdom's history | Lorebook | Only relevant in specific scenes |
| An NPC's personality | Lorebook | Relevant when that NPC appears |
| A magic system's rules | Lorebook | Contextual, not always needed |
| A recurring inside joke | Memory or Backstory | If critical, backstory; if earned, memory |
For the inside joke, decide whether it is an established part of the setup or something that developed during play. The important distinction is its origin and intended use, not a claim that only one storage location can work.
A note on conflicting instructions
Consider a hypothetical scenario: a backstory says the character is "reserved and slow to trust," but a lorebook entry for a specific scene says they are "warm and immediately friendly." When both are active at the same time, the model has to resolve the conflict somehow. The result may be inconsistent, and the outcome depends on the app’s instruction ordering, conflict rules, and model behavior. The fix is to keep each layer internally consistent and to avoid placing contradictory personality instructions across layers for the same character.
Longer Is Not Automatically Better
Longer instructions can add useful detail, but they can also add contradictions and irrelevant material. Within a limited context budget, extra reference text may reduce room for other information. The outcome depends on how the app selects and truncates context.
Write concrete behavior instead of abstract praise. “Deflects awkward questions with humor, but becomes direct when worried” gives you something to observe. “Has a very complex personality” is harder to evaluate. When an instruction is ignored, check its clarity, activation, and conflicts before simply adding more text.
How to Apply the Distinction in Kissable
Kissable provides customizable fictional companions, persistent conversation context, and Adventures. These map broadly to character definition, shared history, and structured story material. That does not mean the app exposes three interchangeable editors or implements every lorebook convention described above.
Use the character controls available in your current version to establish the personality. Treat a correction to something you told the companion as a memory question. Treat rules and supporting characters for an Adventure as story material. Verify the actual fields and behavior rather than assuming a keyword trigger or an always-present prompt.
If you need a starting point for the character, AI girlfriend personality ideas can help you describe a style concretely. Persistent context supports continuity, but “saved” should never be read as a guarantee of complete or permanent recall.
Frequently Asked Questions
Can I put user preferences in the backstory instead of relying on memory?
Yes, and sometimes it makes sense. If there is a preference so central to the interaction that you want it active from the very first message ("always calls me by my nickname, never my full name"), a supported character or instruction field may be a useful place to state it. That does not guarantee that every response will comply. The trade-off is that you must keep the instruction current and within the app’s limits. Preferences that should feel earned or that may evolve over time are better left to memory.
Why does my character sometimes ignore something I told it?
It could be missing, omitted from the selected context, contradicted by another instruction, or misused during generation. A response alone does not reveal the cause. Check the relevant controls, ask a clear question, and keep an example if the problem repeats.
Do lorebook entries conflict with the backstory?
They can, particularly when two entries describe the same character in incompatible ways. A lorebook entry that assigns a personality to the main character that contradicts the backstory will create inconsistency when both are active. Lorebook entries work best for world and NPC facts, not for redefining the main character's identity in specific scenes.
Is a longer backstory always more detailed?
Not in terms of behavior. A long backstory that uses vague language ("is very complex and has many layers") gives the model less to work with than a short one that is specific ("deflects emotional questions with humor, but becomes direct when genuinely worried"). Specificity matters more than length.
What is the difference between a lorebook and a system prompt?
A system prompt is an instruction channel controlled by the application. A lorebook is a content organization feature whose entries may be included in several ways. Activation and instruction priority are separate issues, so “system prompt” is not simply another name for an always-on backstory.
Understanding which layer handles which job is the foundation of building a character that behaves the way you intend. Backstory defines the character. Memory records your shared history. Lorebooks hold the world. Each one has a distinct job, and the best results come from using each for what it is actually designed to do.
Start building your companion on Kissable
AI Research Writer
Maya covers AI companion technology, safety, and the psychology behind human-AI relationships. She focuses on what the research actually says — and what it doesn’t.