System Prompt vs User Prompt vs Assistant Prompt

Part 7 mentioned a hidden system prompt shaping ChatGPT's behavior. This part covers the real, complete three-role structure — system, user, and assistant — that every real LLM API request is actually built from, the exact format part 16's real code sends directly.

The real, three roles

[
  {
    "role": "system",
    "content": "You are a customer support assistant for Bright Leaf Coffee. Be warm, concise, and only reference the real subscription plans provided below."
  },
  {
    "role": "user",
    "content": "What subscriptions do you offer?"
  }
]

system    → real, persistent instructions setting the model's role,
              tone, and constraints for the ENTIRE conversation
user      → what the real, actual person is asking or saying
assistant → the model's own previous real responses, when a
              conversation has multiple turns

This isn't a stylistic convention — it's the real, literal structure every major LLM provider's API expects, and it's the exact format the model was trained to interpret each role distinctly, not just concatenated plain text.

Why the system role exists, concretely

Without a system prompt: the model has no real, explicit guidance
  on WHO it's supposed to be or what real constraints apply — just
  the raw user message
With a real system prompt: role, tone, and real constraints are
  established once, applying consistently across every real user
  message in the conversation, without repeating them each time

This directly extends part 10's four prompt-engineering components — the system role is specifically where "role/context" and "constraints" genuinely belong, set once rather than repeated in every individual user message, which also directly reduces real, per-message token cost (part 8).

A real, multi-turn conversation, fully assembled

[
  { "role": "system", "content": "You are Bright Leaf Coffee's support assistant..." },
  { "role": "user", "content": "What subscriptions do you offer?" },
  { "role": "assistant", "content": "We offer a Gift Subscription ($18/mo) and a Monthly Subscription ($16/mo), both with free shipping." },
  { "role": "user", "content": "Can I switch between them?" }
]

This is exactly what part 9's context window has to hold, and exactly what part 18's real conversation-memory code builds and resends with every new message — the assistant's own prior real response is included as an assistant-role message, which is genuinely what lets the model's next answer ("Can I switch between them?") correctly understand "them" refers to the two plans just mentioned.

A real, practical system prompt for this series' actual project

You are a customer support assistant for Bright Leaf Coffee, a
small-batch coffee subscription business.

Only answer using the real subscription and shipping information
provided in this conversation. If you don't have the real
information needed to answer, say so directly rather than guessing.

Keep responses to 2-3 sentences. Be warm but direct.

This is the real, actual system prompt this series' project uses starting in part 16 — every component maps directly back to part 10's framework: role (a Bright Leaf Coffee support assistant), a real constraint against fabricating unavailable information (directly addressing part 13's hallucination coverage), and explicit format/tone constraints.

System prompts are not a real security boundary

A system prompt shapes behavior — it does NOT reliably prevent a
  determined real user from asking the model to ignore it entirely

This is a genuinely important, honest limitation worth knowing early: a system prompt is a real, effective tool for shaping typical, good-faith behavior, but it isn't a hard, guaranteed security boundary against a user deliberately trying to override it — a real, practical application handling anything sensitive needs real, additional safeguards outside the prompt itself, a topic beyond this series' beginner-to-intermediate scope but worth knowing exists.

Next: real prompt engineering techniques that actually work — few-shot examples, chain-of-thought, and other concrete, testable patterns beyond the basic structure covered so far.