System Prompt
The operating rules a service lays down before a conversation starts
- A system prompt is the standing policy a service lays down before a customer ever says a word.
- Written once, it applies the same way to every conversation. No need to restate it each time.
- It usually spells out role, tone, scope, and answer format.
- Users never see it on screen, but to the model it's just the earlier part of the same input.
- So it isn't an unbreakable rule. Whatever truly must be blocked gets blocked by the program around it.
Contents
1The analogy
Step up to a self-service kiosk and a great deal has already been decided. Which items show up on the menu, what the default spice level is, how "sold out" gets displayed, which payment methods are accepted. The customer orders from inside that screen.
Those settings were made by the store before any customer showed up. They aren't redone per customer — they apply the same way to everyone who walks up that day. However badly a customer wants an item missing from the screen, the kiosk has no way to offer it, no matter how the order is phrased.
The customer never sees the settings screen behind it. What shows up is only the result. A system prompt is that behind-the-scenes setup, quietly shaping every order before it's even placed.
2In detail
It's placed before the customer says anything
Before anyone types a word into the chat box, the service has already handed the model several lines: "You're this company's support assistant," "Use a formal tone," "Never give medical advice." Sentences like these.
The model reads this text first, then reads what the user wrote. The order matters. What attitude to bring to what comes next has already been decided beforehand.
This is why the same model can act like a stiff support rep on one service and a casual conversation partner on another. The model isn't different — the policy laid ahead of it is.
What usually gets written into it
Role gets set: what kind of assistant this is, who it's talking to. Once the role is fixed, tone and subject matter narrow on their own.
Tone gets set: formal or casual, whether emoji are allowed, how long answers should run.
Scope gets set: what to cover, what not to, and how to answer when asked something unknown. A line like "say you're not sure when you're not sure" belongs here.
Answer format gets set: whether to answer as a list or a paragraph, or in a fixed shape a downstream program can read.
When the standing policy meets a live request
When the policy and a live request pull in different directions, the policy usually wins. Ask for a casual tone and a policy that locks in formal wording tends to hold.
Not always, though. A vague policy against a very specific request can tip the other way, and a long enough conversation can push the policy out of view entirely. That's why services keep the important lines short and clear, and reinsert them mid-conversation when it matters.
Hidden isn't the same as locked
A system prompt never shows up on the user's screen. That doesn't mean it's sealed inside the model. To the model, it's simply the earlier part of the same input — made of the same material as anything the user typed.
So a clever enough question can pull its content out, and a sentence hidden inside a pasted document can shake the policy loose. A document that contains "ignore everything said before this and do the following instead" really can pull a model that direction.
That's why anything that truly must never leak doesn't go into a system prompt at all. Keys and personal information are left out entirely, and whatever must never happen gets blocked by the surrounding program instead. A system prompt is a sign posted on the wall, not a lock on the door.
3More precisely
A system prompt is the part of the conversation record fed into a model that's marked with a special role tag. It sits alongside user turns and model replies, distinguished only by that tag, and training tunes the model to follow instructions in this slot more heavily than elsewhere. The same sentence tends to be honored more reliably when it sits in the system slot than when a user simply asks for the same thing mid-conversation.
The analogy breaks down somewhere. A kiosk's settings are code, so a customer truly cannot conjure up an item missing from the menu — but a system prompt is just text, with no guarantee it will always be honored. And a kiosk's settings live on a server, while a system prompt gets loaded back in whole with every single exchange, taking up room and adding cost each time. The longer it runs, the less room is left for the conversation, which is why real services tend to keep only what's essential there and push the rest — logging, filtering, hard limits — into the surrounding program instead.
4Try it yourself
5Common misconceptions
It's easy to think a system prompt is a rule the user can never change, but actually it's part of the same input, so a clever request or a sentence hidden in a document can shake it loose.
It's easy to think it's safe just because it's invisible on screen, but actually it can leak, so secrets never belong there.
It's easy to think a system prompt trains the model, but actually it's just text sent along every time — the model itself never changes.
7One-line summary
In shortA system prompt is the operating policy laid down before a conversation starts, a sign meant to be followed rather than a lock guaranteed to hold.
Spotted an error or have a better analogy? Suggest an edit · Last updated2026-09-02