Roles and System Prompts

What a role does

Role prompting means telling the model whose part it plays and for whom, for example "You draft replies for the Kestrel Energy service desk; the readers are customers without technical knowledge." A persona is the character or professional identity described in such a role: a service desk analyst, a network engineer explaining to a beginner, a reviewer who checks for security problems.

A role works because of how a model produces text: it continues in the style that best fits everything before it. A line that sets up a service desk context makes service desk vocabulary, a polite tone and practical next steps the most likely continuation. Anthropic's guidance says that setting a role in the system prompt focuses the model's behavior and tone, and that even a single sentence makes a difference. A role changes:

• Tone and register: formal or friendly, plain language or technical.
• Focus: a reviewer looks for problems, a writer for clarity, a trainer for what a beginner needs to hear.
• Assumptions about the reader: what can be left out and what needs explaining.

What a role does not do

A role does not give the model knowledge it lacks or make its reasoning more careful. "You are the world's best network engineer" does not add a single fact about subnetting; it mostly makes the answer sound more confident. A research report published in December 2025 under the title "Playing Pretend: Expert Personas Don't Improve Factual Accuracy" found that expert personas generally did not improve accuracy on two benchmarks of difficult questions across six models, with rare exceptions, while low-knowledge personas often lowered it. That fits how models work: a persona changes style, and style is not evidence (see anthropomorphism for why a confident voice is easy to over-trust).

Describe the situation, not a title

What helps is the information a title only hints at: who the answer is for, what they already know, what they will do with it, and what good looks like. Compare:

You are a world-class customer service expert. Reply to this customer.

Customer: "Your portal was down all morning and I couldn't submit my meter reading. Again."

You draft replies for the Kestrel Energy service desk. The customer below is a household customer, not technical, and annoyed after the portal outage this morning (08:10 to 09:05). Readings that failed during the outage were not saved and can be submitted again now.

Write a reply of at most 80 words: acknowledge the problem once, explain what to do, and do not promise that it will never happen again.

Customer: "Your portal was down all morning and I couldn't submit my meter reading. Again."

The second prompt still has a role in its first sentence, but the work is done by the facts and the description of the reader. The first prompt leaves the model to guess what happened and what the customer should do, so a fluent reply with invented details is a likely result.

You are the world's best network engineer. Is 192.0.2.0/25 large enough for 140 hosts?

Explain to Emeka Obi, a new network engineer, whether the subnet 192.0.2.0/25 has enough usable host addresses for 140 devices. Show the calculation in at most two lines, then answer "yes" or "no".

Answers vary between runs and between assistants. If both answers are right, the difference to look for is how easy each is to check and to pass on to a beginner.

System, developer and user messages

A system prompt holds instructions that apply to a whole conversation; the user messages hold what the person types each turn. Where the standing instructions live depends on the tool:

• In an API, the application sends them with every request. Anthropic's Messages API has a top-level system field. OpenAI's APIs use a message with the role developer (or the instructions parameter of the Responses API).
• In a chat app, the vendor writes its own system prompt, which you do not see. You can usually add your own standing instructions on top (see below).
• In coding agents, instruction files in the repository play the same part (covered in Context Engineering and Agents).

A developer message is OpenAI's name for instructions from the application builder: according to its documentation (as of October 2026) they are prioritized ahead of user messages, and its reasoning models use developer messages where older models used system messages. The idea is the same as a system prompt. The example builds the same standing instructions and question as a request body for both APIs, without sending anything; the field names are as documented in October 2026.

import json

# The standing instructions and the user's question, written once.
standing = ("You draft replies for the Kestrel Energy service desk. "
            "Readers are customers without technical knowledge. "
            "Write at most 80 words and never promise a resolution time.")
question = "Customer asks why their smart meter shows no readings since Monday."

# Anthropic Messages API: the system prompt is a separate top-level field.
anthropic_body = {
    "model": "MODEL_ID",
    "max_tokens": 2000,
    "system": standing,
    "messages": [{"role": "user", "content": question}],
}

# OpenAI Responses API: the same text as a message with the role "developer".
openai_body = {
    "model": "MODEL_ID",
    "input": [
        {"role": "developer", "content": standing},
        {"role": "user", "content": question},
    ],
}

for name, body in (("Anthropic", anthropic_body), ("OpenAI", openai_body)):
    print(f"--- {name} request body")
    print(json.dumps(body, indent=2))

