Roles: System, User, Assistant

Grok’s Role System

Conversations with Grok revolve around three distinct roles that structure the exchange. Every message sent to the model carries a role that indicates its function in the conversation. Understanding these roles is essential for writing effective prompts and getting consistent responses.

Grok’s API uses a message format where each entry is an object containing a role field and a content field. This architecture lets you control the model’s behavior precisely.

The System Role (or Developer)

The system message is the first message in the conversation. It defines the model’s global behavior: its personality, constraints, area of expertise, and the rules it must follow throughout the exchange.

{
  "role": "system",
  "content": "You are a cybersecurity expert. You always respond in English, concisely. You cite sources when relevant. You refuse to provide instructions for carrying out attacks."
}

Grok also accepts the developer role as an alias for system. The two are interchangeable and produce the same effect.

What to Include in the System Message

• Identity: who the model is in this conversation (expert, assistant, translator…)
• Constraints: language, response format, length, tone
• Prohibitions: what the model must not do
• Business context: the domain, technical terms to use

Best Practices

• Always place the system message first
• Be exhaustive upfront: it is more effective to specify everything in the system message than mid-conversation
• Use clear sections (with dashes or headings) to organize your instructions

The User Role

user messages represent interventions by the human user. This is the most intuitive role: it contains your questions, requests, and input data.

{
  "role": "user",
  "content": "Analyze this network architecture and identify the three most critical vulnerabilities."
}

The content of a user message can be a simple text string or an array of objects to combine text and images (we will cover this in lesson 4).

Tips for User Messages

• Formulate one request per message when possible
• If you have multiple related requests, number them
• Provide necessary data directly in the message

The Assistant Role

assistant messages contain the model’s responses. You do not write these yourself under normal circumstances: Grok generates them. However, you can include them in your conversation history to guide the model.

{
  "role": "assistant",
  "content": "Here are the three identified vulnerabilities: ..."
}

Why Pre-fill Assistant Messages?

Including fake assistant messages in your history is a powerful technique:

• Guide style: show the model the expected response format
• Maintain consistency: simulate a past conversation so the model continues in the same tone
• Few-shot in context: create question/answer pairs as examples

The Impact of Role Structure

The order and organization of messages directly influence response quality. Here is the recommended structure:

[
  {"role": "system", "content": "Global instructions..."},
  {"role": "user", "content": "First user message..."},
  {"role": "assistant", "content": "Model response..."},
  {"role": "user", "content": "Next message..."}
]

Grok’s Chat Completions endpoint is stateless: it keeps no history between requests. You must include all conversational context in every call. This means that if you want a 5-turn conversation, your 5th request must contain the previous 4 turns.

Hands-On Practice

Test the impact of the system message by sending the same question with two different configurations:

Configuration A:

[
  {"role": "system", "content": "You are a math teacher for high school seniors."},
  {"role": "user", "content": "Explain limits."}
]

Configuration B:

[
  {"role": "system", "content": "You are a senior software engineer specialized in distributed systems."},
  {"role": "user", "content": "Explain limits."}
]

The same question produces two radically different responses depending on the defined system role. The teacher will talk about mathematical limits, the engineer about rate limiting and quotas.

Key Takeaways

• Three roles structure conversations: system (or developer), user, and assistant
• The system message defines global behavior and must be placed first
• The API is stateless: include the entire history in every request
• Pre-filling assistant messages lets you guide response style and format
• A well-written system message is often more effective than multiple corrections mid-conversation