Glossary
System prompt
A system prompt is a set of standing instructions sent to a model ahead of your conversation, usually written by whoever built the tool, setting its role, its tone, its rules and what it will not do.
In plain terms
It is the briefing a temporary member of staff gets before the shift starts. You never see it, it arrives before anything you say, and it explains a great deal about why the same underlying model behaves so differently in two products. Most assistants also let you write a short one of your own, usually presented as custom instructions or preferences, which is the same mechanism with you as the author.
Why it matters
It is the single largest reason two tools built on the same model feel nothing alike, so when a product impresses you it is often this rather than the model you are admiring. It is also the cheapest lever you personally have. Setting your own standing instructions takes five minutes once and stops you retyping the same preferences into every conversation for a year. And it is a place people put things they should not, because it looks private and is not.
How it works
It is ordinary text placed before your messages, and the model reads it as part of the same conversation rather than as a separate kind of thing. There is no enforcement machinery behind it. It works because the model was trained to follow instructions and because coming first gives it weight, which is influence rather than control.
Several of them are usually stacked. The provider sets one covering broad conduct, the company that built the product adds another describing the job, and your own preferences sit on top. When these conflict the earlier and more privileged ones generally prevail, and generally is the honest word: conflicts are resolved by a model weighing instructions, not by a rule engine.
It is paid for on every single request. A long standing brief is sent again with each message and consumes part of the same fixed space your documents and conversation need. This is one of the reasons a product that seemed cheap in testing can cost more than expected in use, and a reason to keep your own instructions short and specific.
It is not secret and it is not a security boundary. People routinely persuade assistants to reveal or disregard theirs, and any material the model reads afterwards can contain instructions that compete with it. Anything genuinely confidential does not belong there, and any rule that must hold, such as who may see what, has to be enforced in code outside the model.
Your own instructions are among the most under-used features an assistant offers. Tone, length, format, what to leave out, what to always include, which conventions to follow: written once, they apply to everything afterwards. The habit worth forming is that anything you have typed into three separate conversations belongs in the standing brief instead.
A short standing brief, and what each line is really doing
Seen in the wild
Set your own standing instructions once in an assistant's settings, then notice over a fortnight how much you have stopped retyping at the start of conversations.
ChatGPTAttach a standing brief to a body of work rather than to a single thread, so the same rules and background apply to every conversation inside it.
ClaudeAdd an assistant step to an automation and write its instructions yourself, which is the same mechanism with you in the position the vendor usually occupies.
n8n
Common misconceptions
People assume
It is hidden, so what I put there is private.
In fact
Assume anything in it can be recovered. Getting an assistant to reveal or paraphrase its own brief is a well-known pastime, and no product can promise otherwise. Credentials, internal reasoning you would not publish, and anything commercially sensitive belong somewhere else entirely.
People assume
A rule in the system prompt is a rule the model cannot break.
In fact
It is a strong influence with no guarantee behind it. Long conversations drift, and material the model reads later can carry instructions of its own that compete with yours. Where a rule must hold every time, it has to be checked in code after the model has answered rather than requested before.
People assume
Custom instructions are a different feature.
In fact
Same mechanism, different author. The provider writes one, the product builder writes another, you write a third, and all of them arrive as text ahead of your message. Recognising that they are one thing makes it obvious why yours can be overruled by the layers beneath it.
Telling them apart
System prompt vs Prompt
System prompt
Standing. Written once, sent ahead of everything, and about how to behave in general.
Particular. Written each time, and about what you want right now.
If you find yourself typing the same sentence into a third conversation, it was never a prompt. Move it up.
System prompt vs Guardrails
System prompt
Asks the model to behave a certain way. Flexible, immediate, and defeated by a sufficiently determined conversation.
Checks and blocks outside the model. Rigid, harder to build, and not subject to persuasion.
Anything embarrassing gets an instruction. Anything that must never happen gets code. Confusing the two is how a rule that mattered turns out to have been a polite request.
Questions
- Can I see the system prompt of a tool I use?
- Sometimes, and not dependably. A few vendors publish theirs, some will describe it on request, and models can often be induced to paraphrase their own. For evaluation the more useful question is whether the vendor will tell you what rules the assistant is operating under, since that is the specification for its behaviour.
- What should I put in my own standing instructions?
- Preferences you would otherwise repeat: the language and spelling you use, how long you want answers, the format you prefer, what to leave out, and any context about your work that changes what a good answer looks like. Keep it short. Everything in it is sent on every request and consumes space your material needs.
- Can a document I upload override the instructions?
- It can compete with them, and sometimes wins. A model reading a document does not reliably distinguish between the text as material and text inside it that reads like an instruction. This matters most where documents arrive from outside your organisation, and it is a reason to check what an assistant does rather than what it was told to do.
- Is a longer system prompt a better one?
- No. Long briefs cost more on every request, crowd out the material you actually want considered, and tend to contain rules that contradict each other, which the model then resolves unpredictably. Short, specific and consistent beats comprehensive, and instructions nobody has reread in six months are usually the problem.
Key takeaways
- It is ordinary text sent ahead of your conversation, working through influence rather than enforcement.
- Several layers stack, from the provider, the product builder and you, and conflicts are resolved unpredictably.
- It is sent and paid for on every request, and it consumes space your own material needs.
- It is neither secret nor a security boundary, so rules that must hold belong in code.
- Your own standing instructions are the cheapest quality improvement, and the easiest never to make.
Last checked July 2026