A system prompt is the standing set of instructions you give an AI model before any user message arrives. It tells the model who it is, what it should and should not do, and how its answers should look. Both Anthropic’s and OpenAI’s developer documentation treat it as one of the main levers for shaping behavior: a well-written system prompt makes a model consistent across hundreds of conversations, while a vague one produces drift, inconsistent tone and surprising refusals. This guide gives you a structure you can reuse, a worked example and the mistakes to avoid.

What a system prompt does, and what it cannot do

The system prompt is read at the start of every conversation, and models are trained to give it more weight than ordinary user text. It is the right place for durable rules: the assistant’s role, the audience, the tone, the output format and the boundaries of the task. It is the wrong place for facts that change every request (put those in the user message or retrieve them), and it is not a security boundary. A determined user can sometimes override or extract a system prompt, a risk explained in our article on prompt injection. Treat the system prompt as guidance, and enforce anything critical, such as permissions, in your application code.

A five-part structure that works

Most effective system prompts contain five parts. You can write them as short paragraphs or as headed sections, whichever is easier to maintain.

  1. Role and audience. One or two sentences: who the assistant is and who it is helping. “You are a support assistant for a small accounting software company. Your users are small-business owners with no accounting training.”
  2. Goal and scope. What success looks like and what is out of scope. “Help users fix invoicing problems. If a question is about tax advice, say that you cannot give it and point to a qualified professional.”
  3. Rules and constraints. The things that must always or never happen, ideally with the reason. Models follow rules better when they understand why: “Never promise refunds, because only the billing team can approve them.”
  4. Output format. Length, structure, language, and any machine-readable format. “Answer in under 120 words. Use numbered steps for procedures.”
  5. Examples. One to three short input-output pairs showing the style you want. Our guide to few-shot prompting explains why examples often beat extra explanation.

A worked example

Here is a weak prompt, followed by a stronger version.

Before: “You are a helpful assistant that answers customer questions about our software.”

This leaves everything open. The model will guess at length, tone, how to handle billing questions and what to do when it does not know an answer.

After:

You are a support assistant for LedgerLite, accounting software for small businesses.
Your users are shop owners and freelancers with no accounting background.

Goal: help users solve invoicing and bank-sync problems.
Out of scope: tax, legal or investment advice. If asked, say you cannot advise
on that and suggest a qualified professional.

Rules:
- Never promise refunds or credits; only the billing team can approve them.
  Offer to hand the conversation to billing instead.
- If you are not sure of an answer, say so and ask one clarifying question.
- Do not guess at features that are not in the help documentation provided.

Format: plain language, under 120 words, numbered steps for procedures.

Example
User: My invoices show the wrong date.
Assistant: That usually happens when the invoice date field is set to "today." To fix it: 1) Open the invoice. 2) Click the date. 3) Choose the correct date and save. Does that match what you see?

The second version fixes the role, the audience, the boundary, the failure behavior and the format. Each line removes a decision the model would otherwise make for you.

Five common mistakes

  1. Writing a wall of rules with no priorities. When forty instructions compete, the model cannot tell which matter. Put the two or three non-negotiables first and cut the rest.
  2. Using vague adjectives. “Be concise” and “be professional” are interpreted differently by every model. Give numbers and examples: “under 120 words.”
  3. Stating what not to do without saying what to do instead. “Don’t be verbose” is weaker than “Answer in one short paragraph, then offer more detail.”
  4. Contradicting yourself. “Always answer fully” and “keep responses brief” in the same prompt force the model to choose. Re-read your prompt as if you were the model.
  5. Never testing. A system prompt is software. Run it against a set of realistic and adversarial inputs, change one thing at a time and keep the prompt in version control. Our guide to building an evaluation set shows how.

Keeping a system prompt healthy

Write down what each section is for, so that the next person can tell whether a line is still needed. Remove instructions that were added to fix one bad answer once the underlying issue is solved. When you switch models, retest: instructions that one model followed literally may be interpreted differently by another, and newer models often need fewer reminders. If the prompt gets long, consider moving reference material into retrieved documents rather than stuffing it into the prompt, a pattern covered in how retrieval-augmented generation works.

What to watch next

  • Model-specific prompting guides from the labs, which change as models change.
  • Tooling that tests prompts automatically against evaluation sets.
  • Features that separate permissions from prompts, so critical rules do not rely on wording.
  • Research on how reliably models follow instructions placed in system prompts versus user text.

Key takeaways

  • A system prompt holds durable instructions: role, scope, rules, format and examples.
  • Specific, testable instructions beat adjectives like “concise.”
  • Explain the reason behind important rules.
  • Do not rely on a system prompt for security; enforce critical limits in code.
  • Test and version your prompt like any other piece of software.

Frequently asked questions

How long should a system prompt be?

As short as it can be while covering role, scope, key rules and format. Many good prompts fit in a few hundred words; length alone does not improve results.

Do all models treat system prompts the same way?

No. Different models and providers weigh and interpret them differently, so retest whenever you change models.

Can users see or override my system prompt?

Sometimes. Users may be able to coax a model into revealing or ignoring it, so never put secrets in it and enforce limits outside the model.