Designing System Prompts for Consistent AI Behaviour

A practical system prompt structure, principles from Anthropic and OpenAI guidance, and a Thai online-shop chatbot example.

Your shop's chatbot answers the first customer politely, writes the second one an essay, and promises the third a discount your shop has never offered. Same model every time. This "good day, bad day" behaviour usually comes from a system prompt that is either too loose or so packed that its rules contradict each other.

What is a system prompt?

A system prompt is the set of instructions placed before the conversation starts. It frames who the AI is, what it does, what it does not do and how it answers, separate from the prompt a user types each time. OpenAI's prompting guide recommends putting overall guidance such as role and tone in the system message, and keeping task-specific details and examples in user messages.

This article focuses on design for reusable setups such as chatbots, internal assistants or custom GPTs. If you are new to prompting, start with What is Prompt Engineering.

Five principles from model developers' guidance

1. A short role helps

Anthropic's prompting guide says that setting a role, "even a single sentence", makes a difference because it focuses behaviour and tone.

2. Give reasons, not just rules

Anthropic's example: instead of "never use ellipses", explain that "your response will be read aloud by a text-to-speech engine, so never use ellipses". The model can generalise the reason to cases you did not write down.

3. Say what to do, not what to avoid

"Answer in flowing paragraphs" works better than "do not use bullets" because the model knows the target.

4. Separate the parts clearly

Use headings or XML-style tags such as <rules> and <context> to separate instructions, data and examples, so the model never confuses which part is an instruction.

5. Write at the right altitude

Anthropic's context engineering article warns that long if-else rules make systems brittle, while vague guidance makes the model guess. Start short and add only where the model actually fails.

A recommended structure

1. Role and goal: who the AI is, who it helps and why.
2. Scope: what it can answer, and what it must hand to a human.
3. Reference data: policies, prices, conditions (or which tool to look them up with).
4. Answer format: length, language, tone.
5. When unsure: ask a clarifying question or say plainly that it does not know.

Example: an online clothing shop chatbot

You are the chat assistant for an online clothing shop. Help customers choose sizes, check order status and understand the return policy. Reply in polite, friendly Thai in no more than 4 sentences, because most customers read on mobile. Use only the information in <policy>. If a question involves discounts or exceptions not in the policy, say you will pass it to an admin, because the shop does not want to promise what it cannot deliver.

Notice that each instruction carries a reason, and there is a clear way out for out-of-scope questions.

A good system prompt is not the longest one. It is the one that makes the AI decide the same way every time in the same situation.

Common symptoms and fixes

• Answers too long: state the length as a number with a reason, such as a maximum number of sentences because customers read on mobile.
• Making things up: tell it to use only the information provided, and what to do when the information is missing.
• Tone drifting: include 2 to 3 examples of good answers instead of describing the tone with adjectives alone.
• Following user requests that break the rules: state clearly that the rules in the system prompt take priority.

Things to watch out for

• No system prompt is 100% attack-proof. Never put passwords, API keys or secrets in a prompt.
• Conflicting rules, such as "be as brief as possible" and "explain in detail", make results inconsistent. Reread the whole set.
• Changing the model or version can change behaviour. Retest every time.

How to start

1. Write a short first version using the five-part structure above.
2. Prepare 20 to 30 test questions, including hard and out-of-scope ones.
3. Run them, note the failures, and add an instruction with its reason only at those points.
4. Keep every version so you can roll back when a change makes things worse.

To go further into designing everything the model sees, read Context Engineering next. And if you are looking for roles that use this skill, search the Plants.work jobs page.