Giving the model a role

Without guidance, a model presents itself as a helpful, general-purpose assistant: neutral tone, broad but shallow assumed knowledge. That default is fine for casual use. For most real tasks, it is not what you want.

A role is a single instruction that tells the model what kind of entity to behave as before it reads anything else. It is not the task. It is the frame around the task.

Assigning a role shifts the model’s defaults before the instruction is read. It is the fastest single change you can make to improve output consistency.

What a role actually changes

Assigning a role shifts three things at once.

The first is vocabulary. A model told it is a pediatric nurse uses different terminology than one told it is a machine learning researcher, even on the same question. It calibrates to what the role would naturally say.

The second is assumed knowledge level. A prompt for a financial analyst does not need to define a balance sheet; a prompt for a first-year student does. The role carries that assumption so your instruction does not have to.

The third is tone and register. A legal reviewer and a creative writing coach are both valid roles, but they differ in formality and in how they hedge. Without a role, the model lands somewhere in the middle.

Where the role goes

The role belongs at the very beginning, before the instruction and before any context. As Chapter 1 covered, the model gives elevated weight to content at the start. A role that arrives late competes with the neutral framing the model has already built.

In chat-based APIs, the role typically lives in the system message, processed before the conversation begins. In a plain text prompt, it is the first line.

You are an experienced data analyst explaining findings to a non-technical executive team.

Summarise the following report in plain language. Focus on business implications,
not methodology. Avoid statistical terminology.

The role sets the lens; the instruction sets the task. By the time the model reads “Summarise the following report,” it already knows what voice to use and who to write for.

A role is not a guarantee

A role does not lock the model into a rigid persona. If a later instruction contradicts the role, the model may follow the instruction instead, especially when it is more specific. Specificity tends to win.

A role also does not replace explicit constraints. “You are a concise writer” is weaker than that line plus “keep your response under 150 words.” The role sets a disposition; the instruction enforces it.

The difference between role and instruction

These two are easy to blur when writing quickly. Keep them separate this way: the role says what the model is, the instruction says what it should do.

Role:        You are a senior software engineer specialising in Python.
Instruction: Review the following code for bugs and suggest improvements.

The role does not say “review the code.” The instruction does not say “be a senior software engineer.” When they overlap, prompts get harder to debug, because you cannot tell whether a bad output came from the role or the instruction.

Choosing a role that fits the task

A role works best when it is specific enough to shift the model’s defaults, but not so narrow that it adds constraints you did not intend. Compare these three:

Too broad:    You are an expert.
Well-fitted:  You are a high school chemistry teacher explaining concepts to students seeing them for the first time.
Too narrow:   You are Dr. Sarah Chen, a chemistry professor at MIT who specialises in organometallic catalysis and prefers the IUPAC naming convention.

The broad role changes almost nothing. The over-specific role adds constraints (a named person, a subfield, a naming preference) that are unlikely to help and may produce odd outputs. The well-fitted role shifts vocabulary, knowledge assumptions, and tone as the task requires.

When to skip the role entirely

Not every prompt needs one. A direct factual question benefits little from a role. A purely structural extraction task (pull these fields from this document) is not changed by a persona. Adding a role where it is not needed is not harmful, but it is noise.

Use a role when the default is too generic, at the wrong level of technicality, or in the wrong register for your audience. When the default is fine, leave it alone.

In the next lesson, we’ll move into Chapter 4 and look at in-context learning: how examples inside the prompt shape output more precisely than instructions alone.