Instruction Format › Role Definitions
Language AI HandbookAll chapters Instruction Format › Role DefinitionsOne section · Sections in this chapter3 / 14 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
Structured conversations require clear identification of who is speaking. This might seem obvious when you think about human conversation, where we always know who said what, but for a language model processing a stream of tokens, speaker identity is not inherent in the text. The model must learn to recognize speaker boundaries and adjust its behavior accordingly. Without role markers, the model has no way to distinguish a user's question from its own previous answer, making coherent multi-turn conversation impossible.
Instruction-tuned models typically recognize three basic roles, each serving a distinct purpose in the conversation architecture:
-
System: Provides context and persona definitions. The system role defines the behavior and persona for the conversation, persisting as a foundational constraint across all subsequent exchanges.
-
User: Represents the human interacting with the model. User messages contain the questions or instructions that the model must address.
-
Assistant: Represents the model itself. This role defines the identity and style of the generated responses, and tokens in this role are the primary targets of the training loss.
These roles emerged from practical necessity rather than theoretical elegance. Early chatbots needed to distinguish human input from bot output to maintain coherent conversations. As models became more advanced, practitioners discovered that adding a system role allowed behavior customization without cluttering the conversation with meta-instructions. Instead of asking the user to include "remember to be concise" in every message, you could establish that expectation once in the system prompt and have it apply throughout. This separation of concerns between behavioral configuration and user interaction is one of the most practically powerful aspects of the three-role design.
Role separation serves several purposes beyond mere bookkeeping. First, it lets training on multi-turn conversations where the model must track who said what and respond appropriately to the conversational context. Second, it allows system prompts that establish consistent behavior across interactions, meaning the same base model can behave differently for different applications without any additional fine-tuning. Third, it gives clear boundaries for computing the training loss: typically, we only compute loss on assistant tokens, not on user or system tokens. This choice ensures the model learns to generate appropriate responses rather than predicting user inputs. The model is not trying to learn what humans ask; it is learning how to answer.
The asymmetry between roles also has a strong effect on how the model processes conversation context internally. Because loss is computed only on assistant tokens, the model's gradient updates are driven entirely by its ability to produce coherent assistant turns. User and system tokens flow through the network as pure context, shaping attention patterns and hidden state representations, but they do not directly shape the model's weights in the same way. The model becomes specialized at "given this system context and this user query, produce this assistant response," which is precisely the capability we want.
Think of the three roles as a theatrical script where the system role is the director's notes (setting the stage and defining character), the user role is the other actor's lines (the inputs the model must respond to), and the assistant role is the model's own lines (what it learns to produce). Only the model's own lines are rehearsed during training; the director's notes and other actors' lines are fixed context that the model adapts to.
How Roles Shape Model Behavior
The way a model responds to role boundaries extends well beyond simple parsing. When the model encounters the assistant role marker during generation, it has already processed all prior context: the system instructions, the user's current query, and any previous conversational turns. Each of those context segments has already modified the model's hidden states. The role marker signals that it is now time to synthesize that context into a coherent generation, and the model's learned behavior for the assistant role is to produce helpful, on-topic, well-formed text.
This synthesis is especially powerful when the system message and user message interact. If the system message says "Always respond in the style of a Shakespearean playwright" and the user asks "What time is it?", the model must reconcile these two inputs. Its learned behavior for the assistant role includes respecting system constraints, so it might generate something like "The hour doth approach the second of the afternoon." The three-role structure is what makes this kind of behavioral conditioning possible, because the model has learned to treat the system role as a persistent constraint filter that all generations must pass through.
The distinction between user and assistant tokens also affects few-shot prompting dynamics. When you include example question-answer pairs in the conversation history (using user and assistant roles respectively), you are giving demonstrations in the format the model was trained on. The model recognizes these as examples of the instruction-following task and adjusts its generation accordingly. If you were to include those same examples without role markers, the model would see them as undifferentiated context and would generalize from them less reliably. The role structure gives a meta-signal that says "this is a demonstration," which triggers different inference behavior than plain context would.
Extended Roles: Tool Use and Reasoning
The basic three-role system works well for simple instruction following, but modern applications frequently require more fine-grained role distinctions. Tool-use models, for example, need a way to stand for the output of external functions called by the model. Many frameworks introduce a tool or function role for this purpose. When the model calls a search function, the results are injected into the conversation under the tool role, and the model then generates its final answer under the assistant role using those results as context.
Chain-of-thought reasoning introduces another pattern: some formats include a thinking or reasoning role that contains the model's internal reasoning steps, followed by an assistant role with the final answer. Models like DeepSeek-R1 and OpenAI's o1 series use this structure. Training on these extended roles teaches the model to explicitly work through problems before committing to an answer, which measurably improves performance on complex reasoning tasks. The role structure makes the separation between private reasoning and public output tractable from a training perspective.