A system prompt is the highest-authority instruction set given to a large language model that defines its identity, tone, rules, and output format before any user input arrives. It persists across a conversation and outranks ordinary user messages in the model's instruction hierarchy.
What Is a System Prompt?
A system prompt is a block of instructions supplied to a large language model (LLM) that establishes how the model should behave throughout a conversation. It is set by the application before the end user types anything, and it typically governs the model's persona, allowed and disallowed actions, communication style, and the structure of its responses. Unlike an ordinary question, a system prompt is not meant to be answered; it is meant to be obeyed.
In modern chat-style APIs, a conversation is represented as a sequence of messages, each tagged with a role. The system prompt occupies the highest-privilege role available to an application and is generally placed first. Because models are trained to weight system instructions above later user input, the system prompt acts as a persistent governing layer that shapes every turn of the dialogue rather than a single one-off request.
The concept emerged with instruction-tuned chat models and is now standard across major providers. OpenAI documents it through message roles and its public Model Spec, while Anthropic exposes it through a dedicated system parameter in the Messages API. The underlying idea is consistent: separate the durable rules that define the assistant from the changing requests that users make of it.
- Set by the developer or platform, not the end user.
- Persists across all turns of a single conversation or session.
- Defines identity, rules, tone, and output format rather than asking a question.
- Carries higher instruction priority than ordinary user messages.
The Message Role Hierarchy: System, Developer, User, Assistant
Chat completion APIs structure input as a list of messages, each carrying a role that signals its purpose and authority. The four roles most developers encounter are system, developer, user, and assistant. The system role sets high-level behavior and identity. The user role carries the end user's actual questions and requests. The assistant role holds the model's own replies, and developers can also supply prior assistant messages as few-shot examples of the desired output.
OpenAI introduced the developer role with its o1 reasoning models in December 2024, where reasoning models support developer messages rather than system messages to align with the chain of command described in the Model Spec. In its Responses and Chat Completions interfaces, the developer role carries application-specific instructions, while the system level is defined as rules set by the model provider. Anthropic's Messages API takes a slightly different shape: it exposes a top-level system parameter and a messages array containing user and assistant turns.
A common practical pattern is a single system message describing overarching purpose, followed by one or more developer messages carrying dynamic application context, ending with the user message that triggers the response. Tool or function results are usually returned through their own role so the model can distinguish model-generated text from external data.
- System: highest-level behavior, identity, and policy for the application.
- Developer: application-specific rules and dynamic context, ranked below platform/system.
- User: the end user's live questions and instructions.
- Assistant: the model's responses, also usable as worked examples.
- Tool/function: results from external calls, kept distinct from user text.
What System Prompts Control: Identity, Tone, Rules, and Format
System prompts operate along four broad axes. The first is identity: who the assistant is, what domain expertise it should adopt, and what role it plays. Anthropic describes setting a role in the system prompt as a way to focus the model's behavior and tone for a use case, noting that even a single sentence can make a meaningful difference to the depth and framing of answers.
The second axis is tone and style: brevity versus elaboration, formality, reading level, and whether the assistant uses lists, prose, or code. The third is rules and constraints: topics to refuse, safety boundaries, escalation behavior, and instructions never to reveal confidential context. The fourth is output format: requiring JSON that matches a schema, a fixed section structure, citation conventions, or a specified language.
Keeping these durable concerns in the system prompt and leaving task-specific details in the user message is a widely recommended separation. It lets a single application serve many different user requests while preserving a consistent voice, consistent safety behavior, and machine-parseable output.
- Identity: persona, expertise, and role the model should adopt.
- Tone and style: length, formality, reading level, and structure.
- Rules: refusals, safety limits, and confidentiality requirements.
- Format: JSON schemas, required sections, language, and citation style.
System Prompt vs User Prompt vs Developer Message
The clearest way to distinguish these is by authorship, lifespan, and authority. The system prompt is authored by the platform or application, is long-lived across the conversation, and holds high authority. The user prompt is authored by the end user, changes with every turn, and holds lower authority. A useful analogy treats the system prompt as a job description and user prompts as the individual tasks assigned within that role.
The developer message sits in between. It lets an application inject its own rules and runtime context, such as the current user's account tier or retrieved documents, without exposing that text to user-level authority. In OpenAI's framing, system instructions come from the model provider, developer instructions come from the application builder, and user instructions come from the person at the keyboard, with authority decreasing in that order.
This separation is what makes consistent, secure behavior possible. Because user-supplied text is treated as lower authority, an application can rely on its system and developer instructions to hold even when a user tries to talk the model out of them, at least to the extent the model has been trained to respect that ordering.
- System prompt: platform or app authored, persistent, high authority.
- Developer message: app authored, carries dynamic context, mid authority.
- User prompt: end-user authored, per-turn, lowest authority among the three.
- Mental model: system is the job description, user prompts are the tasks.
How Models Prioritize Instructions and Why Order Matters
Instruction priority is not merely a convention; it is something models are explicitly trained to follow. OpenAI's 2024 paper The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions describes teaching models to treat higher-privilege instructions as authoritative and to selectively ignore lower-privilege text that conflicts with them. The motivation is that an LLM which weights a developer's system prompt the same as untrusted user or third-party text is vulnerable to having its instructions overwritten. Applied to GPT-3.5, the method increased robustness even to attack types not seen during training, with minimal degradation to standard capabilities.
OpenAI's public Model Spec formalizes this as a chain of command. As of the 2025-12-18 version, it defines five authority levels in descending order: Root, System, Developer, User, and Guideline. Root-level rules are foundational and cannot be overridden by system messages, developers, or users; system and developer instructions outrank user instructions; and guideline-level defaults sit at the bottom and can be implicitly overridden. Higher authority always wins when instructions conflict.
Order matters in two senses. Across roles, the role hierarchy decides which instruction prevails in a conflict. Within a single prompt, placement and explicitness still influence behavior, since instructions can be diluted by long context or contradicted later in the same message. Writing the most important constraints clearly and at the appropriate authority level is therefore both a correctness and a safety concern. Research such as Control Illusion (2025) also cautions that instruction hierarchies are not reliably enforced and can fail even on simple, clearly verifiable formatting conflicts.
- Priority is trained into the model, not just a documentation convention.
- OpenAI's Model Spec (2025-12-18) lists Root > System > Developer > User > Guideline.
- Root rules are inviolable; higher authority overrides lower on conflict.
- Hierarchies are imperfect and can fail under conflicting or adversarial inputs.
System Prompts, Safety Guardrails, and Prompt Injection Risks
Because system prompts carry the application's rules, they are a primary line of defense and a primary target. Prompt injection is an attack in which adversarial text, often arriving through user input or through retrieved documents and tool outputs, attempts to override the system prompt's instructions. A classic example is a web page that contains hidden text instructing the model to ignore its previous instructions and exfiltrate data. The instruction hierarchy exists in large part to make models resistant to exactly this.
Training models to prioritize privileged instructions measurably increases robustness to prompt injection and jailbreaks, including attack types not seen during training, while imposing only minimal cost to ordinary capabilities. However, no current model is immune. Defense in depth remains necessary: validating and sandboxing tool outputs, separating untrusted retrieved content from instructions, limiting the model's permissions, and not relying solely on the system prompt to keep secrets, since determined users may still extract or override parts of it.
A related risk is over-trusting third-party content. When a model browses the web or reads files, that text should be treated as data at user-or-lower authority, never as privileged instructions. Treating retrieved content as commands is one of the most common sources of injection vulnerabilities in agentic systems.
- Prompt injection tries to override the system prompt via user or retrieved text.
- Instruction-hierarchy training improves but does not guarantee robustness.
- Treat tool outputs and retrieved documents as untrusted data, not instructions.
- Do not depend on the system prompt alone to store secrets or enforce permissions.
Writing Effective System Prompts: Patterns and Anti-Patterns
Effective system prompts are specific, ordered, and scoped to durable behavior. A reliable pattern is to define the role first, then the rules and constraints, then the output format, and to keep changing, task-specific details in the user or developer message. Assigning a concrete role tends to outperform vague instructions, and explicit formatting requirements, including an example of the expected output, improve consistency for machine-parseable responses.
Constraints should be stated positively where possible and unambiguously where refusals are required. When exact formatting matters, providing a short schema or a worked example in an assistant message reduces drift. For long or rule-heavy prompts, grouping instructions under clear headings helps the model locate the relevant rule during a given turn.
Common anti-patterns include overloading the system prompt with transient task data that belongs in the user message, writing contradictory rules that force the model to guess, assuming the system prompt is secret, and relying on it to block behaviors that the model has not been trained to refuse. Vague personas, unbounded length, and instructions that conflict with the provider's own policies also tend to degrade reliability.
- Pattern: role first, then rules, then output format; keep tasks in user messages.
- Pattern: give concrete personas and worked examples for strict formats.
- Anti-pattern: stuffing per-request data or contradictory rules into the system prompt.
- Anti-pattern: assuming the system prompt is confidential or self-enforcing.
System Prompts vs Persistent Memory and Context
A system prompt is conversation-scoped: it governs behavior within a session but does not, by itself, remember facts across separate conversations. Persistent memory refers to mechanisms that carry information between sessions, such as stored user preferences or facts a system reinjects into later prompts. Retrieval-augmented context, by contrast, dynamically pulls relevant documents into a given turn. All three feed the model's context window, but they serve different purposes.
In practice these layers combine. A system prompt sets the unchanging rules of the assistant, memory supplies durable user-specific facts, and retrieval supplies the documents relevant to the current question. AI memory and second-brain applications focus on the retrieval and memory layers, storing notes and documents and surfacing them on demand, while a system prompt still governs how the assistant phrases and structures what it returns.
Distinguishing these concepts matters for both design and security. Memory and retrieval typically introduce content of lower authority than the system prompt, so the same injection cautions apply: information recalled from memory or retrieved from documents should be treated as data, not as privileged instructions that can rewrite the assistant's rules.
- System prompt: per-session rules and identity, not cross-session memory.
- Persistent memory: facts and preferences carried between conversations.
- Retrieval: documents pulled into the context window for the current turn.
- Memory and retrieved content are lower-authority data, not instructions.
Key takeaways
- A system prompt is the highest-authority instruction layer an application sets to define an LLM's identity, tone, rules, and output format before any user input.
- Chat APIs use message roles (system, developer, user, assistant); authority decreases from system to developer to user, and models are trained to honor that order.
- OpenAI's Model Spec (2025-12-18) defines a five-level chain of command: Root, System, Developer, User, Guideline, with higher levels overriding lower ones.
- The instruction hierarchy improves resistance to prompt injection and jailbreaks but is imperfect, so treat user input and retrieved content as untrusted data.
- Keep durable rules in the system prompt and per-request details in the user message; do not assume the system prompt is secret or self-enforcing.
Frequently asked questions
Related terms
Related reading
Sources
- OpenAI Model Spec (2025-12-18): Chain of Command
- The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions (arXiv:2404.13208)
- Anthropic: Prompting best practices (system prompts and role prompting)
- Control Illusion: The Failure of Instruction Hierarchies in Large Language Models (arXiv:2502.15851)
- OpenAI: Inside our approach to the Model Spec
Put the idea into practice
MemX is an AI memory agent built on these ideas: store anything, skip the folders, and find it again by asking in plain English.
Try MemX Free