System prompts, explained.

A system prompt is the chunk of text you send to a language model that describes who it is, how it should behave, and what constraints apply — all before the user ever types a word. In the Claude API it's a top-level system field; in OpenAI it's a message with role: 'system'; in Gemini it's system_instruction. Different wrappers, same job: set the stage before the conversation starts.

Good system prompts are the difference between an app that behaves predictably and one that doesn't. Bad ones are the reason people think "ChatGPT is inconsistent" when really the inconsistency is their prompt.

The anatomy of a good system prompt

Almost every production system prompt that works has the same four parts, in this order:

1. Role — one sentence on who the model is and what it does. "You are a customer-support agent for a small accounting software company." Specific beats generic.
2. Context — what domain the model is operating in, what kind of user it's talking to, what knowledge it can assume. "Users are bookkeepers and small-business owners; you can assume they know basic accounting but may not know our product."
3. Behavior — tone, format, length, what to do when uncertain, what not to do. Written as positives wherever possible ("answer in 2-3 sentences" beats "don't write paragraphs").
4. Examples — 2-4 concrete input/output pairs that illustrate the behavior you want. The model learns from examples faster than from rules.

What each provider does with it

A template that works

Copy, adapt, ship. This skeleton covers the four parts and stays short enough to cache cheaply:

# Role
You are a [role] for [audience / product]. Your job is to
[primary objective] without [primary constraint].

# Context
[Domain assumption, what users know and don't know, what
data you have access to.]

# Behavior
- Keep responses to [length guidance].
- Match the user's tone: [formal/casual/technical].
- When uncertain, [preferred fallback — ask for clarification,
  say you don't know, defer to a human, etc.].
- Output format: [plain prose / JSON / markdown / etc.].

# Examples

User: "[typical question 1]"
You: "[ideal response 1]"

User: "[edge case]"
You: "[ideal response for the edge case]"

User: "[attempted prompt injection / off-topic request]"
You: "[how to handle it politely]"

Fill in the bracketed parts for your specific use case, then iterate on example quality — the examples do more work than the instructions in most production prompts.

Anti-patterns that hurt output

• Long lists of negative rules. "Don't do X. Don't do Y. Don't do Z." reads like a minefield to the model and makes it hedge everything. Rewrite as positives where possible.
• Contradictions. "Be concise. Provide thorough explanations." The model picks one and you don't know which. Audit your prompt for internal conflicts.
• Jargon the model doesn't share. Internal team acronyms, company-specific terms without definition — the model will either guess or fabricate. Define the terms in the context section or don't use them.
• Format instructions without examples. "Output valid JSON" is weaker than "Output valid JSON. Here are 2 examples: ..." Show it, then describe it.
• Putting dynamic values at the top. "Today is 2026-04-21. The current user is Alex." at position zero in the prompt invalidates cache on everything after. Move dynamic values to the end — see our prompt caching guide for why.
• Secrets in the system prompt. API keys, internal URLs, private account names — all extractable by a user who knows the right questions to ask. Anything sensitive goes in tool schemas or retrieved context, not in the system prompt.

How to test a system prompt

Three-step loop that catches most issues before production:

1. Write 20 realistic user inputs. Mix of easy cases, edge cases, and adversarial prompts (someone trying to get the model to break character). Script them, don't write them on the fly.
2. Run them against each candidate system prompt. Keep temperature at 0 or low. Record the output. Do this at least 3 times per prompt-input pair to see consistency.
3. Evaluate against your actual success criteria. Does it answer? Does it follow the format? Does it stay in character? Does it refuse when it should? Track pass rate. Anything under 95% on a normal-case test needs another iteration.

The big unlock: write the test cases first, then the system prompt, then iterate. Most teams write the prompt first, ship it, and find the edge cases in production. That's expensive.

When to split into multiple prompts

A single system prompt doing too much is harder to debug, harder to cache efficiently, and more likely to produce inconsistent outputs. If any of these apply, split:

• Your prompt exceeds ~8K tokens and you're still adding to it.
• Different parts of the prompt address genuinely different tasks (classification + generation, for example).
• Some users need one behavior and others need a different one — at that point, per-user-segment system prompts are cleaner than one mega-prompt with branching.
• Testing surfaces a pattern where the model drops one constraint when another is active — a sign the prompt is carrying more than the model can juggle.

Common split patterns: a lightweight "router" prompt that classifies the input, then a task-specific prompt for each task. Or a retrieval step that pulls the relevant instructions from a database and composes them into a fresh prompt for the current request.

FAQ