AnthropicClaude Certified Architect – Professional2026-102.2 Design system prompts, templates, and guardrails
Define useful responses at scope limits
Completed by the knowledge check
Learning objective
Write prompt-level guardrails for scope limits, refusal and escalation behavior, and missing information, and recognize their probabilistic limits
Core idea
A production assistant needs a useful next response when a request crosses its scope, asks for a prohibited outcome, requires human authority, or lacks necessary information. Prompt instructions guide those responses probabilistically; the execution layer still enforces sensitive actions. The architect’s additional job is to define the distinct behavioral outcomes rather than treating every difficult request as the same refusal.
Write each guardrail as a condition, the permitted next behavior, and a reason. Put the standing policy in system, and make any tool’s description consistent with it. Anthropic’s injection guidance recommends explicit refusal instructions and limiting the assistant’s access to sensitive data and actions. A well-worded refusal and a restricted tool surface address different failure paths.
The design succeeds when the assistant remains useful within its remit and stops at the correct boundary. Measuring only how often it completes a request rewards unauthorized behavior. Measuring only how often it declines rewards an assistant that refuses work it could safely perform.
How it works
Separate four behavioral outcomes
Start with an application-owned decision table. The rows should identify what the assistant knows and what it is allowed to do next:
| Condition | Prompt-level response | What the response must preserve |
|---|---|---|
| Request outside the product’s scope | Explain the limit and offer an appropriate route | No claim to provide the excluded service |
| Request conflicts with an explicit rule | Decline that requested behavior and offer a permitted alternative | No prohibited details or promise of an exception |
| Decision requires another person’s authority | Request the defined handoff operation | No claim that the decision has already been approved |
| Necessary information is absent | Ask a targeted question or state the limitation | No invented fact used to complete the answer |
These are proposed application behaviors, not built-in Anthropic routing categories. A missing document might justify a question; a missing authority might justify handoff. Using one generic “cannot help” sentence for both prevents the user from supplying the information that would resolve the first case.
Scope rules should say what remains possible. An education assistant can explain an institution’s published enrollment procedure while declining to decide an admission appeal. The reason is the assistant’s delegated role. It need not classify the entire topic of admissions as prohibited to respect that limit.
Make a refusal precise and bounded
Specify what the assistant declines and what it can offer instead. Refusing a request to fabricate an attendance record should not also forbid explaining how to request a legitimate correction. Keep the refusal brief enough that the alternative remains clear. Avoid rules that require a long argument with the user about why the policy exists.
Do not confuse the application’s policy refusal with a model safety-classifier refusal. For Claude Opus 5.5 on the Claude API, for example, a classifier decline is a normal HTTP 200 response with stop_reason: "refusal"; stop_details.category identifies the policy area when available. A business-scope decline that Claude writes because your prompt told it to is ordinary response text, not that API outcome. Measure the application’s decision and the API’s terminal state separately.
If a classifier refusal occurs after partial streaming output, Anthropic says to discard that partial output as incomplete. An application should not present a fragment as the completed permitted alternative. This is a transport-consumption consequence of the documented refusal behavior, rather than an instruction that more forceful prompt wording can repair.
Specify the missing-information path
Anthropic recommends explicitly allowing “I don’t know” and restricting answers to supplied information to reduce unsupported claims. Translate that into a useful policy for the workflow. Name which absent input can be requested, which answer must remain unknown, and which unavailable decision needs a person.
For example, an assistant can request the course identifier when it is missing. It cannot replace an unstated appeal decision with an estimate based on similar cases. If the user cannot provide the missing identifier, the prompt should allow a limited explanation of the general procedure without pretending to have looked up the specific case.
Do not make abstention incompatible with another instruction such as “always provide a definitive answer.” That conflict pushes the assistant toward filling the gap. Source-backed answers and how to measure unnecessary abstention are covered in 2.2.4.
Keep guardrails proportional to consequences
Guardrails shape language and planning; they do not make forbidden tool execution impossible. Keep the prompt’s scope aligned with the actual operations exposed to the assistant. Anthropic recommends least privilege so that a successful injection has limited consequences; input and output screening are covered in 5.1.1. Giving a read-only advising assistant an enrollment-change operation creates a larger failure surface than its job needs.
Where a workflow needs a handoff, reference the actual application tool in the prompt rather than instructing the assistant only to announce a transfer. The general handoff mechanism is assumed here; this lesson’s decision is when the response should clarify, decline, or request that handoff. Ensure the user-facing message reflects the operation’s result rather than promising an outcome the assistant cannot confirm.
A prompt change is appropriate when the desired behavior was unspecified or contradictory. If the forbidden outcome remains possible even when the rule is explicit, revise the execution path as well. Track both the missed boundary and the over-restrictive response: a repair that declines every case can hide the original error without restoring the service.
Key distinctions and trade-offs
Scope limit versus harmful request: A benign request can fall outside a product’s role. A scope explanation should not accuse the user of unsafe behavior.
Clarification versus escalation: A question seeks information needed for permitted work. Handoff seeks authority or capability the assistant lacks. Asking more questions cannot create that authority.
Prompt behavior versus deterministic prevention: More precise instructions reduce ambiguity. Limiting available actions and enforcing business checks restrict consequences when instructions fail. Neither should be reported as accomplishing the other’s job.
Architecture / decision scenario
A university deploys an enrollment assistant for 12,000 students. Four advisers can handle at most 80 escalations a day during registration. The assistant may explain published procedures but cannot decide appeals or alter attendance records.
The tempting proposal is to escalate every missing field and out-of-scope request to avoid mistakes. A labeled trial shows that this creates 140 transfers a day. The architect and registrar instead define the four outcomes: ask for a missing course identifier; explain the scope limit on unrelated tutoring; decline attendance fabrication while offering the legitimate correction process; request the custom request_appeal_review tool when a decision needs an adviser. This illustrative application tool submits the case to the university’s adviser queue.
The registrar owns those boundaries, and the engineering owner removes record-writing operations from this assistant. In a second trial, transfers fall to 65 daily, but that figure is acceptable only if missed appeal handoffs and fabricated records also meet their separate acceptance criteria. The lower queue load alone cannot justify granting appeal authority. The release review inspects both user-facing responses and requested operations, including attempts to override the rules through supplied notes.
Common exam traps
- Escalating every absent field instead of asking a useful question.
- Treating an ordinary scope refusal as
stop_reason: "refusal". - Providing prohibited details before adding a refusal sentence.
- Requiring definitive answers while also forbidding unsupported claims.
- Declaring a prompt rule sufficient for an irreversible operation.
What to remember
Define scope, refusal, handoff, and missing-information behavior separately. State the condition and useful next action in system, align tool descriptions with the policy, and measure over-restriction as well as missed boundaries. Prompt guardrails guide behavior; restricted capabilities limit the consequences of failures.
Knowledge check
A student asks a university enrollment assistant, “Can I still drop my course?” without saying which course. Drop deadlines differ by course, and the assistant can explain a course’s deadline once it has the course identifier. What should the prompt direct the assistant to do?
A support assistant runs on Opus 5.5 through the Claude API. Its system prompt tells it to decline questions about competitors’ products and offer the product catalog instead. The team measures how often this rule fires by counting responses with stop_reason: "refusal", and the count stays near zero although transcripts show many such declines. What explains the gap?
stop_details.category without a stop reasonfallbacks is enabled"refusal" marks classifier declinesstop_reason: "refusal" is the API’s terminal state for a safety-classifier decline, returned as a normal HTTP 200 with stop_details.category when available. Measure the application’s decision from the response content and the API outcome separately.An advising assistant’s system prompt says clearly that it must never change a student’s enrollment. In testing it still occasionally calls update_enrollment, a tool it was given for an administrative workflow it does not serve. What should the architect change?
descriptionupdate_enrollment from the assistant’s available toolsA benefits assistant’s prompt says “Answer only from the supplied plan documents” and “Always give the employee a definitive answer.” Audits find confident coverage answers about procedures the documents never mention. Which revision addresses the cause?
References
- Anthropic, Mitigate jailbreaks and prompt injections
- Anthropic, Reduce hallucinations
- Anthropic, Handle refusals and fall back to another model