A year after first identifying that ambiguous requests were causing silent wrong-template matches, we had enough real production prompts to stop guessing at the shape of the problem and actually look at it. The ambiguity wasn't random. It clustered into a small number of repeatable patterns.
Missing-channel requests — "notify the customer" without saying how — accounted for the largest share. Missing-destination requests — "save the data" without saying where — were second. A smaller but consistent third pattern was multi-step requests where only the first step was specified clearly and everything after it was implied ("when someone signs up" implying, but not stating, what should then happen). Three patterns, not an unbounded space of confusion.
"Notify the customer" — without saying how.
"Save the data" — without saying where.
Only the first step of a multi-step request is stated.
Finding three dominant patterns instead of an unstructured mess of edge cases changed the shape of the fix entirely. A general-purpose "ask a clarifying question whenever unsure" rule tends toward one of two failure modes: it asks too often and exhausts the user, or it's tuned conservatively and lets real ambiguity through. Knowing the specific, recurring shapes ambiguity actually takes let the detection be targeted at those three patterns specifically, instead of a vague confidence threshold guessing at "unsure" in general.
Three patterns covering most cases is not the same as three patterns covering all cases, and the newest wave of multi-tool, multi-condition requests is already producing a fourth shape we're still characterizing rather than fixing — ambiguity in *ordering*, not just in destination or channel. This is exactly why this stays a running line of work rather than something we consider finished: the request patterns keep evolving as people get more ambitious about what they ask for.
