System Prompt Architecture
Persona, constraints, and multi-section design
System prompts define who the model is and how it behaves across all user interactions. A well-structured system prompt has distinct sections — identity, capabilities, constraints, output format, and examples — that compose cleanly and can be versioned independently.
The system prompt is the most durable piece of prompt engineering in any application. It runs on every request, shapes every response, and is the primary lever for controlling model behaviour at scale. Yet most system prompts are written as a single unstructured paragraph. Production system prompts should be architected with the same care as application code — modular, testable, and version-controlled.
A strong system prompt has five sections. Identity defines who the model is — its role, expertise, and name. Capabilities list what the model can and cannot do, including available tools. Constraints set behavioral boundaries — tone, length limits, topics to avoid, safety rules. Output format specifies how responses should be structured — markdown, JSON, conversation style. Examples (optional) demonstrate the expected interaction pattern. Each section should be clearly delimited (markdown headers, XML tags, or numbered blocks) so the model can reference them unambiguously.
Version control matters because system prompt changes can silently break application behaviour. A small wording change can shift the model's interpretation of constraints, alter its tone, or change how it handles edge cases. The practice of treating system prompts as code — storing them in version control, reviewing changes in pull requests, testing against a regression suite of expected interactions — prevents regressions that are otherwise invisible until users report them. Never edit a production system prompt without running your eval suite.
Key Concepts
- System prompts should be modular: identity, capabilities, constraints, format, and examples
- Delimit sections with headers or XML tags so the model can reference them unambiguously
- Version-control system prompts like code — small wording changes can silently break behaviour
- Never edit a production system prompt without running a regression eval suite
- Capabilities and constraints sections prevent the model from over- or under-reaching