System Prompts: What They Are and How to Write Them

Modern LLM APIs separate the instruction layer from the conversation itself, though they expose it differently: Anthropic takes a top-level system parameter alongside the messages array, while OpenAI uses a developer role, or the instructions parameter in its Responses API, having reserved system for its own use. Whatever the mechanism, that content sits ahead of the conversation, and models are trained to treat it with elevated authority. A system prompt is the content you place in that layer. It is not visible to end users, though they can often infer its contents through probing, and it persists for the duration of a single context window. In standard stateless API calls it does not persist across separate sessions, so your application must re-inject it on every call. The key architectural point is that the model does not know it has a system prompt the way a human knows they have been briefed. It processes the full context window as text, and the system prompt is simply the first content in that context. Adherence is therefore probabilistic, not deterministic: a well-written system prompt strongly conditions the model's behaviour, but it does not enforce rules with mathematical certainty. A user message is one turn among many; the system prompt sits in a fixed, privileged position at the start of the context, and instructions in the system role generally carry more weight than instructions in the user turn, which makes it the right place for hard constraints. That said, conflicting user instructions can still cause drift, so your constraints need to be unambiguous. And because the system prompt establishes trusted authority, it is also the primary target for prompt injection, attempts by malicious user input to override or circumvent your instructions.