AnthropicClaude Certified Architect – Professional2026-102.2 Design system prompts, templates, and guardrails
Separate standing policy from request content
Completed by the knowledge check
Learning objective
Structure system prompts with role, task context, rules, output format, and examples, separate from per-request content
Core idea
For a production architect, prompt structure determines which decisions are shared across requests and which facts belong to one case. Give the assistant a stable operating brief, then deliver the individual question and its supporting content separately. This makes a policy change reviewable without making every customer record part of the policy.
The Messages API exposes a top-level system parameter for context and instructions. Use it for the standing role, task context, rules, output format, and selected examples. Keep the live request in messages, with role: "user" and its content. A role description focuses behavior and tone; it does not grant business authority or prove expertise. Stable system content also supports prompt-caching cost decisions; see 2.5.
The architectural choice is the smallest coherent brief that explains the job and its constraints. A list of prohibitions without purpose leaves interpretation unresolved. A detailed persona without rules leaves operational authority unresolved. A single string mixing both with live records makes it harder to inspect either.
How it works
Give each section a distinct job
Anthropic recommends clear instructions, the motivation behind them, descriptive XML tags, and relevant, diverse examples. Use those techniques to separate five responsibilities:
| Section | Decision it should settle | Failure when omitted |
|---|---|---|
| Role | Whose work the assistant supports and its tone | General assistance drifts beyond the intended job |
| Task context | What the workflow is trying to accomplish | Locally helpful answers miss the business purpose |
| Rules | Permitted behavior and priorities | The assistant improvises authority or exceptions |
| Output format | What the consumer can display or process | A useful answer arrives in an unusable presentation |
| Examples | How representative cases satisfy the rules | Ambiguous wording produces inconsistent interpretations |
The section names are your prompt convention, rather than reserved API fields. Tags such as <role>, <rules>, and <examples> organize the text inside system. Their value comes from the separation and explicit meaning, not a special parser that enforces business rules.
Task context should explain the stable purpose. For a claims-document assistant, it might say that reviewers need a summary of supplied documents before making their own decision. An individual claim number, uploaded letter, or requested comparison belongs to the request. Keeping those facts out of the operating brief reduces the chance that one case becomes an apparent general rule.
For document-rich request inputs of 20k+ tokens, Anthropic recommends placing longform data near the top, before the query, instructions, and examples, with the query at the end. This orders the request content rather than moving standing policy out of system; third-party material still follows the delivery path in 2.2.2.
Explain rules and their alternatives
Write a rule with its reason and the allowed next action. “Do not decide eligibility” leaves a user without a path. “Summarize supplied eligibility criteria; reviewers make eligibility decisions, so refer requests for a decision to the review team” defines both the boundary and useful work within it. These are illustrative application rules, not Anthropic product policies.
Resolve conflicts explicitly. If brevity is preferred but a source discrepancy must be disclosed, say that disclosure takes priority. Otherwise “be concise” and “include every discrepancy” compete without a deciding rule. Do the same for examples: a demonstration of an unsupported conclusion contradicts a rule requiring supplied support, even if its writing style is ideal.
Keep secrets and credentials outside the prompt. Anthropic’s injection guidance recommends limiting access to sensitive data and actions. A sentence saying not to reveal a secret still exposes that secret to the component you are trying to constrain. Prompt scope and tool permissions should support the same restricted job.
Specify format without confusing it with enforcement
For a human-facing summary, describe sections, tone, and how to present an unknown. If software requires a constrained JSON response, evaluate output_config.format rather than assuming “return valid JSON” enforces a schema. This Bite owns the prompt’s expression of the format; source-backed answers and the incompatibility between native citations and that parameter are covered in 2.2.4.
Examples should demonstrate the same format and priorities as the written instructions. Anthropic recommends three to five relevant, diverse examples and organizes them with <examples> containing <example> elements. That recommendation is a starting point, not a requirement to add five demonstrations to every prompt. Technique selection belongs to 2.3; here the examples earn their place by resolving a specific interpretation.
Do not place the live customer’s request inside the example section. The model should be able to distinguish a demonstration from the task it must answer. Parameterized request construction is covered in 2.2.2, and changes to the shared brief require the regression process in 2.2.5.
Key distinctions and trade-offs
Role versus authority: A role establishes the perspective and style. Explicit rules establish the application’s intended authority; execution controls enforce sensitive actions.
Standing context versus live facts: The system brief explains the recurring workflow. Request content supplies the particular case. Repeatedly needed data is not automatically a standing instruction.
Clarity versus length: Additional examples can settle an ambiguity, but contradictory or irrelevant material adds interpretation work. Prefer a short explanation of the deciding rule over multiple emphatic restatements.
Architecture / decision scenario
A financial-services team prepares summaries for eight human claims reviewers. Their service target is a two-minute review preparation, and the assistant must never represent a summary as an approval. The pilot builds one user-message string containing a persona, the claim file, and the instruction “always reach a conclusion.”
One proposal is to add a longer expert persona to that string. The architect instead separates the stable brief into system: reviewer-support role, preparation context, prohibition on deciding claims, a required summary format, and examples showing both supported findings and unresolved information. The case question remains in the user message; third-party documents follow the handling in 2.2.2.
In an illustrative trial of 50 claims, the persona-string prompt presents nine unresolved claims as approvals, compared with one for the separated brief; preparation times are 1 minute 40 seconds and 1 minute 55 seconds respectively. Both meet the two-minute target, but the separated brief reduces the approval error rate from 18% to 2%; neither yet meets the team’s zero-observed-approval acceptance rule.
The review lead owns the authority wording and examples; the integration engineer owns where the fields enter the API request. This costs review time whenever the shared brief changes, but prevents a local case edit from silently changing the assistant’s job. A candidate prompt fails acceptance if it meets the two-minute target by turning an unresolved claim into an approval. Faster presentation cannot compensate for a different decision authority.
Common exam traps
- Treating an expert persona as permission to make a business decision.
- Mixing live case records into the section that defines standing rules.
- Adding examples that contradict the rule they are meant to clarify.
- Assuming XML section names enforce policy or validate output.
- Repairing missing priorities by repeating instructions more forcefully.
What to remember
Use system for a coherent operating brief and messages for the particular request. Separate role, purpose, rules, output expectations, and demonstrations. Explain priorities and alternatives so a reader can defend what the assistant is meant to do before measuring whether it does it.
Knowledge check
An internal HR-policy assistant on the Messages API sends one user message holding the assistant’s role, its answering rules, the output format, three worked examples, and the employee’s question. Policy reviewers want to change the rules without touching any employee’s request. How should the request be structured?
system , with the question after the examples<rules>system ; the question in messagessystem ; the rules, format, examples and question in messagessystem parameter carries the standing brief — role, context, rules, format and selected examples — while the live request travels in messages as a user turn. That separation makes a policy change reviewable on its own and keeps one case from looking like a general rule. XML tags organize text but do not separate standing policy from live facts, and splitting the rules away from the role leaves the brief in two places.A summary assistant’s system prompt contains both “Keep summaries under 120 words” and “List every discrepancy between the supplied documents.” On files with many discrepancies, outputs alternate between cutting the list short and running over the limit. Which revision addresses the cause?
system into each user messageA lending assistant’s system prompt opens with “You are a senior credit officer with 20 years of experience.” Reviewers find that it sometimes tells applicants their loan is approved, a decision only the credit committee makes. Which prompt change addresses the problem?
On the Claude API, a billing service parses the assistant’s reply into a fixed JSON schema, and the response uses no citations. The prompt already says “Return valid JSON matching this schema,” yet about one reply in a thousand breaks the parser. The service needs schema conformance enforced, not merely made more likely. What should the architect evaluate?
output_config.format<format> XML sectionoutput_config.format constrain the response itself. Tags, repetition and examples all make conformance more likely while leaving it probabilistic.References
- Anthropic, Prompting best practices
- Anthropic, Mitigate jailbreaks and prompt injections
- Anthropic, Structured outputs
- Anthropic, Prompt caching