System Prompts & Setting Behavior

Reviewed & published by Brayan K

A system prompt is the set-it-once instruction that tells an AI who it should be and how it should behave before the user types anything. It sets a persistent role, tone, and the rules the model follows on every turn.

Part of the free Prompt Engineering course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

The user turn carries the changing request; the system prompt stays stable underneath it. This lesson shows you how to write system prompts that produce consistent, reliable behavior.

What You'll Learn in This Lesson

• The system/developer message vs the user turn
• Setting a persistent role, tone, and constraints
• What instruction priority means in practice
• Why a stable system prompt gives consistent behavior
• Adding guardrails the model should always honor
• Examples of strong, reusable system prompts

1 The system message vs the user turn

The system prompt sets durable behavior. The user turn is the specific, changing request. Keep the role in one and the question in the other:

User turn (varies each time)

2 Constraints, guardrails, and priority

Guardrails are rules that bound what the AI may do. Because system instructions generally outrank a conflicting user request, putting limits in the system prompt makes them stick:

No audience, tone, or limits, so behavior drifts.

Role, audience, tone, and a clear guardrail.

3 Keep it stable, vary the user content

Stability is what gives consistent behavior. Rewrite the rules every turn and the voice drifts. Freeze the system prompt and let the user request be the only thing that changes.

Fill that template once and reuse it; only the user turn underneath should change from request to request.

Try it for real

A system prompt is just one message in a list, tagged with a role. Build that list in code and the advice above becomes something you can check: compare the system layer across two requests and prove it is identical, then diff two versions of the rules to see exactly what every future turn inherits. No model is called.

# A system prompt is not magic. It is one message in a list, tagged with a role.
# Build the list in code and you can PROVE the stable part stays stable, and diff
# two versions to see exactly what every future turn inherits.

import difflib

def compose_system(role, audience, tone, constraints):
    """Fill the ROLE / AUDIENCE / TONE / CONSTRAINTS template from section 3."""
    lines = [f"ROLE: {role}", f"AUDIENCE: {audience}", f"TONE: {tone}", "CONSTRAINTS:"]
    lines += [f"- {c}" for c in constraints]
    return "\n".join(lines)

SYSTEM = compose_system(
    role="customer-support agent for a bike shop",
    audience="customers who may know nothing about bikes",
    tone="warm, clear, brief",
    constraints=["never share internal pricing", "never promise a delivery date"],
)

def conversation(user_text):
    """The system layer is the SAME text every time; only the user turn changes."""
    return [{"role": "system", "content": SYSTEM}, {"role": "user", "content": user_text}]

a = conversation("My gears keep slipping. What should I check first?")
b = conversation("Do you sell child seats?")

print("--- what the model receives for request A ---")
for msg in a:
    print(f"[{msg['role']}]")
    print(msg["content"])

# 1) Prove the stable part is stable: the two system messages are equal.
print()
print("system layer identical across A and B:", a[0] == b[0])
print("user layer identical across A and B:  ", a[1] == b[1])

# 2) Diff the two whole conversations. Only the user line should change.
def flatten(msgs):
    return [f"{m['role']}: {line}" for m in msgs for line in m["content"].split("\n")]

print()
print("--- diff of conversation A vs B (only changed lines are shown) ---")
for line in difflib.unified_diff(flatten(a), flatten(b), "A", "B", lineterm="", n=0):
    print(line)

# 3) Change the RULES instead, and the diff shows the one line that every
#    future turn will now inherit.
SYSTEM_V2 = SYSTEM + "\n- if asked for something the rules forbid, decline politely"
print()
print("--- diff of system prompt v1 vs v2 ---")
for line in difflib.unified_diff(SYSTEM.split("\n"), SYSTEM_V2.split("\n"), "v1", "v2", lineterm="", n=0):
    print(line)

# Instruction priority (system outranks user) is enforced by the model's training,
# not by this code. What this code guarantees is simpler: the rules are present,
# unchanged, on every single turn.

# Run it. The first lines you should see are below; the rest follows.

# ✅ Expected output:
# --- what the model receives for request A ---
# [system]
# ROLE: customer-support agent for a bike shop
# AUDIENCE: customers who may know nothing about bikes
# TONE: warm, clear, brief
# CONSTRAINTS:
# - never share internal pricing
# - never promise a delivery date
# [user]
# My gears keep slipping. What should I check first?

# 🎯 YOUR TURN — build the two-layer message list and prove the system layer never changes.

def compose_system(role, tone, constraints):
    lines = ["ROLE: " + role, "TONE: " + tone, "CONSTRAINTS:"]
    # 1) One bullet line per constraint.
    lines += ["- " + c for c in ___]
    # 👉 replace ___ with  constraints
    return "\n".join(lines)

SYSTEM = compose_system("tutor for 5th graders", "friendly, simple", ["never give the full answer outright"])

def conversation(user_text):
    # 2) The first message is tagged with the role that makes it persistent.
    return [{"role": ___, "content": SYSTEM}, {"role": "user", "content": user_text}]
    # 👉 replace ___ with  "system"

a = conversation("What is 7 x 8?")
b = conversation("How do I spell 'necessary'?")

print(a[0]["content"])
# 3) Compare the system message of conversation a with the system message of b.
print("same system layer:", a[0] == b[___])
# 👉 replace ___ with  0
print("same user layer:", a[1] == b[1])

# ✅ Expected output:
# ROLE: tutor for 5th graders
# TONE: friendly, simple
# CONSTRAINTS:
# - never give the full answer outright
# same system layer: True
# same user layer: False

Common Mistakes (and the fix)

• Putting the changing request in the system prompt. — Keep the role there; put the task in the user turn.
• Vague role like 'be helpful'. — Name the audience, tone, and limits.
• Rewriting the rules every turn. — Freeze the system prompt; vary only the user content.
• No guardrails. — State clearly what the AI must never do.

⏱ Test Yourself — Timed Quiz

10 quick questions, 12 seconds each. Instant feedback — beat the clock!

🎉 Lesson Complete

• ✅ The system prompt sets persistent role, tone, and rules
• ✅ The user turn carries the changing request
• ✅ System instructions generally outrank conflicting user input
• ✅ Guardrails belong in the system prompt so they stick
• ✅ Keep it stable; vary only the user content for consistency

Practice quiz

Continue this course

• Previous: Reusable Prompt Templates & Cheat Sheet
• Next: Structured Output: JSON & Schemas — Get reliable machine-readable output with schemas, JSON mode and validation

Frequently asked questions

What is a system prompt in plain English?

It is a set-it-once instruction that tells the AI who it should be and how it should behave before the user types anything. Think of it as the job description and house rules you give a new assistant: 'You are a concise support agent, always polite, never share internal pricing.' Every user message that follows is answered with those rules in mind.

How is the system prompt different from what I normally type?

What you normally type is the user turn, the specific request that changes each time, like 'summarize this email.' The system prompt is the persistent layer underneath that sets role, tone, and constraints. The user content varies constantly; the system prompt stays stable so behavior is consistent.

Why should the system prompt stay stable?

Stability is what gives you predictable behavior. If you rewrite the rules on every turn, the AI's voice and limits drift. Keeping the system prompt fixed while only the user request varies means the same tone, the same guardrails, and the same role apply no matter what is asked.

What is instruction priority?

When instructions conflict, system or developer instructions generally outrank a user request. So if your system prompt forbids sharing certain information, a user asking for it should be politely declined. This priority is what makes guardrails meaningful rather than easily overridden.