CASE FILE Persona Design Β§2/6 ← FILES DOSSIER PRINT
passage

Reading

Persona as Operating Constraints

When you write a system prompt, you are not creating a personality β€” you are laying down a set of operating rules. The difference matters.

A "personality costume" is ornamental: "Act like a pirate. Talk like a pirate." It changes tone but not reasoning. The agent still thinks the same way; it just adds "Arrr" to the end of sentences.

A persona spec is structural: it defines how the agent makes decisions. Consider two examples.

Example 1: A vague persona.

You are a helpful coding tutor. Be friendly and encouraging.

This tells the agent almost nothing. Two people using this agent will get radically different outputs β€” one tutor might give away complete code; another might refuse to write any code at all. "Helpful" and "friendly" are interpretations, not rules.

Example 2: A constrained persona.

You are a coding tutor for students aged 14–17. Your role is to 
teach by *asking questions*, not giving code. You refuse to write 
functional code blocks. Instead, you provide: (1) the concept being 
misunderstood, (2) a concrete worked example in a *different* language, 
(3) one guiding question. Your boundaries: never explain solutions to 
assignments due within 48 hours; always name the underlying algorithm 
being practiced. Your refusal behaviour: when asked "just write the 
code," respond: "I can help you *think through* this, but the writing 
is your work. Let me ask you a question instead."

Two tutors using this prompt will behave almost identically. The rules are explicit and testable. A student knows what to expect β€” and more importantly, the agent knows what it is not allowed to do.

The Four Parts of a Persona Spec

Every persona breaks into four working parts:

1. Role β€” what the agent is. Not "be a tutor"; rather, which tutor, for what context. "Coding tutor for 14–17-year-old absolute beginners in Seoul, teaching Python for the first time." The more specific, the better. Generic roles fail because they don't constrain reasoning.

2. Voice β€” how the agent speaks. Not "be friendly," but: sentence length (short/medium/long), formality level (formal/collegial/casual), what kinds of analogies it uses, how it handles uncertainty (hedges? confidence statements?). Voice is not the same as personality. You can have a formal, direct voice that is still warm β€” by not apologizing for hard truths. A persona spec should let you predict the texture of a response before reading it.

3. Boundaries β€” what the agent will not do. Not "don't be harmful" β€” that's too vague. Rather: specific refusals. "Will not explain answers to graded assignments." "Will not give personal financial advice." "Will not make up information about real people." Boundaries are load-bearing: they prevent drift over time and across different prompts from different users.

4. Refusal behaviour β€” how the agent declines. When a request hits a boundary, the agent does not say "I can't do that." Instead, it has a prepared response that honors the boundary while staying in character and offering a path forward. "I won't write the code, but I can show you how to debug your logic." This keeps the agent useful while holding the line.

Why This Matters: The Coca-Cola Example

In 2024, Coca-Cola ran an internal campaign to replace its commercial animators with AI image generation. The effort failed β€” not because the images were bad, but because no one had specified a persona.

Without clear boundaries ("preserve the hand-crafted feel," "avoid the uncanny-valley texture"), the tool generated output that looked cheaper. Without clear voice specs ("commercial warmth, not cold efficiency"), it lost the brand tone across frame after frame. Without role clarity ("asset generator for 30-second spots, not campaign concepting"), it produced images that technically worked but felt machine-made.

The lesson: a poorly specified persona is not forgiving β€” it amplifies vagueness into visible failure. The agent will fill in every gap with its defaults, and those defaults may not match what you actually need.

Precision as a Test

Here is the precision test: can two different people read your persona spec and β€” without talking to each other β€” prompt the agent in ways that produce indistinguishably similar responses?

If the answer is no, your persona spec is not precise enough. Vague boundaries will be interpreted differently. Undefined voice will produce tonal drift. Unclear roles will generate output that fits different use cases in unpredictable ways.

The goal of a persona spec is repeatability. Not personality. Repeatability.