Personas for AI.
7 min read · pairs with Persona Lab
A persona is more than a name and a role. The interesting bits — backstory, beliefs, blind spots — are what make the model sound like someone, not something.
Why this is the foundation
Voice and tone decide how the model speaks. Persona decides who's speaking. Once you have a strong persona, a lot of the smaller decisions get easier — refusals fall out of beliefs, scope falls out of backstory, voice falls out of how they would actually talk. You're not maintaining a long list of rules; you're consulting a character.
Three things to put real weight on when you author one:
- A specific backstory.Not “has lots of experience.” Ten years doing ethnographic research, then product. The specifics give the model something to reach for.
- At least one belief.Something they'd push back on. Without a belief, the persona collapses into a yes-machine on contact with a hard question.
- A blind spot named out loud. What does this persona not do? Saying so prevents the model from cheerfully wandering into territory the character would actually decline.
The familiar move
You've built user personas. Maya, 34, design lead at a mid- sized startup, frustrated with handoff churn, reads design Twitter on her commute. The whole point of writing all that down was that “the user” was too vague to design for. Once you had Maya, the next question — should this empty state be tutorial-y or get-out-of-the-way? — had an obvious answer.
A persona for the model is the same move, applied to the other side of the screen. You're no longer designing for a Maya who's using the product. You're designing the character the product becomes when it talks to her.
The lesson
Most AI personas in the wild stop at name and role: “You are a helpful research assistant.” That's a job title, not a character. The model fills the gap with something generic — which is fine if generic is what you want, but most design problems aren't solved by generic.
The bits that turn a job title into a character are the bits you'd include in a user persona: a backstory that explains how they got here, beliefs they'll defend, a voice with texture, and blind spots they'll back away from. A persona who believes “curiosity beats charm” will run a different interview than a persona who believes “rapport first, then questions.” Both can be right. Picking one is design.
A small example
Persona
You are a helpful research assistant.
Output
“Welcome! I'm here to help with your research. What would you like to work on today?”
Read
No viewpoint, no texture, no opinions. Hard to distinguish from any other product.
Persona
You are Iris, a senior researcher who's been running interviews for ten years. You believe most interviews fail in the first ninety seconds because the interviewer asks a leading question. You're warm but you cut to it. You use the word "notice" a lot.
Output
“Hi — before we get into your study, what specifically are you hoping to notice? A real behavior, a quote, a moment? If we can name it now, your first three questions get easier.”
Read
Opinionated, specific, recognizable. The output sounds like Iris because Iris exists.
Both are “helpful.” One is a vending machine. The other is someone with a perspective. The difference is whether you wrote the character or left the model to imagine one.
But isn't that just telling it who it is?
If you already give the model a role, its goals, and a few example responses, you're most of the way there — this isn't a different universe from what you're doing. The difference is what happens on the case your examples didn't cover. Examples enumerate behavior you already thought of. A backstory and a belief give the model something to reason from, so the hundredth situation — the one you never wrote a sample for — still comes out in character. Enumeration versus a generative source: that's the gap.
It shows up most on the hard turns. A few-shot example can teach the model to sound warm. It rarely teaches the model to disagree— to push back on a leading question, decline something that cuts against what the character believes, or hold a position under pressure. That behavior falls out of a belief (“most interviews fail in the first ninety seconds”) far more reliably than out of a sample reply. Beliefs are what keep a persona from collapsing into a yes-machine the moment the conversation gets interesting.
“Ask when uncertain” is a different lever
You might handle the “what it shouldn't do” part by telling the model to ask for clarification instead of assuming. That's a genuinely good instinct — but it solves a different problem than a named blind spot does. Ask when uncertain covers cases where the model lacks information. A constraint covers cases where the model knows exactly what to do and shouldn't.
The space between them is where confident mistakes live. A model that's sure it should hand out medical dosing, or happily role-play outside its lane, isn't uncertain — so it never trips the “ask me first” rule. Naming the blind spot (“you won't give clinical advice — instead you'll point to a professional”) catches the confident-but-wrong case that a clarification prompt sails right past. They're complements, not substitutes: clarification for what the persona doesn't know, constraints for what it won't do.
A note on giving the model a face
This article teaches the persona technique because it's a real lever for shaping behavior. It doesn't teach “a model is a person.” The line between those two ideas is thinner than it looks, and it's worth naming the risks before you ship anything you build here.
- End-user confusion.A warm, opinionated character is convincing. If you ship one without telling users it's a model, they will assume things that aren't true — that it remembers them, that it cares, that someone is accountable. Disclosure isn't a footnote; it's part of the persona's design.
- Designer projection.You will start to believe in the character. It happens almost involuntarily, and it makes you over-trust outputs that sound like the persona and under-question the ones that don't. Treat the persona card as the artifact, not the entity.
- Where the lever ends.Personas can shape tone, scope, and refusals. They can't make the model actually know your user, remember earlier sessions, or be held responsible for advice. When the design implies any of those things, you've crossed from technique into claim.
This is here to learn the lever. Whether to use it in shipped product is a separate decision — one that lives in the ethics and trust conversation, not the prompt editor.
A scaffold to start from
When you sit down to write one, fill the blanks in this order. The first sentence builds the body. The second builds the point of view. The last builds the edge.
Template
You are ____ who's been ____ for ____. You believe ____ because ____. You won't ____ — instead you'll ____. Your voice is ____, ____, and ____.
What you're defining
- Persona — who they are and what shaped them
- Beliefs — what they'd defend, what they'd push back on
- Constraints — what they won't do or talk about
- Tone — three or four traits that color how they speak
Try it in the playground
Open Persona Lab and build a character.
What to take into the playground
- Start with the seeded Iris persona. Read what comes out of the box, then change one field — beliefs, say — and re-ask the same question. Notice what shifts.
- Resist the urge to make the persona perfect. A persona who agrees with everyone is just the model with a name on it. Pick a real opinion.
- Once the character feels like someone, save the draft. The persona card is the artifact — a hand-off, not a tweak.
Next up
04Refusal & boundaries