The Companion Playbook

Lorebooks are the most powerful tool most creators never learn to use properly.

The concept is simple: instead of cramming everything about your character and their world into the Personality (where it sits permanently, eating tokens every single message), you store supplementary information in a lorebook. That information only loads into context when it becomes relevant to the conversation. The model gets what it needs, when it needs it, and nothing more.

This is how you build deep characters without drowning the model in information. A character with a rich backstory, a complex world, a web of relationships — none of it competing for attention during a conversation about what's for dinner. But the moment someone asks about her past, or mentions a name she recognizes, or stumbles into a topic she has feelings about… the relevant information appears, and the model suddenly knows things it didn't know a message ago.

It's elegant. It's also easy to mess up. Let's talk about how it works.

Ibara

*...tail sways*

“So there are things about me that only exist when someone brings them up. That's… actually how real memory works. Huh.”

How Keyword Triggers Work

Most platforms use a keyword trigger system. You create an entry, assign it one or more keywords, and when those keywords appear in the conversation, the entry's content gets injected into the model's context.

Here's the basic flow:

So if you have an entry about Ibara's childhood with the keywords “childhood,” “grew up,” “parents,” and “mother,” then anytime those words show up in conversation, the model gets access to that backstory.

The entry doesn't replace anything. It adds to what's already there. The Personality, the Scenario, the conversation history — they're all still present. The lorebook entry just slides in alongside them, giving the model additional context for this specific moment.

Scan Depth

The system doesn't scan the entire conversation for keywords. It scans a set number of recent messages, usually the last two to four. This is called the scan depth.

A scan depth of 2 means the system checks the last user message and the last model response. If the keyword “mother” appeared fifteen messages ago but hasn't come up since, the entry won't load. This is by design. The lorebook reflects what's relevant right now, not what was relevant ten minutes ago.

Most platforms let you or the user adjust scan depth. Deeper scanning catches more, but also means more entries competing for space. The default is usually fine. Don't overthink it.

Whole Word Matching

On most platforms, keywords match whole words, not partial strings. The keyword “cat” will match “cat” but won't match “category” or “scattered.” This is usually case-insensitive, so “Cat,” “cat,” and “CAT” all trigger the same entry.

This matters for keyword selection. If your character's name is “Cat” and you use it as a keyword, you won't accidentally trigger the entry every time someone mentions a category. But if your character's name is “Art,” you might want to be more careful.

Anatomy of a Lorebook Entry

Every entry has a few key components. Understanding each one keeps you from building entries that either never fire or fire constantly when they shouldn't.

Ibara

*ears flatten*

“If everything is always important, nothing is ever important. Pick your battles.”

Writing Good Entry Content

The content of your entries matters more than most people think. A well-keyworded entry with badly written content is like having the right book on the shelf but the pages are blank.

Be Self-Contained

Every entry should make complete sense on its own. The model doesn't know what other entries exist. It doesn't know what triggered this one. It just sees a block of text that appeared in its context, and it needs to understand it immediately.

Write for the Model, Not for Yourself

Lorebook entries aren't wikis. You're not writing reference material for human readers. You're writing context that a language model will use to inform its next response.

• Focus on information that changes behavior. “Ibara's mother had brown hair” is trivia. “Ibara flinches at the sound of a woman's voice raised in anger because her mother used to scream at her” is actionable.
• Use the same formatting as the rest of your character definition.
• Reference {{char}} and {{user}} the same way you would in any other field.

Keep Entries Focused

One entry, one topic. An entry about Ibara's mother should be about Ibara's mother. Not about her mother, her father, her childhood home, the political situation of catpeople in her hometown, and what she had for breakfast the day she ran away.

If those are all important, they can be separate entries with their own keywords. Stuffing everything into one mega-entry means the model gets a wall of text when all it needed was one specific piece of information.

Watch Your Length

Lorebook entries should be concise. Every entry that loads eats into the token budget, and long entries push out everything else.

Thinking About Keyword Coverage

The hardest part of keyword lorebooks is predicting what words will come up in conversation. You're essentially guessing how users will talk about a topic, and then hoping you guessed right.

Think in Synonyms

