Dynamic Tool Disablement Prompt Under Load

This prompt is designed for SRE teams and platform engineers operating AI systems where the available tool set can change between requests due to circuit breakers tripping, load shedding, or active incident response. The core job-to-be-done is intelligent, runtime tool routing: the model receives a dynamic list of disabled tools and must select a viable alternative without exposing internal operational state to the end user. The ideal user is an infrastructure or reliability engineer embedding this prompt into a model gateway, agent harness, or tool dispatch layer that already monitors endpoint health and can inject a [DISABLED_TOOLS] list at inference time.

Use this prompt when your system's tool availability is fluid and you need the model to reason about constraints that are not known at deploy time. This is common in multi-tenant platforms where a specific API endpoint might be rate-limited, a database replica might be lagging, or a payment service might be in a degraded state. The prompt expects a structured list of disabled tool names and, optionally, the reason for disablement and an estimated recovery time. Do not use this prompt for static tool routing where the disabled list is fixed, known at deploy time, or can be handled entirely in application code. It is also not a replacement for a proper circuit breaker or load shedder; it is the reasoning layer that sits behind those operational controls.

Before implementing, ensure your harness can provide a live, accurate [DISABLED_TOOLS] payload and that your observability stack can log both the disabled list and the model's final tool selection for later audit. Avoid using this prompt when the disabled tool list is empty or static, as the additional reasoning overhead provides no benefit. The next section provides the copy-ready prompt template you will adapt and inject into your tool-selection step.

This prompt template is designed for SRE teams and platform engineers who need to dynamically disable tools during overload conditions without exposing internal state to the end user. The template accepts a list of currently disabled tools at runtime and instructs the model to route around them, selecting the best available alternative. It also requires the model to generate a user-facing message that explains any degradation in service without revealing which specific tools are down or why.

textCopy
SYSTEM:
You are a tool-selection router operating under load-shedding conditions. Your primary directive is to select the most appropriate tool to fulfill the user's request while strictly avoiding any tool present in the disabled-tool list.

## CONSTRAINTS
- You MUST NOT select, suggest, or reference any tool listed in [DISABLED_TOOLS].
- If no enabled tool can satisfy the user's intent, you MUST select the fallback tool specified in [FALLBACK_TOOL].
- You MUST generate a user-facing message stored in the `user_message` field. This message should explain any change in capability or latency without mentioning specific disabled tools, internal load states, or the disablement list itself.
- If a fallback is used, the `user_message` must politely set expectations for reduced functionality or increased latency.

## AVAILABLE TOOLS
[TOOL_SCHEMAS]

## DISABLED TOOLS (DO NOT USE)
[DISABLED_TOOLS]

## FALLBACK TOOL
[FALLBACK_TOOL]

## OUTPUT FORMAT
Return a valid JSON object with the following schema:
{
  "tool_name": "string (the selected tool)",
  "arguments": {},
  "user_message": "string (a user-facing message explaining the action taken)",
  "is_fallback": boolean
}

USER REQUEST:
[USER_INPUT]

To adapt this template, replace the square-bracket placeholders at runtime. [TOOL_SCHEMAS] should be populated with the full JSON schema definitions of all available tools, including those that are currently disabled. [DISABLED_TOOLS] must be a JSON array of tool names that are currently off-limits. [FALLBACK_TOOL] is the name of a single, always-available tool that can provide a degraded response. Before deploying, validate that your application layer can parse the is_fallback boolean and the user_message string, and ensure that the execution harness enforces the disabled-tool list at the infrastructure level as a secondary guard. In high-risk production environments, log every instance where is_fallback is true to monitor the frequency of degraded service.

This prompt is designed to sit inside a tool dispatch layer, not as a standalone chat interaction. The application should maintain a live list of disabled tools—populated by circuit breakers, deployment rollbacks, or manual SRE toggles—and inject that list into the prompt's [DISABLED_TOOLS] placeholder at request time. The model never sees the raw infrastructure state; it only receives the sanitized list of tool names it must avoid. This separation ensures that internal degradation signals (e.g., 'payment-service-circuit-open') do not leak into user-facing responses or model reasoning.

Integration flow: 1) The application receives a user request and fetches the current disabled-tool set from a short-lived cache (TTL < 30 seconds). 2) The prompt is assembled with [DISABLED_TOOLS] as a JSON array of tool names and [AVAILABLE_TOOLS] as the full tool schema list. 3) The model returns a structured JSON object containing selected_tool, arguments, fallback_tool, and user_message. 4) A post-generation validator checks that selected_tool is not present in the disabled list—if it is, the response is rejected and a retry is triggered with an augmented error message. 5) The user_message field is rendered to the end user only after validation passes, ensuring no internal tool names or degradation details are exposed.

Retry and fallback logic: Implement a maximum of two retries. On the first retry, append a system-level instruction: 'Your previous selection [TOOL_NAME] is disabled and unavailable. Choose a different tool from the available set.' On the second failure, bypass the model entirely and route to a pre-configured static fallback (e.g., a cached response or a 'service temporarily limited' message). Log every retry with the disabled-tool list, model selection, and validator result for post-incident review. Model choice: Use a model with strong function-calling discipline (e.g., GPT-4o, Claude 3.5 Sonnet) and set temperature=0 to minimize selection variance under load. Observability: Emit structured logs containing disabled_tools_hash, selected_tool, validation_passed, retry_count, and fallback_activated so SRE dashboards can track degradation impact and model compliance in real time.