Hive, not swarm: control, flow and collapse in human-directed coding-agent teams

Multi-agent coding systems are often called swarms. I argue that the arrangement that delivers accountable software is structurally different, and I call it a hive. In a swarm, agents choose their own work from local cues, coordinate through a shared medium, and the result emerges from their interactions. In a hive, every agent holds an assignment, writes only inside an owned lane, reads lateral messages as data rather than commands, and one human holds acceptance and stopping authority. Drawing on swarm intelligence, social-insect biology, supervisory control and manufacturing control, I define the two structures on four axes: who selects work, what lateral signals mean, who may write shared state, and how work ends. Central direction is feasible only while an informed supervisor and a system-wide channel exist. I then examine a dated operational record from my own AIEN agent hive between 13 and 28 October 2026, in which the hive repeatedly degraded into swarm-like behavior. Seven mechanisms recur: overlapping authority, coupling through shared derived state, tool drift, channel fragmentation, supervisor saturation or loss, exclusive-resource breaches and unreconciled duplicate work. The selected incident records repeatedly describe deliberate interventions: stop the affected work, one owner per resource, re-issued lanes and a reconciled ledger. Whether that full sequence is necessary is a prospective hypothesis, not a finding. A constrained concurrency model shows how review capacity bounds useful concurrency. The record is retrospective, self-reported and uncontrolled. It supports a mechanism taxonomy and preregisterable hypotheses, including a fault-injection design, not causal claims.