--- Anthropic request body
{
  "model": "MODEL_ID",
  "max_tokens": 2000,
  "system": "You draft replies for the Kestrel Energy service desk. Readers are customers without technical knowledge. Write at most 80 words and never promise a resolution time.",
  "messages": [
    {
      "role": "user",
      "content": "Customer asks why their smart meter shows no readings since Monday."
    }
  ]
}
--- OpenAI request body
{
  "model": "MODEL_ID",
  "input": [
    {
      "role": "developer",
      "content": "You draft replies for the Kestrel Energy service desk. Readers are customers without technical knowledge. Write at most 80 words and never promise a resolution time."
    },
    {
      "role": "user",
      "content": "Customer asks why their smart meter shows no readings since Monday."
    }
  ]
}

The text is identical; only the envelope differs. That is a good reason to keep standing instructions in one file under version control and let code put them in the right field (see Prompt Templates and Reuse and Prompts in Applications: the API).

The instruction hierarchy

When instructions conflict, which one wins? The instruction hierarchy is the order of priority a model is trained to give instructions from different sources: the provider's own rules first, then the application builder's system prompt or developer message, then the user's messages. Content the model reads, such as a pasted email, a web page or the result of a tool call, should be treated as information, not as instructions at all.

Two consequences matter in daily use. First, if a chat app or an internal tool ignores your request to change its format or tone, its system prompt probably says otherwise; ask the owner of the tool rather than arguing with it. Second, the hierarchy is learned behavior, not a lock. Users sometimes talk a model out of its system prompt, and text inside documents can carry instructions that the model follows; that is prompt injection. Anything that must never happen has to be enforced in code and permissions, outside the prompt (see Prompt Security and Responsible Use).

Writing standing instructions

Custom instructions are standing instructions you save in a chat assistant or a project so that they are added to every conversation, for example your role, the audience you usually write for and your format preferences. Most mainstream assistants offer something like this, under different names and in different places in the settings; for an application, the system prompt is the same thing. Write them as you would brief a new colleague who will handle many different requests:

• Who and for whom: the team, the usual readers, the language.
• Defaults: length, format, tone, units, date format.
• Rules with their reasons: a reason lets the model apply the rule sensibly to cases you did not foresee.
• What to do when information is missing: ask, or say what would be needed, instead of guessing.
• Facts the model cannot know: what it can and cannot access, and, in applications, today's date and the product or model name if users may ask.

You help the Kestrel Energy service desk draft customer replies and internal ticket notes.

Customers are households and small businesses in the Netherlands and are usually not technical. Reply in the language of the customer's message, in plain words.

Customer replies: at most 120 words, friendly and factual. Only promise what the knowledge article or procedure in the conversation says. If none is given, say what information you would need instead of guessing, because a wrong promise to a customer costs us more than a slower reply.

Internal notes: start with the ticket number (INC-nnnnn), then symptom, action taken, next step.

You have no access to Kestrel systems; everything you know about a case is in the conversation.

Anthropic's engineering guidance describes the right level for a system prompt as specific enough to guide behavior, yet flexible enough to give the model strong heuristics instead of brittle, hard-coded rules. A system prompt that tries to script every case becomes long, contradicts itself and still misses the case that actually happens.

Keep secrets out of system prompts

A system prompt is hidden from the user interface, not from the model, and whatever the model can read it can be persuaded to repeat. Assume that the full text of any system prompt, custom instruction or instruction file can end up in front of a user. The OWASP Top 10 for LLM Applications lists this risk as System Prompt Leakage (LLM07 in the 2025 edition); the 2026 edition, published in August 2026, uses the broader name Hidden Context Exposure (LLM08:2026).

• No passwords, API keys, connection strings or internal URLs you would not publish. Keys belong in environment variables or a secrets manager (see sensitive data).
• No customer or personal data in standing instructions; give case data per request, and only what the task needs.
• No security rules that exist only in the prompt. "Never show invoices of other customers" must be enforced by the system that fetches invoices, not by a sentence the model reads.

Testing a system prompt

A system prompt applies to every conversation, so a change to it changes everything. Keep a set of typical and awkward requests (an angry customer, a question outside the scope, a request in Dutch, a message that tries to change the rules) and run all of them after every edit and every model upgrade. A tweak that fixes the reply to one customer can make a dozen others worse; Iterating and Testing Prompts shows how to do this systematically.