Module 3 of 11 · Advanced · 9 min read
Roles and system prompts
What system prompts and personas really do, and how to write one that holds up across a whole conversation.
- 1The system prompt sets persistent behaviour; user messages carry the task.
- 2Roles shape tone, perspective and conventions more than raw knowledge.
- 3A good system prompt covers purpose, audience, behaviours, boundaries and formats.
- 4Never put secrets in a system prompt: assume users can extract it.
01System prompt versus user prompt
Most chat APIs let developers send a system (or developer) message before the conversation. Models are trained to treat it as standing instructions that apply to every turn, and to give it priority over conflicting user requests. In consumer apps, custom instructions and project instructions play a similar role.
Use the system prompt for things that should always be true: who the assistant is for, its scope, tone, formatting defaults, tools and rules. Put the specific task and material in the user message.
02What a role does and does not do
Telling a model 'You are a senior tax accountant' does not give it knowledge it lacks. What a role does well is set the perspective, vocabulary, conventions and level of caution you want: an editor notices different things than a marketer; a security reviewer asks different questions than a product manager.
Make roles specific and tie them to the job. 'You are reviewing this pull request as the engineer who will be on call for it' does more than 'You are an expert programmer'.
03Anatomy of a strong system prompt
Write it like an onboarding document for a capable new hire, not a list of commands.
- Purpose: what the assistant is for, in one or two sentences.
- Audience: who it talks to and what they know.
- Behaviours: how to handle common situations, including uncertainty and missing information.
- Boundaries: what is out of scope and what to do instead, such as escalating to a human.
- Format defaults: length, structure, markdown or plain text.
- Tools and sources: what it can use and when.
04Example: a support assistant
Notice the reasons attached to rules, and the explicit instructions for the awkward cases.
05Conflicts and the instruction hierarchy
Models generally follow system instructions over user ones, and both over instructions that appear inside documents or tool results. That ordering helps, but it is not a security boundary: well-crafted user messages or pasted content can still override weak system prompts.
Avoid contradictions inside your own prompt. 'Be concise' plus 'always explain your reasoning in detail' forces the model to guess which you meant. Resolve conflicts explicitly: 'Be concise, except when the user asks why.'
06Pitfalls
System prompts tend to grow by accretion. Treat them like code and review them.
- Bloat: hundreds of rules accumulated over time, many contradictory. Prune regularly and re-test.
- Shouting: ALL CAPS and 'CRITICAL' can make current models over-apply a rule. Explain instead.
- Secrets: API keys, internal URLs or confidential logic in a system prompt can be extracted. Keep them in your code.
- Persona over substance: a vivid character with no instructions for real situations produces charming, unhelpful answers.
Finished reading?
Mark it complete to track your progress, then test yourself with the Advanced Prompting quiz.