A model can get smarter and still make your system less reliable.
That is what weak tool contracts do.
I have seen integrations work in a demo because everything around them was forgiving. Extra fields were ignored. Aliases worked by accident. Invalid shapes slipped through — until a stricter environment exposed the gap.
There is a sharp illustration of this going around right now. A developer found that the newest Claude models — Opus 4.8 and Sonnet 5 — were worse than their older siblings at one specific edit tool: they kept inventing extra fields that did not match the schema, failing the call around 20% of the time in a real agentic session. The intent was correct. The arguments were not. Smarter model, worse tool behavior — and it only showed up in a long agentic history, not a clean one-shot prompt. Exactly the conditions production runs in.
That is the whole point. A model can understand the task and still produce malformed tool calls, because tool calling is the interface where a chat transcript becomes production automation. Tool calls mutate state, trigger workflows, touch files, move data. If the contract is loose, "usually correct" is not good enough — and a newer, more capable model does not save you.
The fix is not a better prompt. It is stricter schemas, validation, constrained calls, and runtimes that fail loudly instead of guessing.
The tool contract is part of the product's intelligence. Reliability comes from the architecture around the model, not just the model.