A system prompt is a set of instructions, usually written by the developer or organisation, that tells an AI model how to behave throughout a conversation. It defines the assistant’s role, rules, tone, knowledge boundaries and output format. Users typically do not see it, but it shapes every response. System prompts are one of the most important tools for turning a general LLM into a specific product.
Key takeaways
- System prompts set persistent behaviour; user prompts make individual requests.
- Models are trained to give system instructions higher priority than user messages.
- A good system prompt covers role, audience, rules, knowledge sources, format and edge cases.
- System prompts are not a secure secret store; they can sometimes be revealed.
- They should be versioned and tested like code.
A system prompt explained in simple terms
When a company hires a receptionist, it gives a briefing: who we are, how to greet visitors, what you can and cannot share, when to call a manager. Visitors never see that briefing, but it shapes every interaction. A system prompt is that briefing for an AI assistant.
System prompt vs user prompt
| Aspect | System prompt | User prompt |
|---|---|---|
| Written by | Developer or organisation | End user |
| Scope | Whole conversation | Single request |
| Purpose | Role, rules, format, boundaries | Specific question or task |
| Priority | Generally higher | Works within system rules |
| Visibility | Usually hidden | Visible |
Most chat APIs mark messages by role: system (or developer), user and assistant. Models learn during instruction tuning and preference training to follow this hierarchy.
What to include in a system prompt
- Role and purpose: who the assistant is and what it is for.
- Audience: who it serves and their expertise level.
- Knowledge rules: use only provided documents; say when information is missing.
- Behaviour rules: what to do, what to avoid, when to escalate to a human.
- Tone and style: formal or casual, length, language, spelling.
- Output format: structure, markdown, or structured output such as JSON.
- Edge cases: off-topic questions, abusive messages, sensitive topics.
A worked example
“You are the support assistant for QueryFeedz, a publishing platform for writers.
Audience: writers and editors with basic technical knowledge.
Rules: Answer only using the help-centre articles provided in the context. If the answer is not in the articles, say you don’t know and offer to connect the user with the support team. Never promise refunds or discuss other customers’ accounts.
Style: friendly, clear, under 120 words, UK English. Use numbered steps for instructions and end with the most relevant article link.”
This prompt sets role, audience, a grounding rule that reduces hallucination, limits, style and format in a few lines.
Best practices
- Be clear and specific; explain the reason behind important rules.
- Organise with headings or tags so sections are easy to follow.
- Put stable content first to benefit from prompt caching.
- Include a few examples if format matters (few-shot prompting).
- Test with real and adversarial user messages.
- Keep it as short as possible while covering what matters; very long prompts can dilute key rules.
Security limits
- Prompt injection: users, or text inside documents and web pages, can try to override instructions (“ignore previous instructions”).
- Prompt leakage: users may coax the model into revealing its system prompt, so never put passwords, API keys or confidential data in it.
- Defence in depth: enforce critical rules in application code, permissions and filters, not only in the prompt.
Limitations
- Models do not follow system prompts perfectly every time.
- Conflicting or vague rules produce inconsistent behaviour.
- Long conversations can weaken adherence.
- Different models interpret the same system prompt differently.