System Prompt

A system prompt is the instruction block a developer sends to a model before any user message, setting its role, rules, tone, and boundaries for the entire conversation that follows.

Most chat-based APIs separate messages into roles — system, user, assistant — and the system role is the one the end user never writes and, in most products, never even sees. It is where the product team encodes everything that should be true on every single turn: who the model is pretending to be, what it must never do, what format its answers should take, and what it should say when it does not know something.

How it works

Mechanically, the system prompt is just text placed first in the model's context, the same way any other instruction is — there is no separate reasoning channel unless a provider specifically implements one. Its power comes from position and persistence: it is present on every turn of the conversation, so instructions placed there survive far longer than something a user mentioned three messages ago and the model has since half-forgotten under "lost in the middle" pressure.

That persistence is also its limit. A system prompt is a strong influence, not an unbreakable rule — models can be argued out of instructions through a long enough or clever enough user conversation, which is why production systems that need hard guarantees back the system prompt with actual code-level checks rather than relying on the instruction alone.

Why it matters

The same base model, given two different system prompts, can behave like two different products. A system prompt is where "helpful general assistant" becomes "phishing-email triage analyst who only replies in a fixed JSON schema" or "customer support agent for a specific company who never discusses competitors." It is the single highest-leverage piece of text in most LLM applications, because unlike a user message it is not optional and not written by someone outside the team.

A worked example

No system prompt, user asks: "Can you cancel my order?" A generic model might apologize and explain it cannot access order systems, or might invent a plausible-sounding confirmation — either way, the behavior is unpredictable.

System prompt: "You are the support assistant for Northwind Outfitters. You may only discuss Northwind orders, shipping, and returns. You cannot cancel orders directly — instead, collect the order number and reason, then respond with a JSON object naming an escalate_cancellation action, the order id, and the reason. If asked about anything unrelated to Northwind, say so and redirect."

Same user question, same underlying model: the response is now a structured, parseable escalation object, scoped to exactly what the business wants handled automatically versus routed to a human. Nothing about the model changed — the system prompt turned a generic assistant into a specific, safe, integratable one.

How miatz teaches it

System prompts are the first artifact learners write in the miatz prompting module, using the COSTAR checklist to fill in role, rules, and format before a single user message is drafted. War Room drills include incidents where a system prompt was too loose — no scope boundary, no refusal behavior — and learners rewrite it against the same test conversation that broke the original.