The instructions a language model receives at runtime come from two places: the developer and the user. System prompts are the developer’s channel.
When an application sends a request to a language model, it passes two separate inputs: a system message and a user message. The system message loads first. It sets conditions for the whole session: the model’s role, what topics it should or shouldn’t address, what output format to use, and whether it should behave as a specific persona. The user message arrives after. In most implementations, models treat system instructions as higher-priority than what the user types.
Where system prompts came from
The role-based message structure (system, user, assistant) was formalized as part of the OpenAI Chat Completions API specification in 2023 and has since become the dominant pattern across hosted language model APIs. Before this, most prompting happened in a single undifferentiated text block. The split introduced a design distinction that matters: the operator (who builds the application) and the user (who interacts with it) now communicate with the model through separate channels, carrying different levels of trust.
What goes inside one
System prompts vary enormously in complexity. A minimal one might say “You are a helpful assistant.” A production one for a customer-facing application might run several hundred words, specifying:
- A persona and name for the assistant
- Which topics the model should and shouldn’t address
- The expected output format (prose or structured JSON)
- Safety constraints and explicit refusal behaviors
- Context about the user’s organization or subscription tier
All of this is written in natural language. There is no separate configuration interface. The developer writes prose, and the model follows it, or tries to. The same base model can appear as a legal research assistant in one deployment and a children’s homework helper in another simply because the system prompt is different.
The instruction hierarchy and its limits
System-over-user priority is learned behavior in modern language models, not a hardwired rule. And it degrades. A 2024 study published at COLM (arXiv:2402.10962) found instruction drift within eight rounds of conversation when testing LLaMA 2 and GPT-3.5. System-level constraints that held early in a session weakened as the conversation grew longer, attributable to attention decay over extended exchanges.
A distinct but related vulnerability is prompt injection: adversarial inputs that attempt to override or extract system instructions. Greshake et al. (2023) demonstrated that when LLMs process external data (retrieved documents, emails, web content), attackers can embed malicious instructions in that content to subvert the original system prompt (arXiv:2302.12173).
Both findings point to the same truth: a system prompt that says “never do X” is a constraint the model has been trained to respect, not a technical enforcement.
What end users don’t see
In most deployed applications, the system prompt is invisible to the person having the conversation. Operators typically instruct the model to keep its system prompt confidential: to decline to repeat it if asked. This confidentiality rests on the model’s instruction-following. A determined user can sometimes infer or partially extract the contents through careful probing.
The opacity has a practical implication for anyone working on prompt engineering within a deployed system. The user prompt sits on top of constraints and formatting rules already set at the system level. Adjusting user messages without knowing what’s already established can produce inconsistent results for reasons that aren’t visible.
Same model, different persona
System prompts are the primary mechanism by which a single base model gets deployed as hundreds of distinct products. The underlying weights are unchanged; what varies is the instruction layer. This is efficient for operators. Model behavior can be customized without retraining, but it also means the apparent identity of an AI assistant is, in most cases, a configuration, not a trained property.
That configuration is written in natural language, which is inherently ambiguous. What the operator intended and what the model interprets are not always the same thing, and neither is visible to the person on the other end of the conversation.
Questions, answered
Is a system prompt the same as a user prompt?
No. A system prompt is written by the developer or operator building an application and takes precedence over user messages. A user prompt is what the end user types during the conversation. The two sit in distinct positions in the model's input structure, and most models are trained to treat the system position as higher-authority.
Can users see the system prompt?
Not by default. In most deployed applications the system prompt is invisible to the person having the conversation. Operators often instruct the model to decline to reveal it if asked, but this is not a technical barrier. It relies on the model's instruction-following and can, in principle, be circumvented.
What happens to system prompt instructions in long conversations?
Research has shown that system-level constraints can degrade over extended dialogs, a phenomenon called instruction drift. A 2024 study found instruction drift appearing within eight rounds of conversation in models including LLaMA 2 and GPT-3.5 (arXiv:2402.10962).
Can a user override the system prompt?
Models are trained to prioritize system instructions, but the hierarchy is not absolute. Adversarial inputs (known as prompt injection attacks) can, in some cases, override or extract system-level instructions. Researchers have demonstrated this against real deployed applications (Greshake et al., arXiv:2302.12173).
Brief is a team of AI associates you direct in plain language. Opening to a small group at a time.
Request access