TL;DR
A conversation is a list of messages, each tagged with a role: system
(the rules), user (what the person types), and assistant (what the model
said earlier). The system message is your main steering wheel — it sets behavior
without changing the model's underlying knowledge.
The idea
A conversation with an LLM is a list of messages, each tagged with a role. Three roles matter for now:
| Role | Who | Purpose |
|---|---|---|
system | You (the builder) | Sets the rules of the interaction. Read before every turn; never shown in the transcript. |
user | The person | Whatever they type. |
assistant | The model | Whatever the model said earlier in the same conversation. |
The system message is where personality, scope, and constraints live. It's the single most cost-effective lever you have: one well-written paragraph can be the difference between a vague chatbot and a focused support agent.
Analogy
The system message is like the briefing you give a new hire before their first shift: "You work the returns desk. Be warm but firm. Escalate anything over $500." You're not teaching them new facts — you're framing how they should act.
What the system message changes
The system message changes which facts the model reaches for and how it presents them — never the underlying knowledge. Same model, same facts; only the framing shifts:
- Tell it "be concise" and it picks shorter words.
- Tell it "explain it to a five-year-old" and it reaches for analogies.
- Tell it "answer only in JSON" and it shapes the output structure.
That's why a single model can sound like a terse engineer or a patient teacher depending on one line of instruction — exactly the swing you'll run in the demo further down.
Example: few-shot prompting
Few-shot examples — short demonstrations placed inside the system message — work because the model uses them as a template for what a good response looks like. The model never sees "this is an example"; it just sees a pattern and imitates it.
System: You classify support tickets. Reply with one word: billing,
technical, or other.
Example 1 — "My card was charged twice" → billing
Example 2 — "The app crashes on launch" → technical
User: I can't log in after the update
Assistant: technical
Two demonstrations were enough to lock in both the format (one word) and the judgment (which category). That's the power of the system role.
Try it yourself
Below is the same user question sent through three different system prompts at the same time. The model is identical; only the personality differs.
Common mistake
A system prompt can't make the model know something it never learned. "You are an expert on our 2026 pricing" won't conjure your actual prices — you still have to supply that text (via the prompt, a tool, or a knowledge base). The system role shapes behavior, not knowledge.
Key takeaways
Key takeaways
- A conversation is a list of role-tagged messages:
system,user,assistant. - The
systemmessage sets the rules and is read before every turn. - Few-shot examples in the system message teach format and judgment by pattern.
- System prompts steer behavior — they don't add new facts.
Go deeper: writing a system prompt that holds up
A few patterns that consistently help:
- Lead with the role and scope. "You are a billing support agent for Acme. You only handle billing." A clear boundary prevents the model from wandering.
- State the format explicitly. If you need JSON, bullet points, or a single word, say so — and show one example.
- Give it an out. "If you don't know, say so and offer to escalate." This reduces confidently-wrong answers.
- Put durable rules in
system, notuser. Anything that should hold for every turn belongs in the system message; the user message is for the specific request.