Naming Characters in AI Stories Before They Blur

Naming characters in AI stories is the cheapest continuity insurance available to you. A name is a short, unusual string that the narrator can carry forward and the story’s record can file a person under. A role is a category, and categories accept new members: call her the innkeeper for three scenes and a second innkeeper can quietly absorb the first.

• A name works as a retrieval key, while a role is a slot the world can refill without telling you.
• SillyTavern’s lorebook entries are activated by a list of keywords, so in that design a name is literally what fetches a character’s background.
• The scenes before you name someone are the scenes most likely to lose their owner when the record is assembled.
• Two names that share a first syllable give the narrator two chances to merge them.
• In an authored game the name is bound to the character once, in code; in a live story it is re-inferred from your prose on every turn.

Why does naming characters in AI stories change what the narrator remembers?

Because almost everything these systems keep is keyed on text, and a name is the most distinctive text a person owns. A structured record has to file each character under something. If that something is “the innkeeper”, the file is really about the job, and the next person to hold the job inherits it.

Roles are generated constantly and cheaply. A guard, a clerk, a sister, a man at the bar. Each one is a slot rather than a person, and a narrator rebuilding scene six from a record full of slots has no reliable way to know whether the guard at the gate is the guard from the courtyard three scenes back.

How literal this is depends on the system. SillyTavern’s World Info documentation describes an entry’s keys as “A list of keywords that trigger the activation of a World Info entry”, and notes that “Keys are not case-sensitive by default (this is configurable)”. With whole-word matching switched on, it offers a worked example: the key king matches “long live the king” but not “it’s not to my liking”.

A lorebook is not the same thing as a story record, and the two are built to different ends. But the lesson survives the difference. A character’s background reaches the page when something in your text points at it. Point with a name and the pointer is unambiguous. Point with a job title and you are relying on there being exactly one holder of that job, forever.

The top track is the common failure, and it is a quiet one. Nothing in it reads as broken. The prose stays fluent, the innkeeper stays an innkeeper, and only when you go looking for the man who owed you a favor do you find that nobody in the story is carrying the debt.

When should you name a character?

The first time they matter, not the third. A name given in the opening scene costs you four words and makes every later scene indexable. A name given in scene six leaves five scenes of history that the record has to attach to somebody after the fact, and attaching it is guesswork.

“Matter” is a low bar here. If a person speaks twice, or if you can imagine coming back to them, name them now. Narrators usually meet you halfway: describe someone specifically enough and the reply often supplies a name on its own, at which point your only job is to use it.

Naming someone the narrator already introduced

If no name arrives, ask for one inside the fiction rather than out of it. A spoken line — “What should I call you?” — is a move that costs one scene and buys you the rest of the story. Handing over your own name in the same breath usually gets theirs in return, because that is how the exchange works in prose.

Attaching a name late is fine as long as you attach it explicitly. Say the name and the role together once, Maret, the innkeeper, so the record has a sentence joining them instead of two loose entries. In Fabledrift, an interactive fiction app for Android, you can also write a note of your own; when a note contradicts the story record, the note wins.

Which names are easiest for a narrator to keep straight?

Short, distinct, and unlike each other. Distinctness matters more than beauty, and more than authenticity. A cast whose names all come from the same phonetic well looks elegant on a page of notes and turns into a smear the moment three of them are in a scene together.

Name pair	Why it drifts	What holds instead
Maren and Marek	Four shared letters, same first syllable	Maren and Dovic
Two characters called “the captain”	The role is a slot, not a person	Captain Ilsa and Captain Rook
Ser Aldric and Aldric the Younger	One name contains the other	Ser Aldric and Pell
Ana and Hana	Differ by one unstressed letter	Ana and Teverin

The same discipline that keeps a world coherent keeps its cast coherent, which is why naming conventions belong in the setting itself rather than in your head. A region whose names share a shape, distinct from the shape of the next region’s, does double duty: it tells the reader where they are and it keeps the record’s rows apart. That is one of the quieter payoffs of designing a world for an AI narrator before the first scene rather than during it.

How authored games bind a name to a character

They declare it. Ink, inkle’s narrative scripting language, treats a name as an ordinary stored value: its documentation states that “Global variables can be defined anywhere, via a VAR statement. They should be given an initial value, which defines what type of variable they are - integer, floating point (decimal), content, or a story address.” The example it uses is VAR players_name = "Emilia".

That binding is made once and nothing the player types can loosen it. Emilia is Emilia in scene forty because a line of code says so, and the cost of that certainty is that the author had to decide it in advance, for every character, before anyone read a word.

Character files for chat-style systems make the same point from the other side. SillyTavern’s character design guide puts it plainly: “Character Name is the only required field. You can leave the rest empty and still use the character in chats.” Personality, scenario, first message — all optional. The handle is not.

A live narrator has neither luxury. Nothing is declared ahead of time, so on every turn it has to work out which words in your prose refer to which person, using only what the record holds and what the scene says. Giving it a name is giving it the one clue that does not have to be inferred.

What to do when a name drifts anyway

Fix the record, not the sentence. Arguing with a paragraph that called Maret “Maren” produces an apology and no change; stating the correction as a fact about the story is what survives into the next scene. The shape of that move is the subject of correcting an AI narrator, and it is worth doing the moment you notice rather than four scenes later, when both spellings have history.

Check the right thing, too. A narrator that greets you warmly by the right name may still have lost the promise attached to it, because a steady voice and a kept obligation are stored differently. We have written about that split before, in AI characters that remember you, and the short version is that getting the name right is necessary rather than sufficient.

Renaming is the one case where more words help. Write the old name and the new one in a single sentence — she tells you her real name is not Maret — so the record can merge two entries instead of opening a second file on the same woman.

Say the name, then use it

The whole practice fits in two habits. Name a person the first time they are worth naming, and then say the name again instead of reaching for the pronoun or the job. Not because the narrator is stupid, but because every repetition is another anchor, and anchors are what a record is built from.

You will notice the difference in the scenes you did not plan: the stranger from scene three walking back in at scene nineteen and being recognizably himself, still holding the thing he was holding. That continuity is not a feature you buy. It is mostly a consequence of naming characters in AI stories while they are still in front of you.