In plain terms
When you chat with a company's assistant, you are not talking to a blank model. Before your first word, the model has already read a briefing from the company: who it is, what it should and should not discuss, how to speak, what it has access to. That briefing is the system prompt. You do not see it, and it shapes every answer.
Why it matters
The system prompt is where a general model becomes your product. It is the cheapest way to define behaviour, and for most deployments the first thing to get right. It is also a security boundary people overestimate: users can often extract it or argue around it, so it should never hold secrets or be the only thing enforcing a rule.
Example
A travel company's assistant has a system prompt saying it helps with bookings on the company's own platform, answers in the customer's language, never quotes prices from memory and always calls the pricing tool. Asked to compare a competitor's fares, it declines politely and offers to search the company's own.
Most often confused with
System Prompt vs. User prompt
Both reach the model as text, but with different standing. The system prompt comes first and is treated as carrying the operator's authority; user messages are requests made within that frame. Models are trained to give system instructions priority, though the priority is a strong tendency and not a guarantee.
Under the hood
Typical contents: role and audience, scope and refusals, style and format rules, tool descriptions and when to use them, examples, and dynamic facts such as today's date or the user's account tier. Long system prompts are normal in production and are well suited to prompt caching, since they repeat on every request. Practices: explain the reason behind a rule, since models generalise better from reasons than from bare commands; keep volatile data out of the cached prefix; version and test the prompt like code. Assume it can leak: prompt-extraction attacks are common.