Anatomy of a production system prompt

AA system prompt is the set of instructions a model receives before every conversation. In a demo, it can be one sentence. In production, it is effectively part of your application code: it decides how the product behaves across thousands of situations nobody tested by hand, and every word is paid for on every request.

Good production prompts share a recognisable structure. This guide walks through the seven sections that matter, the order that works best, what to leave out, and how to test and maintain prompts as they evolve. For complete, copy-ready examples built on this structure, see system prompt templates for production.

The seven sections

1. Role and goal

Describe the job, not a personality. "You are the support assistant for Acme's invoicing software. Your goal is to resolve billing questions accurately in as few messages as possible" is more useful than "You are a world-class, friendly expert." Persona adjectives rarely change behaviour measurably; a concrete goal does.

2. Context

Give the model facts it cannot know: what the product is, who the users are, today's date, the user's plan or locale if relevant. Keep it factual. If context changes per request (user name, account tier), insert it with clearly labelled variables, and keep the stable parts first so prompt caching can reuse them.

3. Knowledge rules

Say where answers should come from and what to do when the sources do not cover a question. This single section prevents most hallucinated policies.

• "Answer only from the documents in <docs>."
• "If the documents do not answer the question, say so and offer to connect the user with a human."
• "When sources conflict, mention both and cite them."

For grounding and citation techniques, see prompting for citations that actually check out.

4. Behaviour rules

Rules about tone, length, scope and escalation. Write them as positive instructions that describe the desired behaviour, rather than prohibitions; "don't" instructions are unreliable and can even plant the idea you want to avoid; see why "don't do X" instructions fail.

Make every rule testable. "Be concise" is vague; "keep answers under 120 words unless the user asks for detail" can be checked automatically.

5. Tools

For each tool, say when to use it, what inputs it needs, and what to do when information is missing. Mark actions that require confirmation: "Before issuing a refund, summarise the amount and reason and ask the user to confirm." Detailed tool descriptions belong in the tool definitions; the system prompt covers when and why.

6. Output format

Specify the exact shape: plain text with a length limit, Markdown with specific headings, or a JSON schema. Show a literal template rather than describing it. For machine-readable output, see structured output without JSON mode.

7. Examples

Examples are powerful and easy to misuse. One to three short examples of difficult cases, such as an ambiguous request or a refusal, often help more than a page of rules. But models copy examples closely, including their length, phrasing and content. Read few-shot examples that don't backfire before adding them.

Order and formatting

• Put stable content first (role, rules, format) and variable content later (user context, retrieved documents), which helps caching and keeps instructions consistent.
• Use clear delimiters such as XML-style tags or headings to separate sections and to mark untrusted content (<docs>...</docs>, <user_data>...</user_data>).
• Restate the single most important constraint near the end for long prompts, where the model is attending to the most recent context.
• Keep it scannable. Short sections and lists are easier for both models and maintainers than dense prose.

What to leave out

• Secrets. Users can often extract system prompts. Never include credentials, internal URLs or security logic; enforce permissions in code.
• Untestable aspirations ("always be maximally helpful and accurate").
• Contradictory rules accumulated from past incidents. Each new rule should be checked against existing ones.
• Long lists of forbidden topics. Describe the scope instead, and give a standard response for out-of-scope requests.
• Instructions the model already follows by default. They cost tokens on every request.

Common anti-patterns, and what to do instead

A few patterns appear in almost every prompt that has grown without review:

• The incident log. Each production problem adds a rule ("Never mention competitor X," "Do not say 'unfortunately'"). After a year, the prompt is a list of special cases that conflict with each other. Instead, group rules by behaviour and rewrite them as general principles with one example each.
• Shouting. Capital letters and words like "CRITICAL" or "ABSOLUTELY NEVER" are a sign that a rule is not working. Emphasis can help a little, but overuse makes every rule equally loud. Fix the underlying ambiguity instead, or enforce the behaviour in code.
• Hidden format rules. Format instructions buried in the middle of a long behaviour section are followed inconsistently. Keep format in its own section, near the end, with a literal template.
• Copying another product's prompt. Leaked or published prompts from other products are tuned for their models, users and risks. Use them for ideas, not as a starting point.
• Prompt as policy document. Pasting a 20-page policy into the system prompt makes every request expensive and buries the rules that matter. Retrieve the relevant policy sections per request instead.

Testing and maintenance

Treat the system prompt as code:

1. Version it in source control with a changelog.
2. Pair it with an eval set covering normal, edge-case and adversarial inputs. Run the eval for every change.
3. Change one thing at a time, so you know what caused an improvement or a regression.
4. Read changed outputs, not just scores. A new rule can quietly change behaviour on cases you did not intend to affect.
5. Prune regularly. Remove rules that no eval case depends on; if behaviour does not change, the rule was not needed.
6. Re-test when models change. Prompts tuned for one model can behave differently on another.

A skeleton to start from

<role>
You are {assistant} for {product}. Your goal: {measurable goal}.
</role>

<context>
Users: {who}. Today: {date}. User plan: {plan}.
</context>

<knowledge>
Answer only from <docs>. If <docs> does not cover the question, say so and offer {fallback}.
</knowledge>

<behaviour>
- {length rule}
- {tone rule}
- Escalate to a human when: {triggers}.
</behaviour>

<tools>
- {tool}: use when {condition}; confirm with the user before {risky action}.
</tools>

<format>
{template or schema}
</format>

Frequently asked questions

What is a system prompt?

A system prompt is the set of standing instructions given to a language model before the user's messages, defining its role, rules, knowledge sources, tools and output format for every conversation.

How long should a production system prompt be?

Long enough to cover the behaviours you test and no longer. Many effective production prompts are a few hundred words. Every rule should correspond to a behaviour you can check in an eval.

What is the best structure for a system prompt?

A reliable order is: role and goal, context, knowledge rules, behaviour rules, tools, output format and optional examples, with clear delimiters between sections and stable content placed first.

How do I test changes to a system prompt?

Run the new and old versions against the same eval set covering normal, edge-case and adversarial inputs, compare scores with confidence intervals, and read every output that changed.