How to Answer
“What makes this different from ordinary API versioning is that the consumer is a language model whose prompt was tuned against the old schema. A change that is technically backward-compatible can still change behaviour, because the model reads the description as instructions.
So I sort changes into three kinds. Additive — a new optional parameter, a new response field — ship freely. Semantic — the description changed, an enum gained a value, a default moved — schema-compatible, behaviour-affecting, and it needs an eval run before it goes out. Breaking — a removal, a rename, a type change — needs a new tool name or a version in the name, with a window where both exist.
The mechanism is that each agent deployment pins the tool versions it was evaluated against. A tool-server upgrade must not silently change what a running agent does.
And none of it works without usage data. You can’t deprecate anything if you can’t see which agents called which version last week.”