Use examples or a system prompt when consistency matters, such as tone, structure, expertise level, or response style. Examples show the model what good looks like, while a system prompt sets a standing instruction for the whole conversation. Both reduce rework by aligning the model’s output with the intended use case from the start.
How to use examples and system prompts together
Examples are best when you want the model to mirror a specific pattern, such as a preferred structure, level of detail, or kind of reasoning. A system prompt is better when the instruction needs to persist across turns, because it sets the standing behaviour for the conversation rather than a one-off sample.
The practical distinction is that examples demonstrate output shape, while a system prompt defines operating rules. When the output needs to stay consistent across many responses, the system prompt should carry the non-negotiables and examples should reinforce the style or format the model should imitate.
Use both when the task has a clear “this is what good looks like” standard and the cost of drift is high. That is especially useful for support bots, drafting workflows, and internal assistants where tone, completeness, and terminology need to stay aligned without re-explaining the same preferences each time.
Why examples often outperform abstract instructions
Examples reduce ambiguity because they show the model the intended target, not just the rule behind it. A short, high-quality example can outperform a long instruction block when the desired response depends on nuance, such as how formal to sound, how much to compress an answer, or how to handle edge cases.
They are also useful when the underlying instruction is easier to recognise than to define. For instance, “write like this” is often more reliable than trying to describe a style entirely in prose. The trade-off is that examples can over-constrain the model if they are too narrow or too specific to one scenario.
For that reason, examples work best when they are representative rather than exhaustive. One or two carefully chosen examples usually guide the model more effectively than a long catalogue, provided the examples reflect the actual production use case rather than a polished but unrealistic ideal.
Risk and Threat Considerations
Prompt examples and system instructions can also become a control surface for output quality and, in some environments, for safety. If they are poorly written, inconsistent, or exposed to untrusted input, the model may follow the wrong pattern, leak internal guidance, or produce outputs that are harder to review and govern.
Failure mechanism: The model over-weights a weak example, inherits a bad pattern from prior turns, or follows an instruction hierarchy that was not designed for the real workflow. In environments where prompts are assembled dynamically, poorly scoped instructions can also be overridden or confused by user-provided content.
Impact: The result is inconsistent responses, avoidable rework, and in more sensitive uses, degraded trust in the assistant’s output. Where prompts encode policy, formatting, or decision logic, defects in the prompt design can create repeatable errors at scale.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST AI RMF set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 16 — Application Software Security | Prompted AI output is software behaviour that should be constrained and reviewed. |
| Recommendation — Review prompt templates and examples as application logic before deployment. | ||
| NIST CSF 2.0 | GV.OV-01 — Outcomes are understood and monitored | System prompts and examples define expected output quality and consistency. |
| Recommendation — Define expected AI output behaviour and monitor whether it is being met. | ||
| NIST AI RMF | GOVERN — Govern AI risks and policies | System prompts are a governance mechanism for standing model behaviour. |
| Recommendation — Set policy for how prompts and examples are approved, tested, and maintained. | ||
| ISO/IEC 42001:2023 | 8.2 — AI system operation | Operational AI behaviour depends on controlled instructions and examples. |
| Recommendation — Maintain prompt and example sets as controlled operational artefacts. | ||
Practitioner Guidance
What to verify: Check whether the system prompt contains only stable rules that should apply to every turn, and keep examples tightly aligned to the intended production behaviour. If the prompt is changing frequently to handle one-off edge cases, move that logic out of the standing instruction and into the application layer.
Common mistake: Treating examples as a substitute for governance. Examples can shape behaviour, but they should not carry hidden policy, brittle exceptions, or instructions that users cannot see or audit. Keep the standing prompt simple enough that reviewers can tell what the assistant is being asked to do.
Practitioner takeaway: Use the system prompt for durable behavioural boundaries, and use examples to make the target output concrete, because the best results come from combining stable instruction with representative demonstration rather than piling on more text.
Related resources from NHI Mgmt Group
- Should organisations use security skill prompts instead of access controls for AI agents?
- What breaks when organisations deploy AI models without clear guardrails for retrieval and output use?
- When should organisations use AI to help manage NHIs?
- When should organisations treat an AI agent as a privileged system?
