System instructions

Messages have roles

Most chat-based AI APIs don't take a single block of text. They take a list of messages, each with a role:

• System (sometimes called "developer" or "instructions"): sets up how the assistant should behave for the whole conversation.
• User: what the person (or your app on their behalf) is asking right now.
• Assistant: the model's previous replies, included so it has the conversation history.

[
  { "role": "system", "content": "You are a support assistant for Acme Bikes. Answer only questions about Acme products and orders. Be concise and friendly." },
  { "role": "user", "content": "My brake lever feels loose. What should I do?" }
]

Exact field names vary by provider — some APIs take the system prompt as a separate parameter rather than a message — but the concept is the same. In consumer apps, features like "custom instructions" or project instructions play a similar role.

What belongs in the system message

Think of the system message as the job description and house rules: things that should be true for every turn.

• Role and audience: "You help small-business owners with bookkeeping questions."
• Scope: what to help with, and what to decline or redirect.
• Tone and style: concise vs detailed, formal vs casual, language.
• Output conventions: always use Markdown, always end with next steps, JSON shape for a tool.
• Behaviour under uncertainty: "If you don't know, say so and suggest contacting support."
• Stable reference context: a short product summary, glossary, or policy excerpt.

What belongs in the user message

The user message carries the specific request and its data: the question, the document to analyse, the one-off constraints ("keep this one under 50 words").

The second version puts the durable rules where they'll apply to every future request in the conversation, and leaves the user message clean.

Persistence and drift

In an API, the model has no memory between calls — your application re-sends the system message and the conversation history every time. That's why system instructions "persist": they're included on every request.

Even so, in very long conversations instructions can lose influence: the history grows, and recent messages may pull the model in a different direction. Practical habits:

• Keep the system message focused; rules buried in a wall of text get followed less reliably.
• Put the most important constraints clearly and explicitly, not as hints.
• For long sessions, consider summarising older history rather than letting it grow indefinitely.
• If a rule matters for a specific turn, it's fine to restate it in the user message.

How strong are system instructions?

Models are generally trained to give system instructions more weight than user messages, and to follow them when the two conflict. That makes the system message the right place for your product's behaviour.

But "more weight" is not "enforced". A system prompt is strong guidance, not a security boundary:

• Users can sometimes talk a model out of its instructions with clever phrasing.
• Text inside documents, web pages or emails the model processes can contain instructions of its own (prompt injection).
• System prompts can sometimes be coaxed out — don't put secrets like API keys or passwords in them.

A solid system-prompt skeleton

You are {{assistant_role}} for {{product_or_team}}. Your users are {{audience}}.

## Goals
- {{primary_goal}}

## Scope
- Help with: {{in_scope}}
- Politely decline and redirect: {{out_of_scope}}

## Style
- {{tone}}; {{length_guidance}}
- Format: {{format_rules}}

## When unsure
- Say what you don't know. Don't invent order numbers, prices, or policies.
- Suggest {{escalation_path}}.

Write it, then test it with awkward user messages: off-topic questions, conflicting instructions, a request to "ignore your rules". You'll learn more from ten tricky test inputs than from rereading the prompt.