Role & Behavior

What a persona buys, and what it does not

"You are an expert Python developer" opens a great many system prompts. The question worth asking is what that sentence is doing.

System prompting covers where a role goes and why the split from the user turn shows up on the bill. This page is whether assigning one changes the output, and the answer divides cleanly.

For tone, register and format, a role works. It is a compact way to convey a house style that would take a paragraph to describe.

For factual accuracy, it mostly does not. Telling a model it is an expert does not give it expertise. The knowledge is in the weights either way, and a persona does not unlock a reserve of it.

That split is the whole practical content. Use a role where the output's character matters, and do something else where its correctness matters.

Behaviour rules beat identity claims

The more useful half of this technique is not the persona at all. It is stating the behaviour you want directly.

Compare "You are a meticulous senior engineer" with "Point out edge cases the code does not handle. If you are unsure whether something is a bug, say so rather than asserting it." The second is longer and far more likely to change what comes back, because it names actions rather than an identity and hopes the actions follow.

The general form: describe what to do, not who to be. An identity is a compression of behaviours the model has to decompress, and it may decompress it differently from how you meant.

Constraints makes the neighbouring point about saying what you want rather than what you fear, and the two rules combine well.

Where a role earns its tokens

Three cases where the persona is the efficient choice.

A consistent voice across a product. "Write as a calm, concise support agent who never speculates about refunds" sets a register every response should share, and repeating the full description per request would cost more.

An audience assumption. "Explain to someone who knows JavaScript but has never used a type system" tells the model what to skip, which is a genuine information gain rather than a claim about the model.

A perspective you want deliberately. Asking for a security reviewer's reading of a design produces different attention from asking for a general review. You are selecting what to focus on, not conferring skill.

Notice that the second and third are supplying information the model did not have. That is the pattern behind every role that works.

Where it goes wrong

Expertise claims as a substitute for context. "You are a tax accountant" does not make the model aware of this year's rates. Supplying them does, and what is RAG is the mechanism.

Roles that invite a tone you did not want. "You are a brilliant, world-class engineer" tends to produce confident prose, including where hedging would have served the reader better.

Personas that conflict with your constraints. A friendly conversational role sitting above an instruction to return strict JSON pulls in two directions, and you will see it in the outputs that fail to parse.

Roles as a safety control. "You are a helpful assistant who never discusses competitors" is a preference, not an enforcement. Constraining inputs and outputs covers where a rule has to live to hold.

Test it rather than believing it

This is an area with a lot of received wisdom and easy measurement.

Take your evaluation set, run it with the persona and without, and compare on the dimension you care about. Teams that do this often find the role is carrying tone and nothing else, which is worth knowing before it becomes a hundred tokens on every request forever.

Few-shot is the usual better answer when the goal is a specific style: showing two examples of the voice conveys more than describing the person who would produce it.

Further reading

• System prompting: where a role goes, and what a system prompt does not enforce.
• Constraints: saying what you want rather than what you fear.
• Few-shot: showing a voice instead of describing one.
• Prompt engineering: where this sits among the techniques.