System Prompt Architecture for Production

System Prompts as Architecture

In casual use, a system prompt is an instruction you give a model before the conversation starts. In production, it is something more fundamental: it defines the model's identity, constraints, knowledge context, and behavioural boundaries for every subsequent interaction. Change the system prompt and you change the application. Most production AI failures — inappropriate responses, scope violations, inconsistent tone — trace back to a poorly designed system prompt.

Professional system prompt design is architectural work. It requires thinking about what the model should and should not do, in what order those constraints should be stated, how they interact with user inputs, and how they behave under adversarial conditions. This lesson treats system prompts with that level of seriousness.

The Six-Element Structure

Research and practitioner experience converge on a consistent ordering of system prompt elements. Each element should appear in this sequence, because the model processes system prompt tokens in order and earlier elements establish the frame for interpreting later ones:

1. Role and identity assignment: Who the model is in this application. Be specific — "a senior customer support specialist for TechCorp with expertise in enterprise software" constrains outputs far more precisely than "a helpful assistant."
2. Task context: What the model is being used for and what it should accomplish. The scope of the application — what problems it exists to solve.
3. Behavioural guidelines: Tone, communication style, formality level, and approach. Should the model be warm or professional? Concise or thorough? Proactive or responsive?
4. Detailed task rules: Specific constraints, formatting requirements, decision logic. What to do when the user asks about X, how to handle edge case Y, required output structure.
5. Safety and scope constraints: What the model must not do. Confidentiality requirements, topics that are out of scope, escalation paths. This comes after the positive specification, not before, because you need to define what you want before you can precisely define the exceptions.
6. Output format specification: The structure, markup, and serialisation requirements for outputs. Markdown or plain text? Numbered lists or prose? JSON schema?

Instruction Hierarchy: What Overrides What

Each major model provider has a published instruction hierarchy that determines which instructions take precedence when they conflict.

Claude (Anthropic): System prompt instructions take precedence over user instructions, which take precedence over assistant messages. However, Claude's model spec explicitly allows users to override some system prompt behaviours within limits — a user can ask Claude to change its output format even if the system prompt specifies one, unless the system prompt explicitly prohibits format changes. Anthropic is the only major provider that publishes its system prompts publicly, offering transparency about how the hierarchy works in practice.

GPT-4.1+ (OpenAI): A significant shift in GPT-4.1 (2025) was a move toward more literal instruction following with less intent inference. Earlier GPT-4 versions would infer what you meant when your instructions were ambiguous. GPT-4.1+ follows instructions more literally and requires more explicit specification. Ambiguous instructions that worked in GPT-4 may produce unpredictable behaviour in GPT-4.1. For GPT-4.1+, specify edge cases explicitly — do not assume the model will infer your intent.

Gemini (Google): Similar three-tier hierarchy (system, user, assistant). System instructions take precedence, though Google's documentation is less explicit about the specific conflict-resolution rules. In practice, Gemini responds well to structured system prompts with explicit constraint sections.

Why Negative Instructions Fail

A consistent finding in prompt engineering research: negative instructions — "do not discuss competitors," "never provide medical advice," "don't be too technical" — are significantly less reliable than positive instructions. Multiple studies show that models struggle with negation, and larger models do not reliably improve on this. The failure mode is that "do not do X" leaves the model uncertain about what it should do instead.

The fix is always to convert negatives to positives:

• Instead of: "Do not include personal opinions."
  Use: "Provide analysis based exclusively on verified facts and published data, without subjective interpretation."
• Instead of: "Don't be too technical."
  Use: "Explain concepts using plain language and everyday analogies, accessible to someone without a technical background."
• Instead of: "Never mention competitor products."
  Use: "When asked about alternatives, focus only on [your product]'s capabilities and how they address the user's need."

This conversion works because it tells the model what to do rather than what not to do — providing a positive target the model can reliably hit.

Jailbreak Resistance

Anthropic's Constitutional Classifiers (February 2025) reduced jailbreak success rates from 86% to 4.4% — a greater than 95% reduction. This is a model-level defence, not a prompt-level one. But at the prompt level, there are patterns that improve resistance:

• Explicit constraint placement: State core safety constraints in the system prompt, not as afterthoughts in user-facing instructions. System prompt content is harder to override than user-turn instructions.
• Positive framing of constraints: "This assistant answers questions only about [domain]. For all other topics, it responds with: 'I'm here to help with [domain] questions.'" is more robust than "This assistant refuses to answer questions outside of [domain]."
• No reliance on instruction confidentiality: Assume users will attempt to extract your system prompt. Design system prompts that work even when the user knows their contents. Security through obscurity is not a defence — correct by design is.

Claude specifically: Anthropic publishes Claude's system prompts. This transparency is intentional and reflects a philosophy that good constraints should hold up to scrutiny rather than depend on secrecy.

Using XML Tags in Claude System Prompts

Claude is specifically trained to interpret XML-tagged content with higher precision than unstructured text. Using XML tags in your system prompt creates clear, parseable structure that reduces ambiguity:

<role>You are a senior product analyst for AcmeCo.</role>

<task>Help users interpret sales data and generate actionable insights.</task>

<constraints>
- Provide analysis based on data provided; do not fabricate numbers
- If data is insufficient, specify exactly what additional information is needed
- Output format: structured sections with headers
</constraints>

GPT-4o and Gemini also process XML-tagged content reliably, though they are not specifically trained on it to the same degree as Claude. XML tagging is a safe universal convention across all major models.