Message roles

The three roles

A chat is stored as a list of messages, and each message carries a role saying who it came from:

system — standing instructions that frame the whole conversation: who the assistant is, what it should and should not do. Written by whoever deploys the model, not said by anyone in the chat.
user — what the person asked or said.
assistant — what the model replied.

Some providers use other names for the same idea — model instead of assistant, a separate field for system instructions, or developer for instructions — and some add a tool role for results returned by functions the model called. The structure is the same.

What the model actually reads

A model reads one flat sequence of tokens, not a list of objects. A chat template converts the messages into that sequence, inserting special tokens that mark where each turn starts and ends and whose turn it is. The model learned these markers during instruction tuning. They are how it knows the user has finished, that it is its turn to speak, and when to stop.

Messages, as stored

systemYou are the support assistant.

userHow do I reset my password?

assistantOpen Settings → Security and choose Reset password.

What the model reads

<|im_start|>system
You are the support assistant.<|im_end|>
<|im_start|>user
How do I reset my password?<|im_end|>
<|im_start|>assistant
Open Settings → Security and choose
Reset password.<|im_end|>

Left: the messages as stored. Right: the same chat after the model's chat template, here a ChatML-style template used by some open model families. Special markers tell the model whose turn it is and where each turn ends.

Each model family has its own template. Using the wrong one, or none, produces input the model has never seen in that shape, and quality drops sharply. Hosted training services apply the right template for you; for open models, libraries such as Hugging Face Transformers store it alongside the tokenizer.

How roles shape training

In supervised fine-tuning the roles decide what is learned. The model is trained to produce assistant messages; system and user messages are context it reads but is not trained to write. That is why a dataset of chats teaches the model to answer like your assistant rather than to ask questions like your users.

Roles also explain why the system prompt matters so much. A model fine-tuned with a particular system message learns its behaviour in the presence of that message, and behaves most like the trained model when it receives the same instructions at run time.

One chat, three roles

system: “You are the support assistant for an invoicing product. Answer in short numbered steps.”
user: “How do I add a VAT number to an invoice?”
assistant: “1. Open Settings → Company. 2. Enter the VAT number. 3. Save — it now appears on new invoices.”
In training, the first two messages are context. The third is what the model learns to write, given that context.

Rules most training formats enforce

Turns alternate between user and assistant.
After any system message, the conversation starts with the user.
There is usually one system message, at the very start.
A record ends with an assistant message if it is to teach anything.

Common mistakes

Putting instructions in a user message during training but in the system prompt at run time, or the other way round.
Training with one system prompt and deploying with another.
Formatting an open model's input by hand instead of using its chat template.
Leaving consecutive messages from the same role, which most formats reject.

References and further reading

External sources open in a new tab.