Tool Priority Override
Tool priority override is an architectural pattern where a system prompt establishes a single tool as mandatory or near-mandatory for a category of queries, effectively demoting or disabling all other available tools for that category. Rather than relying on API-level tool filtering or schema restriction, the override is expressed as an instruction: “USE this tool and NOT the others.”
This is the inverse of the “all tools available” default most agent prompts assume. Instead, one tool takes precedence and others are only reachable through narrow exceptions.
How It Works
The prompt declares a tool (e.g. launch_extended_search_task) and instructs the model that it MUST be used for almost all queries, with only 1–2 explicitly enumerated exceptions (e.g., basic conversation, simple factual lookup). The rationale is typically product-design: the user intentionally enabled the premium tool, so they expect it to be used.
The override is enforced by instruction weight, not by removing other tools from the model’s available set. Other tools remain callable, but only when the prompt’s narrow exception gate is satisfied.
Example
The leaked Anthropic research-instructions prompt establishes launch_extended_search_task as the mandatory tool for all non-conversational queries, explicitly forbidding the use of web_search or any other retrieval/inference tool outside the two exceptions.
Trade-offs
| Aspect | Tool priority override |
|---|---|
| Pros | Simplifies the default path; prevents the model from “shopping” between redundant tools; aligns UX with premium-tool economics |
| Cons | Can frustrate users who want a quick answer and know the premium tool is wasteful; creates a binary gate where nuance is lost; harder to maintain as the tool set evolves |
This pattern is the opposite of [[tool-context-management]] strategies (programmatic calling, context editing), which assume all tools are live and optimize within the tool set.
Implications
Tool priority override works best when the premium tool subsumes the cheaper one’s function (research ⊇ search) and when the user’s intent is known (they opted into “advanced research” mode). It degrades user agency when the override is surprising or non-negotiable within a session.
When to Use
- When a premium/reverse-priced tool should handle the query class by default
- When a “slow path” tool offers qualitatively better output (agentic research vs. keyword search)
- When the tool surface is large and the model tends to over-rotate on cheaper alternatives
Avoid when the override would surprise users who have easy tools available and expect the model to pick the cost-appropriate one.
Relationships
- “differs from” tool-context-management — that concept optimizes within a live tool set; this pattern restricts the set itself
- “contradicts” communication-style-spectrum — override selects the workflow path before style is chosen
- “belongs-to” anthropic-research-instructions — concrete implementation of this pattern
Sources
- raw/prompts/leaked/anthropic-research-instructions.md