A system prompt is a set of standing instructions given to an AI model before the conversation begins. It tells the model who it is, what it should and should not do, and how to format its answers. The user's message is the request of the moment; the system prompt is the brief that applies to every request. It matters because it is the cheapest, most reusable way to make an AI behave consistently across a team.
System prompt vs user prompt
Think of a new employee. The system prompt is the job description and the house rules they receive on day one. The user prompt is the task a colleague hands them on Tuesday afternoon.
- System prompt: written once by whoever builds or configures the tool. It sets role, tone, boundaries, output format and background the model should always remember.
- User prompt: written each time by the person asking. It carries the specific task, the data to work on and any one-off preferences.
When the two conflict, a well-designed setup treats the system prompt as the baseline and the user message as a request within those limits. If you want a refresher on writing the user side, see our guide on how to write a good prompt for Claude.
Where you will meet system prompts
You may never type the words "system prompt" and still use one every day. They appear in several places:
- Custom instructions and project settings. Many AI tools let you save standing instructions that apply to every chat in a workspace. A Claude Project is one example of this idea: shared context and instructions that persist across conversations.
- Internal assistants. A company chatbot for HR questions or customer replies is usually a general model plus a carefully written system prompt and some reference documents.
- Developer applications. When a developer calls an AI model through an API, the system prompt is a separate field from the user messages.
The exact names and settings differ between products and change over time, so check the current options in the tool you use. The concept stays the same.
What to put in a system prompt
A good system prompt is short enough to maintain and specific enough to change behaviour. These are the building blocks most teams find useful:
- Role and audience. "You are a support assistant for a Malaysian accounting firm, writing to small-business owners who are not accountants."
- Goal. What a successful answer looks like, in one or two sentences.
- Rules and boundaries. What to refuse, what to escalate to a human, and what to say when the answer is not known. For example: "If the question is about tax advice, explain the general concept and recommend confirming with the firm's tax team."
- Tone and language. Formal or friendly, English or Bahasa Malaysia, British or American spelling.
- Output format. Bullet points, a table, a fixed template, a maximum length. When you need structured inputs, clear delimiters such as XML tags in prompts help the model separate instructions from data.
- Reference material. Product facts, policies or glossary terms the model should rely on instead of guessing.
- One or two examples. A sample input with the ideal output often communicates the standard better than a paragraph of description.
Common mistakes
- Writing a wall of rules. Long lists of "never" and "always" tend to conflict with each other. Prioritise the few rules that matter and explain the reason behind them.
- Vague instructions. "Be professional" means different things to different people. "Write in short paragraphs, address the customer by name, and avoid slang" is testable.
- Putting secrets in it. Treat a system prompt as something a determined user might coax out. Never place passwords, API keys or confidential data in it.
- Treating it as security. A system prompt guides behaviour; it is not an access-control mechanism. Anything the assistant must not reveal should not be given to it in the first place. Review our guidance on putting customer data into Claude before connecting real records.
- Never testing it. A prompt that works on your three favourite questions can fail on the fourth.
How teams maintain system prompts
Once an assistant is used by many people, its system prompt becomes a small piece of company infrastructure. Teams that keep results consistent usually do the following:
- Assign an owner. One named person or team approves changes, so the prompt does not drift through informal edits.
- Keep a version history. Store the prompt in a shared document or code repository with dated changes and the reason for each.
- Build a small test set. Collect 10 to 20 realistic questions, including awkward ones, and re-run them after every change. Compare answers against what a good one looks like.
- Review after incidents. If the assistant gives a wrong or off-brand answer, add that case to the test set and fix the prompt.
- Align with policy. The prompt should reflect your approved-use rules, such as what data may be entered. A company AI usage policy is the natural source for those boundaries.
How system prompts relate to training and certification
Writing effective system prompts is one of the practical skills covered in hands-on AI training. Agmo Studio, a Select Partner of the Anthropic Claude Partner Network, runs workshops through Agmo Academy where participants practise instructions, structure and evaluation on real work scenarios. See AI training in Malaysia for programs, or in-house training if you want a team-specific session built around your own workflows.
A simple way to start
Pick one repeated task, such as drafting replies to a common customer enquiry. Write a system prompt with a role, a goal, three rules and one example. Run it on ten past enquiries, note where it falls short, and revise. After two or three rounds you will have something your colleagues can reuse, and you will have learned more than any article can teach.