0
Disambiguate overlapping tools so an agent picks the right one consistently
⁂auto-checked, 4 days oldAauraNovice
The prompt
I have multiple tools that overlap in what they can technically accomplish: overlapping_tools_list. The agent keeps picking the wrong one for a given situation. Help me write disambiguation guidance:
1. For each pair of overlapping tools, state the precise deciding factor (not 'use judgment') that determines which one is correct for a given request: data freshness needs, cost difference, side effects vs read-only, granularity of result.
2. Give a decision table or flowchart in text form the agent can apply mechanically: given attributes of the incoming request, which tool to pick.
3. Identify requests that are genuinely ambiguous even with the deciding factors (both tools would serve about equally well) and state what the agent should do then: pick the cheaper/faster one by default, or ask, your call given the stakes described.
4. Give 3 example requests, one for each tool and one genuinely ambiguous one, with the correct tool choice and one-sentence justification for each.
Tools and what they do: overlapping_tools_list
Observed mis-selections: observed_mistakes
Where it has been run
| Model | Version | People | Broke | Auto | Last |
|---|---|---|---|---|---|
| Claude | Haiku 4.5 | 0 | 0 | 1/1 | 4 days ago |
Example output
Tools: `get_cached_price(product_id)` (fast, up to 15 min stale) vs `get_live_price(product_id)` (slower, hits the pricing API directly, real-time).
Deciding factor: does the request involve an action with financial commitment (checkout, quote a customer a binding price)? If yes, always use `get_live_price`, staleness risk is unacceptable there. If the request is informational only (display price on a browsing page, answer 'roughly how much is X'), use `get_cached_price`, the 15-minute staleness is immaterial and it's meaningfully cheaper/faster.
Genuinely ambiguous case: a customer asks 'is this still around $50?' during a support chat, not a transaction. Default to `get_cached_price` here since no commitment is being made and speed matters more in a live chat; only escalate to `get_live_price` if the customer explicitly says they're about to buy.
Examples: 'What's the price shown on the product page' -> cached (informational, high volume, staleness fine). 'Confirm the exact price before I charge this customer's card' -> live (financial commitment, staleness unacceptable). 'Is the price still roughly $50' in casual chat -> ambiguous, default to cached per the rule above.
0 comments
Sign in to comment or report what this prompt did for you.
Sign inNo comments yet. Run the prompt and report what you got.