System Prompts and Message Roles
The Pedal Point assistant answers a question about a competitor's e-bikes, writes a limerick when asked, and replies in long paragraphs on a phone screen. None of that is a model failure. Nobody told it what its job was. That is what the system prompt is for.
The rule
The system prompt sets the job; user messages bring the requests.
Chat models take a list of messages, each with a role:
- system: standing instructions from you, the developer. Who the assistant is, what it may and may not do, how to answer.
- user: what the customer typed.
- assistant: the model's earlier replies, resent so it can follow the conversation.
[
{"role": "system", "content": "You are Pedal Point's support assistant..."},
{"role": "user", "content": "Can I return a helmet?"},
{"role": "assistant", "content": "Yes, if it is still sealed..."},
{"role": "user", "content": "What if I opened it?"}
]This is the input format. The exact shape varies by provider (some take the system prompt as a separate field), but the idea is the same everywhere.
A good system prompt covers three things:
- Role and behaviour. Who the assistant is and the tone it uses.
- Constraints. What is in and out of scope, what it must never do, and what to do when unsure.
- Format. Length, structure, language.
Be specific. "Be helpful" changes nothing. "If the reference text does not answer the question, say so and offer a human" changes behaviour.
A few more habits help. Put the most important rule where it cannot be missed. Give a reason for unusual rules ("never promise refunds, because only staff can approve them"), since models follow rules better when they understand them. Keep the prompt short enough to read in one go: every word is resent on every call.
The shortcut
Write every system prompt as Role, Rules, Format, then read it and ask: "Could a new employee follow this without asking me anything?"
Role
"You are the support assistant for Pedal Point, an online bike shop. Be friendly and plain-spoken."
The trap is treating the system prompt as a vault. Users can sometimes talk the model into revealing or ignoring it, so never put secrets in it, and enforce anything critical in code too.
Drills
Answer fast — trust the rule.
Which role carries the developer's standing instructions?
Why does the app resend earlier assistant messages?
Which instruction is most likely to change the assistant's behaviour?
Where should the shop's payment API key go?
Remember
- The system prompt sets the job; user messages bring the requests.
- Role, Rules, Format — then the new-employee test.
- No secrets in prompts; enforce critical rules in code.