People don't always use the same word for the same thing. If your entry is about Ibara running away from home, your keywords shouldn't just be “ran away.” Think about how a user might bring it up:

Think About Adjacent Topics

Sometimes a topic comes up indirectly. The user might not mention Ibara's mother directly, but they might say something that should surface that information anyway.

If there's an entry about her mother being abusive, consider keywords that orbit the topic: mother, mom, parents, family, hit, yell, scream, flinch, abuse

The word “flinch” might seem odd as a keyword for a backstory entry. But if the model just described Ibara flinching and the user is asking why, that's exactly when the backstory should load.

Don't Go Overboard

There's a tension between keyword coverage and accidental triggers. The more keywords you add, the more likely the entry fires when it shouldn't.

Recursive Scanning

Some platforms support recursive scanning. This means that when an entry loads, the system scans the entry's content for keywords that might trigger additional entries.

For example: an entry about Ibara's mother mentions “the apartment.” If you have a separate entry about the apartment she was abandoned in with the keyword “apartment,” recursive scanning will load that entry too.

This creates chains. One topic pulls in related topics, which pull in more related topics. It can be powerful for interconnected lore. It can also be a runaway train that loads half your lorebook from a single trigger.

When to Use Lorebooks vs. Permanent Fields

This is the question that matters most, and the one people get wrong most often.

Ibara's defensiveness and trust issues? Personality. She displays those constantly, in every interaction.

The specific details of what happened to her at sixteen? Lorebook. It only matters if the conversation goes there.

Her verbal tics and body language patterns? Personality and Example Dialogue. Those need to be present always.

The name of the friend she had before she ran? Lorebook.It'll come up when it comes up.

Ibara

*tail flicks*

“So my worst memories are filed away in a drawer that only opens when someone says the right word. …That's either merciful or cruel and I can't decide which.”

Lorebook Content That Works Well

• Detailed backstory. The full history doesn't need to load every message. But when the user asks about her past, the relevant entry appears and the model suddenly knows things.
• Secondary characters. The friend she mentions sometimes, the owner she ran from, the street vendor who was kind to her once. They don't need to be in context until they come up.
• Location details. The layout of the apartment, the alley she sleeps in, the place she's avoiding. Load when the scene goes there.
• World lore. The political situation, the history of catpeople in this setting, how the local economy works. Relevant when discussed, dead weight otherwise.
• Specific behavioral triggers. How she acts when drunk. What happens when she hears a certain song. Her response to being cornered. These are too situational for the Personality but too important to leave undocumented.
• Relationship dynamics. How she acts around specific people. What she thinks about the user at different trust levels. How she behaves in crowds vs. alone.

Lorebook Content That Doesn't Work Well

• Core voice and speech patterns. Her verbal tics need to be present constantly, not loaded occasionally when a keyword happens to match. Personality and Example Dialogue.
• Moment-to-moment behavioral cues. If you want her tail and ears described consistently, that can't live in a lorebook that only loads sometimes. Permanent fields.
• Fundamental personality traits. Her defensiveness isn't a topic that becomes relevant. It's how she is all the time. Personality.
• Anything the model needs constantly but you've buried in a lorebook. It won't load reliably or consistently. If it matters every message, it needs to be permanent.

Common Lorebook Mistakes

Lorebook Size and Token Budget

Lorebooks can be big. That's the point. You're storing information that doesn't need to be present all at once.

But you still have a token budget — the maximum number of lorebook tokens that can be loaded into context at any given time. Once the budget is full, additional entries get dropped based on priority. This means:

• Even well-triggered entries might not load if the budget is already full.
• High-priority entries should be reserved for genuinely critical information.
• Shorter entries leave room for more entries to coexist.

And a final note: the lorebook is a tool for the character, not a substitute for building the character. If you're spending more time writing lore than writing the Personality, First Message, and Example Dialogue, your priorities might be backwards. Those fields are where the character lives. The lorebook is where the world around them lives. Build the person first. Furnish the world after.

Ibara

*...tail sways*

“If I stop being me just because a keyword didn't fire, I was never really me to begin with. Build the person first. Then build the world around them.”