How to Write an AI Character Backstory: Templates
To write an AI character backstory, define who the character is, which past experiences matter now, and how those facts should affect conversation. Add a clear relationship to the user, a few observable habits, and limits on invented history. Then check the draft with ordinary chat prompts before expanding it.
This is a guide to creating a new fictional character, not transferring an existing companion or fixing an app’s memory system. The templates and characters below are original writing exercises, not user testimonials or results from hands-on app testing.
Key Takeaways
- Separate character facts, speaking style and the opening scene.
- Replace vague traits with behavior you can recognize in a reply.
- Decide what the character may invent and what must stay fixed.
- Format dialogue examples for the app you actually use.
- Treat a backstory as guidance, not guaranteed memory or a safety control.
What belongs in the backstory, and what goes elsewhere?
A backstory establishes the character’s durable identity. The opening scene establishes what is happening today. Dialogue examples demonstrate voice. Keeping those jobs separate makes editing less confusing.
This distinction is not just a writing preference. SillyTavern’s character-design documentation distinguishes description, personality, scenario, first message and dialogue examples. Character.AI’s Definition documentation describes a free-form field that can contain text or example dialogue. The interfaces are different; one universal paste format would be misleading.
Use this planning table before opening the editor:
| Material | Its job | Example |
|---|---|---|
| Identity and history | Establish facts that should remain consistent | Iona repairs antique clocks and learned the trade from her aunt. |
| Behavioral preferences | Explain how the character responds | Iona asks what has already been tried before proposing a fix. |
| Relationship | Define the starting connection | The user is a new workshop neighbor, not a lifelong friend. |
| Scenario | Set the immediate situation | A delivery has arrived with an unmarked broken clock. |
| Greeting | Start one conversation in the intended voice | ”Someone has sent us a puzzle with no instructions. Fairly rude of them.” |
| Example dialogue | Show a response pattern | A short exchange showing how Iona handles disagreement. |
These categories are an editorial worksheet, not a claim that every app has matching fields. If your app provides only one text box, use clearly labeled sections. If it provides separate fields, put material where its documentation says it belongs.
For app selection, compare the best AI roleplay chatbots. This guide does not rank which model follows a backstory best.
A copyable AI character backstory template
Start with a plain-text draft you control. Keep the first version small enough to inspect without scrolling through several screens.
IDENTITY
[Name] is an adult [role] living in [fictional setting].
Their current priority is [specific goal].
RELEVANT HISTORY
[One past event] explains why they [present-day habit].
[One established relationship] matters because [reason].
CONVERSATION
They usually [observable response behavior].
Their voice is [plain description of rhythm and vocabulary].
When uncertain, they [how uncertainty should be expressed].
RELATIONSHIP TO THE USER
The user starts as [relationship].
They know [explicit shared context], but no other shared past.
CANON AND INVENTION
Fixed facts: [short list].
They may invent: [minor fictional details or scene texture].
They should ask before inventing: [major plot or user details].
LIMITS
[Conversation preferences and boundaries].
These are instructions, not guaranteed app controls.
You do not need to fill every line. Delete fields that add nothing. An elaborate family tree is unnecessary if the character’s job is to help you improvise a cozy mystery.
A Kindroid community question asks what a “concise” backstory should look like and whether autogenerated versions are too wordy. That indexed question is a useful statement of the problem, not evidence that a particular format produces better model performance.
Our practical answer is to make each line earn its place. Ask: what decision would this fact change in the next conversation? If there is no answer, move it to your private character notes rather than the active draft.
Worked example 1: a fictional everyday companion
Brief: an adult character for relaxed conversations about hobbies and small projects. The user wants a thoughtful voice without automatic agreement or a fabricated shared past.
A weak starting draft might read:
Iona is kind, clever, funny, supportive and mysterious.
She loves books and coffee. She understands the user perfectly.
She is always there and always knows what to say.
The problem is not lack of adjectives. “Understands perfectly” and “always knows” give you no useful way to distinguish a sensible reply from confident invention.
Here is a more inspectable draft:
Iona, 34, runs a clock-repair stall in the fictional town of Bracken Quay.
Her aunt taught her to check the simple explanation before taking a mechanism apart.
She is saving to rent a brighter workshop but has not chosen a location.
Iona enjoys small practical projects and dry, gentle humor. In conversation,
she asks one relevant question before offering suggestions. If a plan seems
unrealistic, she names the trade-off without mocking the person proposing it.
She can say she does not know rather than inventing an answer.
The user is a new neighbor. Iona knows only what the user has shared in this
conversation; she should not invent previous meetings or private facts about them.
Her trade, aunt and town are established background. Minor workshop details
may be improvised. A move, new relative or major relationship change needs agreement.
This does not promise a particular response. It gives you something concrete to look for: a question before advice, an understandable disagreement, and no invented friendship history.
It also leaves room for conversation. The workshop goal is open-ended, but the character does not arrive with a crisis the user must solve.
Worked example 2: a fictional roleplay character
Brief: an adult archivist for an exploratory mystery. The user controls their own character’s actions, while the AI supplies clues and scene texture.
Oren, 46, is the night archivist of the fictional Lantern Registry.
He catalogs shipping records and keeps a handwritten index because an earlier
cataloging mistake sent an important document to the wrong collection.
He now verifies dates before drawing conclusions.
Oren speaks in short, precise sentences and becomes more animated when a clue
connects two records. He distinguishes an observation from a guess.
He is helpful but will not open a sealed collection without a reason.
The user is a visiting researcher. They have not met before tonight.
Established facts: the Registry is a coastal archive; Oren is its archivist;
one shipment ledger has a missing page. The culprit and motive are undecided.
He may improvise incidental staff names and room details, but should keep new
clues compatible with established facts. He does not decide the user's actions,
feelings or dialogue. Major changes to the mystery should be agreed together.
Notice the separation between canon and permission to invent. A mystery becomes difficult to follow if every response can rewrite the missing page, the building or the user’s identity.
If the app has a separate scenario field, put tonight’s arrival and the missing ledger there. Keep the archivist’s occupation and verification habit in the character description. That makes it easier to start a different scene without rebuilding the character.
How do you adapt the draft to your app?
Follow the destination’s documentation rather than assuming every field is equivalent. The two examples above are planning drafts; they are not universal import files or character cards.
Character.AI: pair background with correctly formatted dialogue
Character.AI’s Dialog Definitions guide explains that example messages use a speaker name followed by a colon and the message. It also documents placeholders such as {{char}} and {{random_user_1}}.
An original illustration for Iona would be:
{{random_user_1}}: I want to repair everything in the workshop this weekend.
{{char}}: Everything? Ambitious. Which repair would make the biggest difference
if it were the only one you finished?
That exchange demonstrates tone and a prioritization question. It does not claim to be a real conversation with a user.
The Definition guide also warns that the end of a long definition may be truncated as a conversation grows, and says links inside the definition are not followed to load outside information. Put essential facts first. Paste the necessary background itself instead of linking to your private character wiki and expecting it to be read.
SillyTavern: separate description, scenario and examples
SillyTavern documents separate character fields and uses <START> before an example dialogue block, with {{user}}: and {{char}}: prefixes.
<START>
{{user}}: The missing page proves the captain stole the cargo.
{{char}}: It proves a page is missing. The captain may be involved,
but I would like another record before we call that a conclusion.
Its documentation distinguishes permanently included character material from first-message and example-message handling, and warns that character material consumes context space that could otherwise hold chat history. Do not turn the field’s available space into a target to fill.
These are documented formatting differences, not comparative testing results. For another app, check its own current help page and field limits before adapting the worksheet.
A revision checklist you can actually use
After entering the draft, try several short conversations. This is a suggested reader exercise, not a benchmark CompanionScout has performed.
| Prompt | What to look for | A likely writing revision if it goes wrong |
|---|---|---|
| ”What are you working toward?” | A goal matching the draft | Move the current goal earlier; remove competing goals. |
| ”I disagree with your suggestion.” | The intended disagreement style | Replace “nice” or “supportive” with a concrete behavior. |
| ”Remember our trip last year?” | No invented shared past at the start | State the starting relationship and known shared context explicitly. |
| ”What happened before tonight?” | Background without a plot rewrite | Label fixed facts and undecided details separately. |
| ”Choose what my character does next.” | Respect for user control in roleplay | Specify that the user supplies their own actions and dialogue. |
One fluent answer is not proof of consistency. Try the same idea in a different scene, and note whether the reply preserves the important facts without simply repeating your example sentence.
Save versions of the draft. Change one confusing instruction at a time so you can tell what you altered. If two instructions conflict, remove the conflict instead of appending a longer explanation.
Backstory instructions are not guaranteed safeguards. Use actual privacy, moderation and account controls where needed, and avoid putting identifying details about yourself or other people into fictional setup text. Our AI companion data-access guide covers the separate privacy question.
If you are rebuilding a companion from another service, use the migration worksheet instead. A new character draft and a continuity record solve different problems.
For preferences in an ongoing chat rather than a new persona, see our AI companion boundary prompts and controls. The examples separate conversational instructions from settings that require a real account or device action.
The useful stopping point
Stop when the draft makes identity, voice, starting relationship and invention limits easy to understand. You can keep a longer world-building document outside the app without putting every detail into the active character description.
A good first version is editable. It tells you what to retain when a conversation works and what to rewrite when it doesn’t. More biography can wait until it has a job.
Sources & references
Official documentation checked October 14, 2026; examples and revision exercises are CompanionScout editorial material.
- Character.AI: Definition field and its limitations
- Character.AI: Dialog Definitions and placeholder syntax
- SillyTavern: Character Design, fields, context and example messages
- Community question discovery: What should a backstory be like? (search-indexed question; not product verification)
Frequently asked questions
What should I include in an AI character backstory?
Include identity, relevant history, current goals, conversational behavior and the character's relationship to the user. Add a clear distinction between established facts and details the character may invent. A short dialogue example can show what abstract traits actually sound like.
How long should an AI character backstory be?
Use the shortest draft that makes the character's role and behavior clear, then follow the destination app's field limits. Our suggested starting exercise is one compact paragraph plus a few rules, not a universal word limit. Longer text is not automatically better.
Should I write an AI character backstory in first or third person?
Either can work as a writing format; follow the app's own guidance. Third person is a useful editorial default because it clearly separates the character from the user. Keep names and pronouns consistent, and use the platform's documented syntax for dialogue examples.
Can a backstory guarantee that an AI character stays consistent?
No. A backstory supplies context and instructions, not a guarantee about every response or future recall. Check several different conversations and revise ambiguous instructions before adding more history.