System, Role, and Context Prompts: Give Instructions Their Place

A prompt often contains several kinds of information: rules that apply every time, a request for this turn, and background details needed to answer it. Putting those pieces in the right place makes a prompt easier to maintain and easier to inspect when a response misses the mark.

This lesson explains system instructions, role framing, and context in plain language. The names can be confusing because “role” may mean a message type in an API or a persona description such as “act as an editor.” Those are different ideas. We will separate them, look at how current APIs represent instructions, and build one small example.

Put stable guidance apart from the immediate task

An instruction that should shape many requests is different from a one-time request. Suppose you are building a help assistant for a library. It should consistently answer in plain language, use the library’s approved information, and ask a follow-up question when a request is ambiguous. Those are stable behavior rules.

The visitor’s question changes each time: “How do I renew a book?” or “Is the downtown branch open on Sunday?” Those are task inputs. The library’s current opening hours or renewal policy are supporting context. Keeping these categories distinct helps you update the right part when something changes.

A system instruction is high-level guidance supplied by the application or developer to shape a model’s behavior. In some APIs, the related concept may be named or represented differently. A user message is the request or information supplied for the current turn. A model’s assistant message is its response. A developer message is an application-level instruction role in APIs that expose it. Do not assume every provider uses identical message types or priority rules.

For a simple mental model, think of three containers:

• Stable guidance: the assistant’s recurring job, boundaries, and style.
• Current request: what the person wants done now.
• Task context: facts, documents, or examples needed to complete that request.

These containers may map to different API fields or message roles depending on the provider. They can also be combined in a single text prompt in a basic chat interface. The conceptual separation still helps you write and revise them.

What “system” means across providers

The word system is common in prompt discussions, but the exact API structure varies. OpenAI’s current API documentation describes high-level instructions and roles such as developer, user, and assistant. Developer instructions have higher priority than user instructions. The Responses API can also take high-level instructions in an instructions parameter. Check the endpoint you are using because fields and behavior may differ across APIs.

Anthropic’s Messages API takes a top-level system parameter for system guidance. In the standard conversation messages, the common roles are user and assistant; a system prompt is not sent as an ordinary first message with a system role. Google’s Gemini API supports a system_instruction field. The exact parameter names and behavior are provider-specific, so use the current documentation for your chosen model and endpoint.

For a reader using a playground, these differences may show up as separate boxes labeled “System instructions,” “Instructions,” or similar. Some interfaces may combine settings or change their labels over time. Check the request preview or current docs before assuming where a field goes. What matters conceptually is knowing which instructions are meant to persist and which text belongs to this one request.

This is an area where old tutorials can become misleading. They may say every model accepts a system message, or that system always outranks every other input in the same way. Those are not safe assumptions. Read the provider’s role hierarchy and endpoint reference. If your application carries conversation state between turns, check whether its instruction field is automatically carried forward or must be sent again.

Role framing is not the same as a message role

A message role tells the API who supplied a message or what kind of instruction it contains. For example, a user message generally carries the user’s request, while an assistant message contains a model response. Some APIs provide a separate higher-priority developer role.

Role framing is wording inside an instruction, such as “You are a patient writing coach” or “Act as a copy editor.” It suggests a perspective, audience, or style. It does not create a new API role, grant expertise, or guarantee that the model has real-world qualifications. It is best used when the perspective changes the response in a useful way.

Instead of relying on a broad persona alone, describe the behavior you want. “You are a helpful expert” does not say what to do. “Review this paragraph for unclear sentences. Suggest edits and explain each one in plain language” gives an observable task. If a role helps, pair it with clear actions: “Act as a copy editor. Preserve the author’s meaning, identify unclear sentences, and suggest concise revisions.”

Roles can also distract from what matters. If a simple request needs only a one-sentence summary, adding “You are a world-class strategist and communications visionary” adds noise without clarifying the output. Try a role when it meaningfully shapes voice or viewpoint, then compare results using the workflow from your first prompt workflow.

Add context that earns its place

Context is information that helps the model interpret or complete the task. It might include who the audience is, what happened earlier in a conversation, a product policy, a passage to summarize, or examples of the desired format. Context is useful when it closes a gap that would otherwise lead to a guess.

Context is not automatically reliable or current. If you provide a policy excerpt, the model can use the excerpt, but it cannot know whether the excerpt is the latest version unless you tell it or connect it to a current source. If you paste a customer’s note, the model can use its contents, but it may misunderstand ambiguity. Check important details and update context when the source changes.

