System Prompt

Think of the system prompt as a job description plus work instructions: "You are the support assistant for Company X. You answer only questions about our products, exclusively based on the provided knowledge base. For price negotiations, complaints or legal questions, you escalate to a human. You make no binding commitments."

The clearer this core instruction, the more predictable the behaviour. Vague system prompts are one of the most common reasons AI systems over-promise, drift off-topic or overstep their remit.

System prompts should be versioned and tested like code: every change is checked against real example cases before going live. Technical guardrails add an extra layer of security beyond what the prompt alone can guarantee — for instance, ensuring an agent simply cannot execute certain actions, regardless of what the text says.

Proven elements: role and mandate (who am I, what am I responsible for), knowledge foundation (what can I rely on, what's off-limits), tone (formal, casual, multilingual?), escalation rules (when and how do I hand over to humans), explicit prohibitions (no price commitments, no legal advice) and behaviour under uncertainty (ask rather than guess).

An underestimated point is prioritisation when goals conflict: what takes precedence if helpfulness and caution collide? Good system prompts answer this explicitly ('When in doubt, make no commitment and escalate') — because it's precisely in these grey areas that embarrassing or costly errors happen.

The best source for this content isn't technology but the business unit itself: whoever handles enquiries today knows which phrasings work, which cases need escalation and which commitments must never be made. A workshop with your most experienced staff provides the raw material for a system prompt that reflects actual business practice — not a generic template.

A common misconception is that the system prompt alone controls all behaviour. In fact, it's one of several interconnected layers. It sets role, tone and rules — but which expertise is available depends on data integration (RAG); which actions are technically possible depends on authorised tools; and whether output goes live depends on approval steps (human-in-the-loop). Trying to control everything through prompt text alone overloads it and makes it less secure.

The clean division of labour is this: the system prompt describes how the system should behave; technical boundaries enforce what it's actually allowed to do. An example makes the difference clear: a support agent making no refund commitments belongs in the system prompt — but having no technical access to the payment function is a hard boundary that holds even if someone tries to bypass the prompt. Only this interplay between clear instruction and technical safeguard creates a reliable system. The system prompt is the steering wheel; the guardrails are the guardrails — you need both.