When a prompt misbehaves, we usually look at the instructions. A less obvious cause is vocabulary: the same concept called three different things.
Consider a prompt that says "customer" in the intro, "user" in the rules, and "account holder" in the output format. A human reader infers these are the same person. A model usually does too, but not always, and "usually" is exactly the failure rate that is expensive to debug. When behavior differs between two of those terms, you get inconsistencies that look random because the cause is in the wording, not the logic.
The same problem appears in tool definitions and schemas. A field called id in one tool, identifier in another, and ref in a third forces the model to guess whether they are interchangeable. Guessing wrong produces a valid-looking call that fetches the wrong record.
A few cheap habits help:
- Pick one term per concept and keep it everywhere. That includes the prompt, the examples, the tool names, the schema fields, and the output format.
- Define terms that carry weight. If "active" or "resolved" has a specific meaning in your product, say so in one line. Do not assume the model shares your internal definition.
- Search before you ship. A quick grep for synonyms across your prompts and schemas often turns up drift that accumulated over several edits by different people.
- Keep your code in step. If the prompt says "ticket" and the code says "issue", the next engineer will have to translate in their head, and so will the model.
This costs almost nothing and fixes a class of problems that no amount of extra instruction will. If a prompt is behaving inconsistently, read it once purely for vocabulary before you add another rule.