Give the model the relevant slice, not every document you have. Extra material can distract from the current task, use more of the model’s context capacity, or contain conflicting facts. State which source to use and what to do when the answer is absent. For example: “Use only the policy excerpt below. If it does not answer the question, say that the excerpt does not specify.”

Make the boundaries visible. Labels such as Policy, Customer message, and Task can help separate sources. If the content may contain text that looks like an instruction, clarify that it is data to analyze rather than a rule to follow. Later lessons will cover examples and prompt injection in more depth.

A worked example: a library help assistant

Imagine a library wants a tool that drafts short answers to common questions from an approved policy excerpt. A stable instruction could be:

1You help library staff draft clear answers to routine visitor questions.
2Use the policy text provided with each request as the source for library rules.
3If the policy does not answer the question, say what information is missing.
4Do not invent fees, dates, or exceptions.
5Write in plain language and keep the answer under 80 words.

The current request and context might be:

1Task: Draft an answer to the visitor's question.
2
3Policy excerpt:
4Items may be renewed once if no other visitor has placed a hold.
5Renewals can be requested online or at any branch desk.
6
7Visitor question:
8Can I renew my book online if someone else has put it on hold?

The stable guidance describes the recurring job and boundaries. The request asks for an answer now. The context provides the policy that the answer must use. This separation also makes revisions clearer: if the word limit should change for every answer, edit the stable guidance; if the visitor asks a different question, replace the request and relevant excerpt.

A suitable illustrative answer might be: “You can renew online once if no one else has placed a hold. Since another visitor has placed a hold, the policy does not allow this renewal.” This answer is an example written for teaching. No live model generated or checked it. The policy excerpt itself is fictional, and an actual library should verify that its rules are current before using them.

The example includes a short limit and plain-language direction, but it still needs human review. A system instruction cannot ensure every response follows the policy. If the answer affects access, fees, or a person’s rights, make the tool show its source and involve staff in the approval process.

Keep recurring instructions in the right place

When you build an application, it is useful to keep recurring guidance separate from user-provided text. That makes the program easier to inspect and reduces the chance that a visitor’s request accidentally replaces the application’s task description. It also lets you version the instruction alongside the code and test it after an edit.

The layout depends on your provider. In OpenAI’s Responses API, high-level instructions can be passed through instructions; in Anthropic’s Messages API, the top-level system parameter is used; in Gemini API requests, the field is called system_instruction. User messages and conversation history are structured according to the API as well. These names are examples from current documentation, not interchangeable field names. Confirm current support and priority rules when you select a model or endpoint.

If you are using a no-code chat interface, you may not see these message roles. You can still separate the same ideas with labels:

1Your recurring job:
2[Stable instructions]
3
4Current task:
5[Request for this turn]
6
7Reference material:
8[Relevant context]

Do not add sections just to make a prompt look advanced. A short instruction can work well when it states the task and the information needed. Structure is most helpful when it makes the prompt easier for a person to maintain or reduces confusion between sources.

For a deeper treatment of how agent instructions interact with tools and application behavior, see the AI Agents lesson on prompting for agents.

Mistakes beginners make

1. Treating role framing as a credential. “Act as a lawyer” does not make the model qualified or make its answer legal advice.
2. Putting every detail in recurring instructions. One-time facts belong with the current request or its context.
3. Assuming providers share the same role structure. Check your endpoint’s documentation and current role hierarchy.
4. Pasting context without naming its source or limits. Tell the model which material to use and what to say when it lacks an answer.
5. Adding irrelevant background. More text can obscure the facts the task depends on.
6. Expecting high-level instructions to guarantee compliance. Review answers and build safeguards around consequential uses.
7. Using a persona when a concrete task would be clearer. State the action, audience, and output you need.

Recap and try it yourself

Keep recurring guidance, the current request, and task context conceptually separate. A message role is an API structure; role framing is a persona description in words. System instructions and their priority differ across providers, so check the current endpoint documentation. Add context that helps answer the task, name its source, and explain what to do when it does not contain the answer.

Try it: write a recurring instruction for a low-stakes helper, then add one request and a small piece of context. Label the parts and remove anything that does not affect the answer. Ask whether a teammate could tell which facts are supplied and which behavior should stay consistent. In the next lesson, we will see how examples can teach a model a desired pattern through zero-shot, one-shot, and few-shot prompting.