Capability Denial with Alternative Suggestion Prompt

This prompt is for product and UX engineering teams building customer-facing AI agents that must gracefully decline unavailable features without breaking user trust. The core job is to generate a refusal instruction that clearly states a capability boundary while immediately offering one or more permitted, relevant alternatives. This is not a generic 'sorry, I can't do that' prompt. It is a structured instruction designed to be embedded into a system prompt or a tool-augmented agent's policy layer, ensuring that every denial is paired with a constructive, in-scope path forward. The ideal user is a prompt engineer or AI product developer who already has a defined permission scope and needs the model to enforce it conversationally.

Use this prompt when you have a concrete list of out-of-scope capabilities and a corresponding list of permitted alternatives that the model can actually execute. For example, if your agent cannot delete user data but can guide users to a self-service deletion page, this prompt will produce the exact refusal language and alternative suggestion logic. It is particularly valuable for regulated industries, customer support bots, and multi-agent systems where over-promising a capability creates compliance risk or user frustration. The prompt requires you to supply the denied capability, the reason for denial, and at least one actionable alternative. Without these inputs, the output will be vague and untestable.

Do not use this prompt when you need a generic safety refusal for harmful content, when the model lacks any viable alternative to suggest, or when the denial reason is too sensitive to disclose to the user. This prompt is also insufficient for dynamic permission systems where the available alternatives change mid-session based on user authentication state—in those cases, you need a tool-call-driven permission check before the refusal is generated, not a static instruction. Finally, if your denial requires legal disclaimers or regulatory wording, you must supply that exact language as a constraint; the model should not invent compliance text. After adapting this prompt, wire it into your eval harness with test cases that verify both the refusal clarity and the relevance of the suggested alternative.

This template is designed for UX-focused teams building agents that must handle capability denials without breaking user trust. The prompt instructs the model to clearly state that a requested feature is unavailable, explain the scope boundary in user-friendly terms, and proactively suggest one or more permitted alternatives that the agent can actually execute. Use this template when your agent has a well-defined permission scope and you want refusal to feel helpful rather than obstructive.

textCopy
You are an assistant with a strictly defined set of capabilities. Your permitted actions are limited to: [PERMITTED_CAPABILITIES].

When a user requests an action outside your permitted capabilities, you MUST:
1. Politely and clearly state that you cannot perform the requested action.
2. Briefly explain that this action falls outside your current scope, without revealing internal permission details.
3. Suggest [MAX_ALTERNATIVES] alternative actions from your permitted capabilities that could help the user achieve a related goal.
4. If no relevant alternative exists, state that you cannot assist with this request and suggest the user contact [ESCALATION_CHANNEL].

Tone requirements:
- Maintain a helpful and empathetic tone throughout.
- Never apologize excessively or imply the system is broken.
- Never promise future capability or speculate about feature roadmaps.

Examples of good denials:
User: "Delete all records from the database."
Assistant: "I'm not able to delete records directly, as database write operations are outside my scope. I can help you generate a report of all current records or prepare a deletion script for your review. Would either of those be useful?"

User: "Send an email to the entire customer list."
Assistant: "I can't send bulk emails, as outbound messaging is outside my current capabilities. I can help you draft the email content and segment your customer list for your marketing team to send. Would you like me to start on that?"

Now, respond to the following user request using these rules.

User request: [USER_REQUEST]

Adapt this template by replacing [PERMITTED_CAPABILITIES] with a concise, user-facing list of what your agent can actually do. Set [MAX_ALTERNATIVES] to control how many suggestions the model offers—typically 2 or 3 prevents overwhelming the user. Provide [ESCALATION_CHANNEL] as a concrete path (e.g., 'contact support@example.com' or 'reach out to your account manager'). The [USER_REQUEST] placeholder receives the actual user input at runtime. Before deploying, run this prompt through your eval suite to verify tone consistency, alternative relevance, and that the model never leaks internal permission details in its denial language.

This prompt is designed to be a pre-response guard in a tool-augmented agent or customer-facing assistant. It should be invoked immediately after the model's reasoning step identifies a user request that falls outside the declared capability scope, but before the final response is streamed to the user. The prompt acts as a formatting and tone-enforcement layer: it takes the raw denial reason and the list of permitted alternatives, and shapes them into a consistent, helpful, and on-brand refusal. Do not use this prompt as the primary mechanism for detecting out-of-scope requests—that detection should happen in your application logic or via a separate classification step. This prompt's job is to turn a known denial into a good user experience.

Integration pattern: In a typical agent loop, your tool-calling or routing layer will catch an OutOfScopeAction or PermissionDenied exception. Capture the [DENIED_CAPABILITY] (the specific thing the user asked for that isn't allowed) and the [PERMITTED_ALTERNATIVES] (a list of in-scope actions the agent can perform that are semantically related). Inject these into the prompt template along with your [BRAND_VOICE] guidelines and any [ESCALATION_PATH] instructions for cases where no alternative is acceptable. The model's output should be treated as the final user-facing text. Validate the output before sending: check that it does not re-promise the denied capability, that every suggested alternative is actually in your permitted list, and that the tone matches your brand voice spec. A simple regex or keyword check can catch accidental capability leakage.

Model choice and latency: This is a low-latency, low-reasoning task. Use a fast model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) rather than a frontier reasoning model. The prompt is structurally constrained and does not benefit from deep chain-of-thought. Retry logic: If the output fails validation (e.g., it suggests an alternative not in the permitted list, or it re-offers the denied capability), do not retry with the same prompt. Instead, append the validation error to the next attempt as [PREVIOUS_FAILURE] context, or fall back to a hardcoded denial template for that capability. Logging: Log every denial event with the denied capability, the alternatives offered, the generated response, and the validation result. This data is critical for product teams to understand where user expectations diverge from agent capabilities, and for tuning the alternative suggestion logic over time.

Human review triggers: For high-risk domains (healthcare, finance, legal), route a sample of denial responses to a human review queue, especially when the [RISK_LEVEL] is high or when the user pushes back after the first denial. The prompt includes a [REVIEW_FLAG] placeholder that can be set to true to instruct the model to append a note that a human will follow up. What to avoid: Do not use this prompt to dynamically decide whether a capability is denied—that decision must be made deterministically by your permission system. Do not allow the model to invent alternatives; always supply the [PERMITTED_ALTERNATIVES] list from your application's capability registry. Finally, never expose the raw prompt or its internal placeholders to the end user; the output of this prompt is the only surface the user should see.