Give retries a budget of their own
Bound repeated requests by attempts, elapsed time, and the remaining task allowance.
A retry can recover from a transient error. It can also repeat paid work, amplify an outage, or turn a closed-tab response into an endless loop. The same instruction to “try again” has very different consequences depending on what the remote service already did.
A retry policy should classify the failure before deciding whether another attempt is useful.
Separate rejection from uncertainty
A request rejected before execution is different from a request that timed out after the server may have accepted it. A successful response whose final bytes were lost can represent real work even though the caller did not receive the result.
Amazon's guidance on idempotent APIs describes why retries need a stable notion of the same intended operation. Apply that discipline at each layer: repeating a ledger commit is not the same as repeating an inference request, and neither proves that a tool action can be repeated safely.
Set three independent limits
An attempt limit stops a persistent failure. An elapsed-time limit prevents a task from waiting indefinitely. A spend boundary limits the amount of additional work admitted along the way. Use all three where the task needs them, and preserve the reason when one ends the retry sequence.
In an illustrative policy, a worker allows at most three attempts within one minute and only while its tab can reserve the next call. The numbers are placeholders for the workload's needs. A timeout should not automatically authorize a more expensive fallback model or a fresh set of attempts at another layer.
Back off without synchronizing the fleet
Immediate retries from many agents can arrive together and worsen the original problem. AWS's backoff guidance explains how jitter spreads retry timing. A bounded delay also gives a recovering service time to change state before the next attempt.
Follow a provider's retry instructions when present, but stop on errors that require an operator decision. A revoked key, a denied tool, or a manually closed tab is not a transient network fault. Surface that reason to the supervisor instead of converting it into silent background traffic.
Count attempts in the task review
Record the initial attempt and every retry under the same task identity, with distinct request identities where appropriate. Compare the final accepted result with the total work consumed across the attempt chain. Reporting only the last successful request makes an unreliable workflow look artificially cheap.
FlockTab can refuse new supported calls when the tab or policy does not allow them. The harness still owns its retry loop and needs to respond correctly to that refusal. Test the combination with a fake upstream that alternates failures and success before relying on it for unattended work.
Sources checked 23 September 2026. Numerical scenarios are illustrative unless explicitly identified as provider data. Vendor limits and interfaces can change; consult the linked documentation for current details.