Every message you send to a chatbot is only part of the full picture. Behind the scenes, there's usually another layer of instructions — invisible to you — quietly shaping how the model behaves before your message even arrives. That hidden layer is the system prompt, and understanding how it differs from the user prompt clarifies a lot about how AI products are actually built. Here's the breakdown.
The Basic Definitions
- System prompt: A set of instructions provided to the model, usually by the developer or platform building the AI application, that establishes the model's overall behavior, role, tone, rules, and constraints — typically before any conversation with the user even begins, and typically invisible to the end user.
- User prompt: The actual message a person types into the chat — their specific question, instruction, or request in that moment.
Both get combined into the model's overall context (as covered in the earlier "Prompt vs. Completion" post), but they serve very different purposes and usually come from different sources.
Who Writes Each One
This is the clearest distinction: developers write system prompts, users write user prompts.
A company building a customer support chatbot might write a system prompt like: "You are a helpful, concise support agent for [Company]. Only answer questions related to our products. If asked about something unrelated, politely redirect the conversation. Never make promises about refunds without escalating to a human agent."
The end user never sees this. They simply type something like "My order hasn't arrived yet" — that's the user prompt — and the model responds shaped by both layers simultaneously: the hidden system-level rules, and the specific question just asked.
What System Prompts Typically Control
System prompts tend to establish the more stable, persistent aspects of a model's behavior across an entire conversation:
- Role or persona — "You are a friendly cooking assistant" (connecting back to the role-based prompting post)
- Scope and boundaries — what topics the model should or shouldn't engage with
- Tone and style guidelines — formal vs. casual, concise vs. detailed, use of emoji or not
- Formatting rules — how responses should generally be structured
- Safety and behavioral guardrails — restrictions on certain types of content or requests
- Context about the product or use case — background information the model should assume is true throughout the conversation, like company policies or product details
Because the system prompt is typically set once and applies throughout an entire session, it creates a kind of consistent operating context that every user message gets interpreted within.
What User Prompts Typically Control
User prompts are the dynamic, changing part of the interaction — the actual specific ask in the moment:
- The immediate question or task — "Summarize this article," "Debug this code," "Write me an email"
- Specific details relevant to that particular request — data, context, or constraints for this one message
- Follow-up clarifications or refinements — as a conversation continues, each new user message adds to the evolving context
Where the system prompt sets the stage once, user prompts are the ongoing dialogue happening on that stage.
How They Combine in Practice
Even though they come from different sources and serve different purposes, both ultimately get processed together as part of one continuous sequence of tokens that the model reads before generating a response (as covered in the earlier posts on tokens and how generation works). The model doesn't experience them as fundamentally different types of input in some deep technical sense — but well-designed systems structure this combination carefully, generally treating system-level instructions as a stronger, more persistent influence that user messages operate within, rather than override entirely.
This is part of why, for example, a customer support bot with a system prompt restricting it to product-related topics will typically still (mostly) decline to answer an unrelated user question, even if the user asks directly — the system-level instruction is designed to take precedence over conflicting user requests.
A Simple Analogy
Think of the system prompt like a job description and company handbook given to a new employee before their first day — it sets expectations, boundaries, and tone for how they should generally operate. The user prompt is like a specific customer walking up and asking a particular question. The employee (the model) responds to that specific question, but always within the framework established by that handbook, not from a blank slate each time.
Why This Separation Matters
Splitting instructions this way solves a real practical problem: how do you build a consistent, specialized AI product on top of a general-purpose foundation model (covered in the earlier foundation models post) without requiring every single user to write out detailed instructions themselves?
Without a system prompt, every user would need to explain, in every conversation, exactly how they want the model to behave, what topics are relevant, and what tone to use — which is neither practical nor consistent. The system prompt lets developers bake that configuration in once, so users can just ask their actual question and get appropriately shaped responses immediately.
This is also part of how many different specialized AI products can be built from the same underlying foundation model — a coding assistant, a customer support bot, and a creative writing tool might all be powered by the same base model, differentiated largely by very different system prompts layered on top.
System Prompts and Safety
System prompts also play an important practical role in shaping safer, more appropriate model behavior for a specific application — restricting scope, discouraging certain types of responses, or adding disclaimers where relevant. That said, it's worth noting that a system prompt is a strong steering mechanism, not an absolute, unbreakable guarantee. Well-designed systems combine system-level instructions with other safeguards, since a system prompt alone isn't always sufficient to prevent every possible unwanted behavior, especially against a sufficiently adversarial or creative user prompt trying to work around it.
Can Users See or Change the System Prompt?
Typically, no — system prompts are usually hidden from the end user by design, since they represent the application developer's configuration choices rather than something meant to be part of the visible conversation. That said, this varies by platform: some tools intentionally expose or allow customization of system-level instructions (for example, API access often lets developers write their own system prompts, and some consumer products offer limited customization options), while consumer chat apps more often keep this layer entirely behind the scenes.
The Bottom Line
System prompts and user prompts are two different layers of input that combine to shape a language model's response: the system prompt is typically written by developers to establish persistent role, tone, scope, and behavioral rules for an entire application, while the user prompt is the specific, changing request a person types in the moment. Together, they let a single general-purpose foundation model be shaped into countless different specialized applications — each with its own consistent personality and boundaries — without requiring every individual user to configure that behavior themselves.