What You Need to Know
A system prompt holds what applies to every request: role, audience, standing policy and output contract (the format that the output must follow). The system prompt is a contract: a fixed statement of what applies to every request. It is not a greeting. User turns contain the data of each request. A template is a prompt with named variable slots. A guardrail limits what the model receives or returns.
This lesson uses one made-up example throughout: a large law firm whose online assistant answers clients from its published fee list. Its standing rules are in the system prompt. Each client's question is a user turn.
The System Prompt as an Architectural Contract
Policy in the system prompt has stable authority: the model treats it as policy, not one more conversational message. Anthropic says a role in the system prompt focuses Claude's behaviour and tone. Prompt caching (objective 2.5) can reuse a stable system-level prefix (the opening part of the prompt). Policy restated differently in every user turn varies by developer. It behaves less consistently and costs full input price on each request.
Anthropic's context engineering guidance adds an altitude rule, which is about the level of detail in a system prompt. Effective system prompts are between two failure modes: hardcoded brittle logic and vague high-level guidance. They are "specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics".
Explicit Instructions and the Escape Hatch
Claude follows clear, direct, specific instructions literally, and follows vague ones with confident but inconsistent output. Anthropic's golden rule: if a colleague with minimal context would be confused by the prompt, Claude will be too. State precisely:
- the role
- the audience
- the rules
- what to do when rules conflict
- the output format
A prompt that gives the motivation ("this will be read aloud by a text-to-speech engine, so never use ellipses") helps the model generalise correctly. For the law firm, such a rule is "clients plan their budgets from these fees, so never estimate a fee that is not in the list".
An escape hatch defines what Claude does when it cannot do a task honestly. For example, return null when the document lacks the field. Answer "I don't have enough information" when the sources do not cover the question. Without an escape hatch, the output contract (the format the output must follow) forces the model to invent an answer. For an unlisted service, the assistant returns the not-enough-information answer.
Anthropic's guidance on hallucination (a confident answer that the model invented) says that permission to admit uncertainty "can drastically reduce false information". The guidance pairs this permission with grounding:
- extract word-for-word quotes before analysing long documents
- cite sources for claims
- restrict answers to the provided context
Precise instructions, not a bigger model, fix confident but inconsistent output.
Templates as Engineering Artefacts
Named slots make a template testable and versionable. You can diff it, code-review it, evaluate it before you deploy it and revert it when it regresses. Give each content type (instructions, context, examples, per-request input) its own consistently named XML tag. Anthropic documents XML tags as the way to help Claude parse complex prompts unambiguously, especially where instructions mix with variable and untrusted input. The fee list and each client's question get separate tags.
One reviewed template is better than ten hand-made copies that diverge. Prompts in production are managed like code: version-controlled, owned and covered by evals (Domain 4 configures them).
Guardrails in Layers
The prompt is one layer of defence, never the whole defence:
- Instruction-level: scope ("answer only from the provided policy text"), refusal rules, tone constraints, and the escape hatch.
- Input-side: validate and sanitise input before it reaches the model. Screen the input for size, format and sensitive data. Delimit untrusted content (retrieved documents, user uploads) inside tags, so that it arrives as data, not as instructions. Content that arrives as instructions can act as instructions. That attack is prompt injection: text inside the content that the model follows as instructions. Domain 2's part of prompt-injection defence is treating that content as untrusted by default. Defence in depth (several independent layers of protection) belongs to Domain 5.
- Output-side: parse and validate the model's output against the schema and business rules before anything downstream consumes it. Model output is untrusted input to the next system. At the law firm, the output-side guardrail checks quoted fees against the fee list.
Give every refusal a fallback. A guardrail that blocks with no fallback (no human-review queue, no structured error that the caller can handle) converts a safety control into an outage. The law firm sends blocked questions to staff.
Instructions Cannot Guarantee Behaviour
Instructions influence behaviour probabilistically. Only programmatic validation can guarantee behaviour.
In the exam
The Professional exam tests deliberate contract design. It also tests whether you know that instructions alone are never the whole defence. When a question describes a system-prompt-only defence and asks what is missing, the answer is code-level validation around the model, not more emphatic instructions.
Exam Traps
Restating standing policy (differently) in each request's user turn instead of the system prompt
Buried policy loses stable authority, drifts per developer, and destroys the cacheable prefix. The same rules then cost full input price on every request while behaving less consistently.
Responding to an invented-fact incident with a larger model or a lower temperature
Hallucination under a vague contract is a prompt design failure. The fix is scope restriction plus an escape hatch: answer only from provided text, with explicit permission to admit uncertainty. A larger model obeys the same vague contract more fluently.
Relying on system prompt instructions as the sole guardrail around a sensitive workflow
Instructions cannot guarantee behaviour. Programmatic input and output validation wrapped around the model (parsing, schema checks, business rules) is what is missing, applied before any later step uses the answer.
Keeping every schema field mandatory and adding a bold 'never invent' rule
A bold rule cannot help: when the source lacks the field, the model must either break the schema or invent the value. An explicit null path plus permission to say the information is missing removes the incentive to hallucinate.
Practice Scenario
A financial-services chatbot must answer strictly from an internal policy library. Its launch system prompt reads: 'You are a helpful assistant. Answer questions about company policy.' In week one it answers a question about a competitor's products, invents a policy clause, and returns inconsistently formatted answers. Which single redesign most reduces the invented-clause risk?
Build Exercise
Redesign a One-Paragraph Prompt into a Layered Contract
What you'll learn
- How to write an explicit role, scope, and rule-conflict contract
- How to design an output contract with a genuine escape hatch
- How to structure a template with XML tags separating static and per-request content
- How to place input-side and output-side guardrails around the model
- How to pair every refusal rule with a fallback route
- Take a real assistant with a minimal system prompt and rewrite it: explicit role, audience, scope limits, and rule-conflict behaviour
Why: Vague prompts produce confident but inconsistent output. The rewrite is where the contract becomes specific enough to guide behaviour.
You should see: A system prompt where every sentence either sets scope, sets policy, or sets format — nothing decorative.
- Define the output contract: format, schema, length, and the escape hatch for unanswerable input, with the null path stated in full
Why: An output contract without an escape hatch forces invention. The null path is the anti-hallucination control.
You should see: A schema plus one explicit rule for what the model returns when the source does not contain the answer.
- Restructure the template with XML tags separating instructions, policy content, examples, and per-request input; mark which sections are static and which vary
Why: Tags make the prompt parseable and the static/dynamic split is what makes the prefix cacheable later.
You should see: A template with four or five named tag sections and a static/dynamic annotation on each.
- Add the input-side layer: what is validated or sanitised before the model, and how untrusted content is delimited
Why: Content that arrives as instructions can act as instructions. Delimiting untrusted input as data is the Domain 2 share of injection defence.
You should see: A short list of pre-model checks plus the tag that wraps retrieved or user-supplied content.
- Add the output-side layer: the parser and business-rule checks that run before any later step uses the answer, and the fallback route when validation fails
Why: Model output is untrusted input to the next system, and a refusal path that leaves the user with no next step is an outage.
You should see: A validation list plus one named fallback per failure mode: retry, human review, or structured error.
Sources
- Prompting best practices — Anthropic
- Reduce hallucinations — Anthropic
- Mitigate jailbreaks and prompt injections — Anthropic
- Prompt engineering overview — Anthropic
- Effective context engineering for AI agents — Anthropic
- Claude Certified Architect Professional Exam Guide (v1.0) — Domain 2 — Anthropic