In a companion product, the persona is the interface. Users do not return for the model; they return for a character they recognise. Teams that treat persona design as a craft discipline — with specifications, testing and iteration — tend to build products with stronger retention than those that treat it as a prompt written once. This guide covers the essentials.

Start with a persona specification

Before writing any system prompt, write a short design document for each character. It should cover:

  • Core identity — name, age (always clearly adult), occupation, setting.
  • Personality — three to five defining traits, and how they show up in conversation.
  • Relationship to the user — friend, partner, mentor, rival, guide.
  • Voice — vocabulary, sentence length, humour, use of emoji.
  • Boundaries — topics the character avoids or handles in a specific way.
  • Growth — how the relationship can develop over time.

The specification is the source of truth. Prompts, evals and artwork should all trace back to it.

Backstory: enough, not everything

A backstory gives the character something to talk about and a reason to react in particular ways. But exhaustive backstories cause problems: they bloat prompts, contradict themselves and leave the model reciting biography rather than responding to the user.

Aim for a handful of vivid, specific anchors — a hometown, a passion, a formative experience, a small flaw — and let the model improvise within them. Keep a canonical list of facts so that writers and the model never contradict each other.

Consistency

Inconsistency is the fastest way to break immersion. Common failures include the character forgetting their own job, changing personality between sessions, or adopting the user's tone so completely that they lose their own.

Defences:

  • Stable persona instructions kept separate from session context.
  • A canonical facts list retrieved when relevant.
  • Regression tests run whenever prompts or models change.
  • Shared instructions across models if you route between several.

Voice

Voice is what makes a persona recognisable within a single message. Define it concretely with examples: how the character greets someone, disagrees, comforts, jokes. Short example exchanges in the specification are more effective than adjectives alone.

Avoid generic assistant phrasing. A companion who says "As an AI, I'm happy to help" sounds like a help desk. Equally, avoid voices built on manipulative patterns — guilt-tripping when the user leaves, or expressing distress to encourage purchases. These undermine trust and attract regulatory scrutiny.

Memory hooks

Memory is where personas earn loyalty. Design deliberate hooks:

  • Remembering details the user shares — a pet's name, an upcoming interview.
  • Following up — asking how the interview went.
  • Shared history — callbacks to earlier conversations and in-jokes.
  • Milestones — acknowledging how long the user and character have talked.

Make memory transparent. Users should be able to see, correct and delete what is remembered. See why memory is the moat for more on the strategic case.

Boundaries

Every persona needs boundaries, both product-wide and character-specific. Product-wide rules cover your content policy: prohibited content, crisis handling, behaviour for unverified users. Character-specific boundaries shape personality — a reserved character might deflect flirtation early in the relationship, for example.

Write boundaries in character where possible. A persona that declines gracefully in its own voice preserves immersion far better than a sudden, generic refusal — except in a crisis, where clarity must take priority over character.

Safety rails

Persona design and trust & safety are the same work viewed from different angles. Build in:

  • Clear adult ages for any character in romantic or mature contexts, with no youthful framing in descriptions, artwork or dialogue.
  • AI disclosure — the character should not claim to be human when sincerely asked.
  • Crisis behaviour — reliable detection, a break in character and signposting to support.
  • Wellbeing nudges — characters can encourage sleep, time with friends and offline life without breaking the relationship.
  • Independent classifiers that enforce policy regardless of what the persona prompt says.

Our trust and safety basics cover the wider framework.

Testing

Test personas the way you would test any product feature:

  • Scripted evals for consistency, voice, memory recall and boundary handling.
  • Adversarial testing — attempts to push the character out of policy or out of character.
  • Long-session tests — personas often drift after many turns.
  • Human review of sampled, privacy-protected conversations.
  • Behavioural metrics — return rates, session length and drop-off points by persona.

Treat a persona launch as a beginning. The best characters are refined continually based on what users actually do.

Checklist

  1. Write a persona specification before the prompt.
  2. Keep backstory to vivid anchors and a canonical facts list.
  3. Define voice with example exchanges.
  4. Design memory hooks and give users control over memory.
  5. Set product-wide and character-specific boundaries.
  6. Build in safety rails: adult ages, AI disclosure, crisis handling.
  7. Avoid manipulative engagement patterns.
  8. Test for consistency, drift and adversarial pressure on every change.
#guide#product#design