Every conversation with a language model has the same skeleton. Three roles, always in the same structural relationship, whether you're using a consumer chatbot or a production enterprise feature that cost seven figures to build. Understanding those roles — precisely, not approximately — is the difference between a discovery call where you're following the buyer's framing and one where you're setting it.
The three roles are: user prompt, system prompt, and assistant turn. Here's what they actually are.
What the Three Roles Are
The user prompt is the input from the person using the application. In a consumer chatbot, it's what you typed. In an enterprise feature — a policy Q&A tool, an HR assistant, a procurement helper — it's what the employee typed into whatever interface the vendor built. The user prompt is the live, variable input. It changes every time someone uses the system.
The system prompt is a set of instructions written by the application developer and delivered to the model before the user's input arrives. It's not something the end user sees or writes. It's the developer's layer: "You are a helpful assistant for Acme Corp's IT helpdesk. Answer questions only about supported software. Do not discuss competitor products. Always respond in formal English." The system prompt is fixed at deployment time — or at least, it's supposed to be.
The assistant turn is the model's response. In a multi-turn conversation, the conversation history accumulates: system prompt, then user prompt, then assistant turn, then the next user prompt, then the next assistant turn. The model sees all of it. Every response is generated in the context of everything that came before it.
These three roles aren't a convention that one vendor invented. They're the structural interface that the major model providers — OpenAI, Anthropic, Google — expose through their APIs. When a developer calls the API, they pass a structured array of messages, each tagged with a role: system, user, or assistant. The model processes them in order.
• Three roles: User prompt is live input; system prompt is developer-configured instructions delivered before the user arrives; assistant turn is the model's response — and in multi-turn conversations, all three accumulate into a single context the model reads in full.
How It Actually Works
The mechanism is where the intuitions go wrong, so it's worth being precise.
When a developer calls a model API, they're not sending a single string of text. They're sending a structured conversation: a list of messages, each with a role and content. The model receives this list and generates the next message in the sequence.
The model doesn't have a separate "system prompt processor" that runs before the language model kicks in. There's no privileged execution layer. The system prompt is just the first message in the list, tagged system. The model reads it, reads the user prompt tagged user, and generates a response. The system prompt gets processed the same way the user prompt gets processed: as tokens in a context window.
A typical system prompt for an enterprise feature might run 300 to 1,500 tokens — call it a few paragraphs of instructions. A full conversation context window on a current model might be 128,000 tokens or more (these numbers move fast; treat them as order-of-magnitude anchors, not specs to cite). The system prompt is a small fraction of the available context. The model weighs it alongside everything else in the window.
The model is not enforcing the system prompt. It is following it, in the same way it follows any coherent instruction in its context. When the system prompt says "do not discuss competitor products," the model has learned from training that it should comply with that kind of instruction. But that compliance is a behavior, not a constraint. It's the difference between a door with a lock and a door with a sign that says "please keep closed."
The model's behavior can be influenced by what comes later in the context. A sufficiently crafted user input can confuse, override, or work around system prompt instructions — this is prompt injection, and it's a real attack surface, not a theoretical one. That's a separate article. The point here is just that the mechanism doesn't work the way "policy" implies it works.
• Mechanism: The model receives system prompt, user prompt, and conversation history as a single structured list and generates the next response. The system prompt has no privileged execution status — it's the first message in the list, processed like any other text.
Where You'll Need This
A CIO or a CISO — more likely a deputy CIO, the one who actually reads the procurement docs — asks: "How does the vendor control what the model says? What prevents it from going off-script?"
The answer they're expecting, based on how every other enterprise software conversation goes, is something about configuration. You set a policy, the policy enforces the behavior, the audit log shows you what happened. That's how access management works. That's how DLP works. That's how most of the enterprise software they've bought for twenty years works.
The accurate answer for a system-prompt-driven feature is more complicated. The vendor configured a system prompt. The model follows it reliably under normal conditions. But "reliably under normal conditions" is doing a lot of work in that sentence, and a technically sophisticated buyer will notice.
Your ability to explain the mechanism is what earns you the room here. You can say: the system prompt is the primary behavioral control for this feature. It's how the vendor scopes what the model will and won't do. It works well for the use cases the vendor designed for. The places where it's less deterministic than a traditional policy configuration are the edge cases — unusual inputs, adversarial inputs, inputs that weren't in scope when the system prompt was written. Those are the places where the vendor's testing and monitoring matter, and those are the questions worth asking in procurement.
That framing is more useful than "the system prompt controls everything" and more credible than "nobody really knows." It also sets up the right follow-on questions: What does the vendor's red-teaming process look like? What's the escalation path when the model produces unexpected output? Is there a human-in-the-loop for high-stakes responses?
Consumer use is ad hoc — you type, the model responds, you adjust. Enterprise features are built on the assumption that the system prompt is stable, reliable behavioral infrastructure. That assumption is mostly right. The word "mostly" is where the engineering work lives.
• Practical stakes: When a buyer asks how the vendor controls model behavior, the accurate answer centers on the system prompt as the primary behavioral control — reliable under designed conditions, not deterministic in the way a traditional policy enforcement mechanism is. That distinction is the basis for the right procurement questions.
IDAM Concept Mapping
The system prompt most resembles a pre-authentication policy evaluation — the kind of configuration that runs before the user session begins and shapes what the system will and won't do. Think of an ABAC policy that evaluates context before granting access, or the OAuth scope configuration that defines what a token can do before the user ever makes a request. The analogy holds in one important way: the system prompt is set by the application layer, not the end user, and it's meant to constrain what happens in the session that follows.
The analogy breaks at enforcement, and that's the part that matters. An access policy is enforced by infrastructure. The authorization server checks it. The resource server validates the token against it. The policy doesn't care whether the user finds it persuasive. A system prompt carries no equivalent enforcement status. It is text that the model processes alongside all other text. The model has been trained to follow system prompt instructions, and it does so reliably — but that reliability is a learned behavior, not a hard constraint. A user input crafted to conflict with or confuse the system prompt can affect model behavior in ways that a conflicting OAuth claim simply cannot affect a properly implemented token validation.
Teams that treat the system prompt as an access policy will under-invest in testing, monitoring, and adversarial input handling. They'll ship a feature that works in demos and fails in production when a user — accidentally or intentionally — sends input the system prompt wasn't written to handle. The system prompt is a real and important control. It's just not the kind of control that enforces itself.
Prompt engineering — the discipline of writing and refining system prompts to produce reliable model behavior — is a real craft. It's the primary interface between application intent and model behavior for most deployed AI features, and it will remain so regardless of what other controls get layered on top. The people who are good at it understand the mechanism: specificity beats generality, examples outperform abstract instructions, and the model's training shapes how it interprets ambiguous directives. They also know that no system prompt is complete on day one, because you don't know what users will actually send until they send it.
That's the honest framing for a buyer conversation. The system prompt is where behavioral requirements get expressed. Testing and monitoring are where you find out whether the expression worked. The gap between those two things is where the interesting engineering happens — and where the interesting procurement questions live.
Next in AI Foundations: context windows — what they are, why they have limits, and what happens to a conversation when it runs out of room.