System vs. User Prompts

This guide will help you separate policy from task so your model follows instructions more reliably. “Policy” is the standing rule set that governs tone, format, and boundaries. “Task” is the specific thing you want done right now. When these get mixed together, responses drift, formats wobble, and quality drops.

A system prompt carries the policy. It sets voice, role, safety boundaries, and formatting defaults. A user prompt carries the task: the concrete input, context, and the question or request.

Why this matters: models are sensitive to how instructions are framed. Keeping policy in the system prompt reduces “compliance drift” (the model gradually ignoring parts of your instructions) and makes it easier to reuse the same standards across many tasks.

We’ll use a small mental model, walk through one example, and give you copy-paste prompts. You’ll finish with a short lab that shows how moving instructions to the system prompt improves consistency.

Think of a café. The café’s house rules (quiet tone, no profanity, receipts printed in a standard format) are policy. Each customer order (one cappuccino with oat milk) is the task. If every customer had to repeat the rules with their order, mistakes would rise. Instead, the barista follows house rules every time, then executes each order.

💡 Insight: The system prompt is the café’s laminated card; the user prompt is the order slip.

Compact example

• Policy (system): “You are a polite writing assistant. Always respond in 3 bullet points and end with one italicized takeaway.”

• Task (user): “Summarize this paragraph about photosynthesis.”

We’ll rewrite a mixed prompt and split it cleanly.

Before (mixed, fragile) The user message tries to do everything at once:

Please summarize the text below in exactly three bullets, be professional but warm, no emojis, end with a one-line italicized takeaway, and avoid jargon. Text: “Large language models…”

This often works once, but formats tend to drift across multiple runs.

After (separated, stable)

System (policy):

User (task):

Summarize the following text for a busy reader:
“Large language models…”

What changes: the reusable rules live in one place. The task is short and focused. If you repeat the task with new text, the model keeps the same format and tone.

⚠️ Pitfall: Duplicating policy in the user prompt can create conflicts. When system and user disagree, models often follow the latest or strongest phrasing, which increases drift.

Starter system prompt (reuse this):

User prompt template (fill in the blanks):

Vague vs. precise (beginner win)

• Vague user prompt: “Explain RAG.”

• Precise user prompt under the same system policy:

  jsonCopy

  TASK: Explain Retrieval-Augmented Generation to a product manager. CONTEXT: PM knows search and APIs, not ML math. GOAL: 3 bullets + one italic takeaway the PM could repeat to a VP.

You’ll see the system policy keep tone and structure steady while the task steers the content.

When results drift, first look for instruction collisions. If the user prompt re-states tone or format differently (“be witty; use emojis”), the model may favor the latest instruction. Keep policy single-sourced in the system prompt and keep the user prompt about content, not behavior.

Short policies are easier to follow. Long, tangled system prompts can reduce clarity. Start small; add rules only when a real failure suggests you need them. Finally, remember that not all models weigh system instructions equally; test with your chosen model before standardizing.

Quick fixes to try next:

1. Remove behavior words from the user prompt (“be polite”, “write 5 bullets”).

2. Strengthen policy verbs (“Always”, “Exactly N bullets”, “Never use emojis”).

3. Add a fallback line: “If unsure, ask for X; otherwise proceed.”

4. Tighten counts and ordering (“exactly 3 bullets, then one italic line”).

You’ll run two short experiments and score compliance. “Compliance drift” means the model starts missing your policy over repeated runs.

Step 1 — Baseline (instructions in user):

• System: (leave empty or generic)

• User (run this 3 times):

  Write in a warm, concise tone with no emojis or jargon.
  Respond in exactly 3 bullets, then a single italicized takeaway.
  Topic: Why teams should write acceptance criteria.

Score each run (0–2 per item): Tone (warm, concise), Format (3 bullets), Closure (one italic line). Max 6 per run.

Step 2 — Policy moved to system:

• System:

  Policy:
  - Tone: warm, concise; no emojis, no jargon.
  - Format: exactly 3 bullets.
  - Closure: end with a single italicized takeaway line.

• User (run this 3 times):

  Topic: Why teams should write acceptance criteria.

Compare the average scores. You should see higher and steadier scores in Step 2.

Expected output snippet (when compliant):

• Acceptance criteria create a shared definition of “done,” reducing rework.

• They make edge cases visible early, cutting surprises during QA.

• Clear criteria support faster reviews and healthier team debates.
  

If your outputs fluctuate, re-check for hidden conflicts in the user prompt.

Separating policy (system) from task (user) is the simplest way to improve consistency. The system prompt carries durable rules—tone, structure, safety—while the user prompt carries the immediate request. This reduces collisions and makes results easier to predict.

Common pitfalls include repeating behavior instructions in the user message and letting the system policy bloat. Start with a crisp policy, keep user prompts content-focused, and measure results with a tiny rubric so you can see drift, not guess at it.

As you practice, you’ll build a small library of system policies for different jobs (explainers, analysts, critics). Reuse them, swap tasks in and out, and your outputs will feel intentionally consistent.

Next steps

1. Turn one of your frequent tasks into a policy+task pair and save both templates.

2. Run the drift lab on your model of choice and keep the scoring rubric in your notes.

3. Add a single new rule to your policy (e.g., citation style) and test if compliance stays stable.