PM-301a · Module 1

What the System Prompt Actually Does

4 min read

The system prompt and the user prompt are not equal. The system prompt occupies a privileged position in the context window — it appears first, it establishes the frame for everything that follows, and most models give it higher attentional weight during generation. The user prompt operates inside the constraints the system prompt defines.

Think of the context window as a legal document. The system prompt is the governing contract — the definitions, the scope, the constraints, the obligations. The user prompt is the specific request submitted under that contract. When a user prompt conflicts with the system prompt, the system prompt wins — or it should, and if it does not, you have a hardening problem we will address in Lesson 9.

Practical consequence: anything you want to be true across all interactions belongs in the system prompt. Persona, output format, response length, prohibited topics, required disclaimers, grounding documents, available tools — specify them once in the system prompt rather than repeating them in every user prompt. The system prompt is overhead you pay once. Every clause you omit there becomes a clause you must write in every downstream prompt.

Do This

  • Put persona, role, and behavioral constraints in the system prompt
  • Define output format requirements in the system prompt
  • Inject static context (org info, date, available tools) in the system prompt
  • Write system prompts as if they will be read once and govern forever

Avoid This

  • Repeat behavioral constraints in every user prompt
  • Leave format requirements implicit and correct them after the fact
  • Put static context in the user turn where it competes with the actual request
  • Treat system prompts as suggestions rather than governing specifications