Many APIs and tools for language models expose a special place for “system instructions” or something similar. It is usually separated from normal messages, labeled clearly, and highlighted in documentation.

This easily gives the impression that system instructions are a higher level of authority: that they always take precedence, that they define what the model must follow, and that other instructions are secondary. Users start to think there is some strong technical guarantee behind that separation.

In practice, there might not be such a big difference. In some cases, there might be no real difference at all.

From the model’s point of view, everything ends up as text in a single prompt. System instructions, user instructions, previous messages: it is all just context the model reads and then uses to guess what it should do next. The model is not applying a fixed rule engine where “system beats user” in all cases. It is pattern matching on the combined text.

That also means it does not really matter where the instructions are given to the model. They can be sent in a separate “system” field, or they can be written into the first user message. Either way, they become part of the same input. The separation exists mostly for humans and tools, not as a hard technical boundary inside the model.

When instructions conflict, this becomes very visible. You might have a system instruction saying “Always answer in Norwegian,” and later a user message saying “Answer in English instead.” Or a framework might inject one set of system rules, while the application or end user adds different or even opposite instructions in normal messages.

In those situations, the model does not strictly enforce a priority based on where each instruction came from. It tries to guess what it is supposed to do overall. Often, it will lean toward what seems most likely or most recent in the conversation. Sometimes it follows the system instruction, sometimes the user, sometimes it ends up in between. The result is that you cannot rely on the location alone to resolve conflicts.

So what can you actually do with system instructions?

They are still useful as a way to define shared baseline behavior: things like role, tone, and general constraints you want across many conversations. They are also a convenient place for tools and frameworks to inject their own configuration. But you should not assume that “because it is in the system field, the model will always obey it.”

The practical takeaway is: think of all instructions together, not as layers with strict power. Avoid contradictory instructions if you want predictable behavior. If something really matters, make it clear, simple, and repeat it where necessary, instead of trusting that a single system instruction will always win.