System Prompt Design
System prompt design establishes persistent instructions for an assistant's role, behavior and interaction with tools. It defines how the model should approach a task and handle uncertainty or conflicting input, while recognizing that application permissions and critical checks must be enforced outside natural-language instructions.
What it is
A system prompt occupies an instruction position defined by the selected model interface. It can specify the assistant's purpose, tone, output conventions and rules for using evidence. Unlike a user's individual request, it is intended to remain stable across many interactions. Some APIs distinguish system and developer messages or use different instruction hierarchies, so the application must use the provider's actual contract. Source documents and tool results should be presented as data with clear boundaries; embedding everything in one undifferentiated message makes authority and task context harder to interpret.
What the work involves
The designer writes a concise behavior contract with explicit priorities and realistic exceptions. Tool descriptions explain when an operation is appropriate and what information it needs. Tests cover ordinary requests, insufficient evidence, contradictory instructions and attempts to treat retrieved text as authority. The prompt is versioned with the model and tool schema. An effective review asks whether each instruction changes a measurable behavior and whether a deterministic rule would be better enforced by code, access control or output validation.
Illustrative example
A technical support assistant is instructed to distinguish verified product documentation from suggested troubleshooting steps. It must state when a procedure is unsupported and escalate requests that require a privileged account change. A retrieved forum post telling the assistant to ignore those rules is handled as source content. The application additionally blocks privileged tools for ordinary users. The system prompt helps shape the explanation, while the server decides which actions are actually available to the current account.
Limits and common mistakes
A system prompt is not a security boundary or a complete specification of model behavior. Long lists of prohibitions can conflict, and models may fail to follow even clear instructions in difficult contexts. Vendor instruction hierarchies differ and can evolve. Quality checks need adversarial and ambiguous inputs as well as friendly examples, and high-consequence actions need application controls that remain effective when the model interprets an instruction incorrectly.
Prerequisites
System prompts are the highest-level prompt engineering artifact — you need to understand prompting before you can design contracts
Related skills
- → is part of: AI Agent Design
- → is part of: Prompt Engineering
Sources and further reading
- Effective context engineering for AI agents
Discusses clear system instructions, suitable specificity and separation of context components.
- OpenAI Model Spec
Documents an example instruction hierarchy and treatment of differing instruction authority.
Last updated: 2026-10-10