Out-of-Band Package Management

Operating-system repositories are built for stability: packages are reviewed, bundled and released at intervals. Agent tooling currently evolves in days, sometimes hours. Sourcing both through the same channel gets you either outdated tools or an unstable system. Separation resolves the conflict: the system stays conservative while the toolchain is managed independently and versioned per project. In practice that means one file in the project recording authoritatively which versions apply, plus a command that materialises them. This is more than convenience — it is the precondition for agent runs behaving identically across machines and execution environments. The flip side is a wider supply chain: every tool obtained this way bypasses distribution review. Provenance, signatures and a deliberate update cadence therefore belong to the concept, not to the optional extras.

For teams this is the unspectacular part of agent adoption that decides reproducibility. Without pinned tool versions, error reports from agent runs are barely usable, because nobody can say which version produced them.

A project pins runtime, formatter and agent CLI versions in one file. Developer machines, execution nodes and CI materialise exactly those versions. One agent tool is deliberately bumped twice a week; the operating system stays on the distribution's stable release.

Per-language version managers have existed since the 2010s. Cross-cutting tool managers consolidated that role from the late 2010s. With command-line agents emerging in 2025/2026, update frequency became the decisive argument: tools changing daily do not fit release cycles measured in weeks.