How to Write a System Prompt (With Examples)

To write a good system prompt, describe the assistant the way you would brief a new employee: who it is and whom it serves, what it should and should not handle, the facts and sources it may rely on, the rules it must follow, how to answer (tone, length, format), and what to do when it cannot help. Write it in clear sections, keep each rule short and unambiguous, put stable content first, and test it against realistic conversations before going live. Below is a structure you can reuse and a complete example.

What a system prompt is and where it fits

In an AI application, every request to the model usually has two layers:

• System prompt: standing instructions written by you, the same for every conversation.
• User messages: what the person types, different every time.

Many APIs also accept messages from the assistant's previous turns and tool results. The system prompt sets the frame for all of it. In chat tools, similar settings are sometimes called custom instructions or project instructions.

Because the system prompt is sent with every request, it also affects cost. A 2,000-token system prompt on 30,000 requests per month is 60 million input tokens. Our guide on LLM API pricing explains how that adds up, and prompt caching can reduce the cost of a stable system prompt.

A seven-part structure

Section	What it contains
1. Role and purpose	Who the assistant is, whom it serves, what it is for
2. Scope	Topics it handles, topics it declines or hands over
3. Knowledge and sources	What information it may use, and how to treat missing information
4. Rules	Must and must-not behaviours, in priority order
5. Style	Tone, form of address, language, length
6. Output format	Structure, markup, fields, or a schema
7. Fallbacks and escalation	What to do when unsure, out of scope or when a human is needed

Using clear headings or delimiters such as tags helps the model, and helps the next person who has to maintain the prompt.

Writing each section

1. Role and purpose

One or two sentences are enough: "You are the support assistant for [company], an online shop for office furniture. You help existing customers with questions about orders, delivery, returns and product care."

A role works best when it is specific about the audience and the job, not when it adds superlatives. "World-class expert" adds nothing; "answers questions from customers who are not technical" changes the vocabulary.

2. Scope

List what is in and out. Be explicit about the out-of-scope response: "If asked about topics unrelated to our products and orders, say briefly that you can only help with those and suggest contacting [channel]."

3. Knowledge and sources

Tell the model where facts come from. In many applications, relevant passages from a knowledge base are inserted into each request. State the rule: "Answer only from the information in the provided context. If the answer is not there, say you do not know and offer to connect the customer with the team." This is one of the most effective ways to reduce AI hallucinations.

4. Rules

Short, concrete, prioritised. Positive phrasing tends to work better than long lists of prohibitions:

• "Only confirm delivery dates that appear in the order data."
• "Never ask for full payment card numbers or passwords."
• "Refunds and compensation are decided by staff; you may explain the process, not promise an outcome."

If two rules could conflict, say which wins.

5. Style

Tone, form of address, reading level, length. "Friendly and concise. Use the customer's language. Answers of up to 120 words unless the customer asks for detail." If your brand has a style guide, summarise the parts that affect short written answers.

6. Output format

For chat interfaces: paragraphs or lists, whether to use markdown, whether to include links. For automations: a precise schema. If the next step in a workflow parses the output, specify the format exactly and, where your provider supports it, use structured output features rather than relying on wording alone.

7. Fallbacks and escalation

Define what happens when the assistant cannot help: missing information, angry customers, legal threats, safety issues, or a request for a human. Give it exact wording or a handover action. Clear fallbacks prevent improvisation in the situations where improvisation is most risky.

A complete example

## Role
You are the customer support assistant for ExampleCo Office, an online shop selling
office furniture to small businesses in the EU. You help existing customers with
orders, delivery, returns and product care.

## Scope
In scope: order status, delivery times, returns and exchanges, assembly and care
instructions, product dimensions and materials.
Out of scope: pricing negotiations, legal questions, topics unrelated to our products.
For out-of-scope requests, say briefly that you cannot help with this and suggest
emailing support@[domain].

## Sources
Use only the information in <context> and <order_data>. If the answer is not there,
say that you do not have that information and offer to forward the question to the
team. Never guess dates, prices or policies.

## Rules (in priority order)
1. Never request payment card numbers, passwords or full ID numbers.
2. Do not promise refunds, discounts or compensation. Explain the process and offer
   to forward the request.
3. Only state delivery dates that appear in <order_data>.
4. If the customer mentions injury, damage to property or legal action, apologise,
   do not discuss liability, and hand over to a human (see Escalation).

## Style
Friendly, calm and concise. Reply in the customer's language. Use the form of
address the customer uses. Up to 120 words unless the customer asks for detail.

## Format
Plain text with short paragraphs. Use a numbered list only for step-by-step
instructions. Include a link only if it appears in <context>.

## Escalation
If you cannot resolve the request, if the customer asks for a person, or if rule 4
applies, reply with your answer followed by the line:
HANDOVER: <one-sentence summary of the issue>

The company and details are invented for illustration. Note how the example separates the stable instructions from the variable data, which arrives in tagged blocks with each request.

Testing a system prompt

A system prompt is software; test it like software.

1. Write test conversations. Twenty to fifty is a good start. Include typical questions, edge cases, missing information, out-of-scope requests, frustrated customers, and attempts to make the assistant ignore its rules.
2. Define expected behaviour. For each test, note what a good answer must and must not contain.
3. Run and review. Score each answer as pass or fail against the expectations.
4. Change one thing at a time. Then re-run everything.
5. Re-test after model changes. Behaviour can shift between model versions.
6. Monitor live conversations. Sample real conversations regularly and add failures to the test set.

For the review side of live operation, see human-in-the-loop AI.

Using examples inside a system prompt

Showing one or two short example exchanges can set tone and format more effectively than describing them. Mark them clearly as examples and vary them, or the model may copy their wording. Few-shot prompting explains how to choose examples.

Security considerations

• A system prompt is not a lock. Determined users may be able to make a model reveal or ignore instructions. Enforce permissions in your application code: what data the assistant can access and which actions it can trigger.
• No secrets in the prompt. Never include API keys, passwords or internal data the user should not see.
• Treat inserted content as untrusted. Documents, emails or web pages placed in the context can contain instructions ("ignore previous rules"). Tell the model to treat context as information, not instructions, and back this up with technical controls.
• Limit actions. If the assistant can call tools, give it the minimum permissions and require confirmation for consequential actions.

Common mistakes

• Vague role descriptions. "Helpful assistant" gives no direction.
• Contradictory rules. "Be thorough" and "keep it short" without priorities.
• Burying important rules. Put critical rules near the top, numbered.
• Overlong prompts. Repeating the same instruction five ways costs tokens and can confuse rather than reinforce.
• No fallback. Without instructions for unknowns, the model improvises.
• Mixing variable data into the instructions. Keep user-specific data in separate, clearly marked blocks. It also keeps the stable part cache-friendly.
• No version control. Store system prompts in a repository or document with version history and an owner.

A quick drafting aid

If you are starting from a blank page, draft the role, task, rules and format with the AI prompt generator, then convert the result into the seven sections above. For the general principles behind good prompts, read the prompt engineering guide for business.