Roles: System, User, and Assistant

Understand the role system

Mistral’s Chat Completions API structures every conversation around roles assigned to messages. Every message sent to the model must include a role that defines its function in the exchange: who is speaking, and with what authority. This mechanism might seem like a technical detail, but it is actually the backbone of any professional prompt—it’s what distinguishes a simple question asked in a chat from a carefully built application.

Mistral recognizes four distinct roles, each with a precise function:

The system role: the foundation of your prompt

The system message comes first in the message list and acts as a permanent directive that influences the entire conversation. Think of it as the job description you would hand to a new team member before their first day: it defines the expected personality (tone, level of formality, language), the preferred area of expertise, the rules for what the model must or must not do, and the default format for its responses. Once this description is written, every subsequent exchange fits within this framework without you having to repeat it.

messages = [
    {
        "role": "system",
        "content": """You are a senior technical writer specializing in API documentation.
Rules:
- Use precise technical English
- Always include Python code examples
- Structure your responses with headings and lists
- Never exceed 500 words per response"""
    },
    {
        "role": "user",
        "content": "Explain how to handle HTTP errors in a REST API."
    }
]

Note an important point for your future applications: the system prompt is managed by the developer, not the end user. Your application’s user never sees it, but all their interactions take place within the framework you established there. This makes it your most powerful control lever.

The user role: the concrete request

The user message contains the specific request. This is the most intuitive role: it represents what the human says to the model, and every new question or instruction from the user becomes a message with the user role. Its apparent simplicity shouldn’t make you forget best practices: be precise in your request, specify the desired format if it differs from the one defined in the system prompt, and provide the data the model needs directly in the message—a text to summarize, figures to analyze. The model cannot fetch what you do not give it.

The assistant role: guiding the response

The assistant role is the most subtle of the three because it has two distinct uses. The first is conversation history: in a multi-turn exchange, the model’s previous responses are reinserted with the assistant role to maintain context. This is how the model “remembers” what it said:

messages = [
    {"role": "user", "content": "What is the capital of France?"},
    {"role": "assistant", "content": "The capital of France is Paris."},
    {"role": "user", "content": "And its population?"}
]

Without the intermediate assistant message, the “its” in the last question would refer to nothing: the API is stateless, and you reconstruct the memory with every call.

The second use is prefilling (prefix): you can end your message list with an assistant message that contains the start of the expected response. The model will continue from this point, as if the first words had already come out of its mouth. This is a powerful technique for controlling the output format:

messages = [
    {"role": "user", "content": "List 3 Python frameworks for the web."},
    {"role": "assistant", "content": "```json\n[", "prefix": True}
]

Note the "prefix": True field: Mistral’s API requires it on this last assistant message to treat it as the start of a response.

Here, the model understands it is writing JSON and will complete the started array, without preamble or introductory sentence. Where a text instruction “respond in JSON” might be ignored, an already-written start to the response leaves little choice.

The tool role: function results

The tool role comes into play during function calling. When the model decides to call an external function—a web search, an API request, a calculation—the result of that function is sent back to it as a tool message, which it then integrates into its response. This role is more advanced and will be covered in dedicated courses; just remember that it exists and complements the main trio.

Build a complete conversation

Let’s now assemble all these elements into a realistic exchange, where the system prompt frames the assistant, where history maintains the thread, and where the last question builds naturally on what came before:

response = client.chat.complete(
    model="mistral-large-latest",
    messages=[
        {
            "role": "system",
            "content": "You are a French culinary assistant. Respond concisely."
        },
        {
            "role": "user",
            "content": "How do I make a classic vinaigrette?"
        },
        {
            "role": "assistant",
            "content": "For a classic vinaigrette, mix 1 spoon of mustard, 3 spoons of olive oil, and 1 spoon of vinegar."
        },
        {
            "role": "user",
            "content": "And for a lighter version?"
        }
    ]
)

Observe the architecture: system first, then a user/assistant alternation that reproduces the flow of the conversation. This order is not decorative—it’s what allows the model to correctly interpret “a lighter version” as a variant of the vinaigrette it just discussed.

Key takeaways

• The system role frames the model’s overall behavior—it’s your most powerful lever
• The user role carries the user’s concrete request
• The assistant role serves as both history and a guide for response format
• The tool role handles function call results
• Message order is crucial: system first, then user/assistant alternation