Did you know that a single failed AI-agent request can create dozens of extra calls when each service retries independently? Retries are useful for temporary network problems, but unbounded retries can overload a struggling provider, exhaust a learner’s time budget or repeat an external action that may already have succeeded. A retry budget defines which operation may be retried, how many attempts are allowed and how much time remains before the user task must stop or seek a safer alternative.
The practical method is to classify failure evidence, preserve one logical operation identity, respect HTTP Retry-After where applicable, use bounded exponential backoff with jitter, propagate a parent-task deadline to child calls, and check completed side effects before any retry. This guide uses a fictional 120-task reliability ledger and a second school-publication exercise to show what the numbers mean. These are original invented teaching examples, not observed eduKate API traffic or proof of existing artificial superintelligence.
Continue through How Super Intelligence Works. Agent Circuit Breakers examines protecting dependencies during outages, while Database Connection Pools examines shared resource capacity. This chapter addresses the retry decision itself: which failure is eligible, what the server asked the client to do, and whether another attempt can still fit within the user’s original task.
Choose a practical reading route
- Receiving HTTP 429? Start with Retry-After and failure classification.
- Building a resilient agent? Study backoff, jitter, shared attempt budgets and parent deadlines.
- Learning Mathematics? Recalculate the 120-task ledger and 3 × 3 × 3 retry example.
- Safeguarding external writes? Read idempotency, cancellation and result reconciliation.
Contents
- 1. Retries are a limited resource, not a reflex
- 2. HTTP 429 says slow down, not become more aggressive
- 3. Retry-After has two documented formats
- 4. Backoff reduces correlated retry pressure
- 5. Jitter spreads clients across time
- 6. Set a real parent-task deadline
- 7. Attempt budgets prevent hidden nested amplification
- 8. The AWS standard-mode quota is a concrete example
- 9. Idempotency comes before retrying external effects
- 10. Retrying denial can undermine user authority
- 11. Handle 503 and temporary outages with bounded recovery
- 12. Retry-After must not override task cancellation
- 13. An original 120-task retry-budget laboratory
- 14. An explicit attempt-count example
- 15. Changed-context forty-task school-publisher case
- 16. Repair a retry storm without weakening safety
- 17. A useful retry runbook for education systems
- Frequently asked questions
- Primary technical sources
- Connected specialist guides
1. Retries are a limited resource, not a reflex
A remote call can fail because of a transient network loss, an overloaded service, an invalid request or missing permission. Repeating it can be helpful in the first case and harmful in the others. The request’s status code, provider-specific error and actual target state should inform a retry decision. The language model’s desire to finish should never substitute for that evidence.
An AWS Builders Library discussion describes retries as useful but potentially selfish because they ask an already strained service to do more work. Without bounded policies, many clients retrying together can amplify a minor outage. An agent with several tool layers makes the problem worse when each nested service retries silently in addition to the parent controller’s attempts.
Define a retry budget for the user’s logical operation. It can include a maximum total attempt count, allowed additional network cost, total waiting time and a hard completion deadline. Some tasks may be allowed one harmless read retry; an uncertain external send may require reconciliation instead of any immediate repeat. One universal retry configuration rarely fits both cases.
Track the original task and operation identity across attempts. Three HTTP requests for one intended document update are not three user tasks. A model-generated new ID on each attempt may prevent the provider from recognizing a duplicate effect. A stable ledger makes retry decisions inspectable and permits honest reports when the budget is exhausted.
Return to contents or continue to HTTP 429 says slow down, not become more aggressive.
2. HTTP 429 says slow down, not become more aggressive
RFC 6585 defines status 429 Too Many Requests for rate limiting. It notes that the response may carry a Retry-After header, and leaves open whether the server counts requests per user, resource, application or another unit. A client should treat the provider’s actual rule as part of the service contract instead of assuming all 429 responses indicate a universal ban for the whole organisation.
MDN’s reference for 429 explains that Retry-After can communicate how long to wait. A retry-aware agent should not immediately submit the same request repeatedly just because it regards the user’s school question as important. More traffic can deepen the overload that caused the limit in the first place.
A client can also receive other conditions such as 400 Bad Request, 401 Unauthorized or 403 Forbidden. These often require corrected inputs or legitimate credentials rather than identical repetition. Provider semantics still matter; a service may define special transient conditions. Separate unsupported requests, authorization denials and genuine throttling rather than handle every non-200 response as retryable.
Do not ask the model to select a broader account or bypass a rate limit by rotating through unauthorized credentials. That is not reliability engineering. A legitimate response may be to queue work under its appropriate owner, preserve partial safe results or tell the user the external provider is temporarily unavailable.
Return to contents or continue to Retry-After has two documented formats.
3. Retry-After has two documented formats
RFC 9110 defines Retry-After as either an HTTP-date or a nonnegative number of delay seconds. A client must parse the actual supplied value according to the specification. For example, Retry-After: 120 requests a wait of two minutes; a valid HTTP date needs conversion relative to current time and clock state.
The header can appear with a 503 Service Unavailable response and with certain redirects as well as in rate-limiting situations. The application should not assume the header always means the same business condition. A redirect carrying a requested delay still needs its destination validated under the application’s source and network policy.
Consider a fictional API call at 10:00 with Retry-After: 90. A retry no earlier than 10:01:30 is indicated under the simple local-clock example, assuming no other policy is stricter. If the user’s full task deadline is 10:01, waiting until 10:01:30 would not fit. A responsible controller should stop or defer instead of pretending the deadline disappears.
Clock skew and invalid header values require safe handling. The client can use a trusted clock and bounded policy to interpret a dated response, while rejecting malformed values or applying documented fallbacks. A model’s natural-language guess about a timestamp is not an acceptable timer implementation for consequential work.
Return to contents or continue to Backoff reduces correlated retry pressure.
4. Backoff reduces correlated retry pressure
Exponential backoff increases the interval between retry attempts. A common illustrative sequence is one second, two seconds, four seconds and eight seconds, capped according to the provider and task policy. The objective is to reduce repeated pressure on a dependency that may need time to recover rather than generate a synchronized storm of immediate calls.
Google Cloud’s retry guidance describes truncated exponential backoff with jitter and an explicit deadline. AWS SDK standard mode similarly uses bounded retry budgets and jitter under provider-specific rules. An application should generally use a supported client retry mechanism instead of accidentally stacking several independent retry loops around it.
Backoff is not permission to retry every request. A write whose outcome is uncertain needs an idempotency or reconciliation mechanism first. A user may also cancel the task while the worker waits. When the next scheduled attempt arrives, check that current authorization and task need remain valid.
Measure the actual waiting and network attempts. A service might spend a minute waiting between retries only to discover that the user’s request was already completed by the first attempt. A stable operation ID and target-state readback can avoid further work and reduce both duplicate effects and user delay.
Return to contents or continue to Jitter spreads clients across time.
5. Jitter spreads clients across time
Suppose one hundred clients fail at the same moment and each retries exactly two seconds later. They can create another synchronized spike at the same overloaded service. Jitter varies the interval within a defined range, distributing attempts instead of concentrating them into identical moments. AWS and Google Cloud recommend this technique for appropriate retryable conditions.
The distribution should follow the chosen algorithm and service contract rather than an arbitrary model-generated random delay. Full jitter, equal jitter and other variants have different performance patterns. A production implementation needs deterministic configuration, bounded values and a testable maximum, even if individual delays are randomized.
An illustrative full-jitter design might sample uniformly between zero and a capped exponential backoff value. If a cap for the next retry is eight seconds, the sampled delay lies in that defined interval, not necessarily exactly eight seconds. The next action also needs to respect any minimum provider Retry-After and overall task deadline.
Jitter is not a substitute for rate limiting or an overload circuit breaker. A hundred clients randomly spacing requests can still exceed a service’s capacity if the aggregate volume is too high. Combine bounded retries with suitable concurrency, global budget and provider feedback rather than assume randomness creates free capacity.
Return to contents or continue to Set a real parent-task deadline.
6. Set a real parent-task deadline
A long-running AI task can call several tools in sequence: find a source, read the file, validate its date and publish an approved result. Each child tool might have its own timeout. Without a parent deadline, ten apparently reasonable per-call waits can turn one short user request into minutes of accumulated delay.
Establish an overall deadline and pass the remaining time to child operations. If the parent has sixty seconds and thirty-five have already passed, the next child cannot reasonably be granted a fresh sixty-second timeout while pretending the original promise remains unchanged. Its permitted work should be bounded by the remaining twenty-five seconds, subject to provider minimums and current task consequence.
Include queue time and intentional backoff in the budget. A five-second network timeout plus a thirty-second Retry-After already consumes thirty-five seconds before another attempt. The model should not hide those costs by reporting only inference latency. Deadline propagation makes resource consumption visible across a chain of dependent services.
A deadline is a service goal, not authority to bypass controls. If verifying a private recipient or current official source cannot fit in the time remaining, the safe response may be to hold the action and report that it is unresolved. Skipping validation to make a progress bar reach Done is worse than an honest delay.
Return to contents or continue to Attempt budgets prevent hidden nested amplification.
7. Attempt budgets prevent hidden nested amplification
Suppose an agent controller allows three attempts, its API client independently allows three, and a proxy also retries three times. In the worst simplistic fully nested case, one logical call can lead to 3 × 3 × 3 = 27 underlying attempts. That arithmetic does not assert every runtime always makes twenty-seven requests; it shows why independent retry layers need a shared policy or coordinated budgeting.
Choose where retries live. AWS’s guidance generally favours avoiding retries at many levels of a service stack because repeated attempts multiply pressure. A top-level controller may retry a high-level task while its child tool already has SDK retries, but it must account for the actual child attempt count and side-effect semantics.
Pass a remaining attempt allowance or use a shared retry-quota mechanism where the platform supports it. The parent should know when the SDK has exhausted its attempts and stop rather than invoke it again as though no retries occurred. A monitored retry budget avoids a subtle form of denial of service caused by well-intentioned agents.
Treat logical tasks as the outcome denominator, with individual transport attempts recorded separately for cost and reliability diagnosis. A model completing one worksheet after nine repeated source reads has served one user task, not nine. Counting attempts as successes creates misleading reports and rewards inefficient behaviour.
Return to contents or continue to The AWS standard-mode quota is a concrete example.
8. The AWS standard-mode quota is a concrete example
AWS’s SDK retry reference describes standard mode as using exponential backoff with jitter and a retry quota. Retries deduct tokens from a bucket that replenishes with successful work. If tokens are exhausted, the SDK returns an error rather than continuing to retry. The quota limits retry traffic, not the initial request in standard mode.
The documentation also distinguishes adaptive mode, which adds a client-side request-rate limiter that can delay even initial requests when throttling is observed. Adaptive mode’s behaviour depends on client sharing and resource scope. If one SDK client addresses unrelated resources, throttling at one can affect the others. Choosing a mode requires understanding the actual service and latency needs.
AWS documentation’s max-attempts setting includes the initial request. A configured maximum of three generally means one initial attempt plus up to two retries under the relevant SDK settings, not three extra retries. This off-by-one distinction affects expected network cost and helps explain why an engineer’s attempt logs differ from a model-generated count.
SDK defaults and supported modes can vary by language and version. Treat the official documentation for the deployed client as authoritative. A user-facing AI reply should not claim a particular retry schedule from memory without knowing which SDK, service and configuration actually handled the operation.
Return to contents or continue to Idempotency comes before retrying external effects.
9. Idempotency comes before retrying external effects
Reading a public document may be repeatable without creating a new side effect, although even reads can consume quota. Sending an email, creating a public post or changing an account is different. If the provider timed out after accepting the action, retrying blindly can duplicate it. Determine whether the action is idempotent under the provider contract or can be reconciled by stable identity before repeating it.
Google Cloud Storage’s retry strategy distinguishes always-idempotent, conditionally-idempotent and non-idempotent operations. Conditional requests using generation-match preconditions can make some writes safer to repeat. The correct mechanism depends on the object store and operation; an agent cannot make any arbitrary write safe by adding the word retry to a prompt.
For a WordPress article, the controller can retain the original post ID and canonical slug. If creation timed out, fetch the existing resource before issuing another create. A second new post with a suffixed slug would be a distinct public artifact, not evidence of successful recovery. Source version and approval remain important even when the content is similar.
An idempotency key itself has scope and lifetime. A new random key on every attempt defeats duplicate recognition. Conversely, reusing one key for a materially different user request can conflate separate intentions. Bind it to one logical operation and preserve the provider’s actual rules.
Return to contents or continue to Retrying denial can undermine user authority.
10. Retrying denial can undermine user authority
An HTTP 403 or other authorization refusal may be the expected outcome when a parent requests a record outside their scope. The correct response is not to keep retrying until the provider’s defenses loosen. It is to respect current object-level permission and, if appropriate, offer a legitimate route for requesting access.
An approval may expire during backoff. A teacher might allow publishing revision 4, then withdraw consent while the agent waits on an overloaded publishing provider. Before its next attempt, the controller should recheck the valid grant and content revision. Timeouts do not extend human approval automatically.
A common unsafe fallback is to switch to a broader administrator token after an authorization error. That changes the task’s authority rather than solving transient failure. The model should not make this decision unilaterally, even if the user repeatedly asks it to finish faster.
Log safe status evidence without publishing private request bodies or credentials. A denial can be recorded with opaque task and resource IDs, while a qualified reviewer has controlled access to the underlying decision. Retry telemetry should not become a second route for leaking what the denied operation tried to read.
Return to contents or continue to Handle 503 and temporary outages with bounded recovery.
11. Handle 503 and temporary outages with bounded recovery
A 503 response can indicate temporary service unavailability, with an optional Retry-After hint under RFC 9110. Some failures may be network timeouts or connection resets without a clear HTTP response. The client should distinguish what it actually observed and apply its provider-specific retry policy, using idempotency and overall deadline constraints.
An overloaded service can recover if clients reduce pressure. Repeated immediate calls can prevent recovery by consuming capacity as soon as it returns. Backoff, jitter, circuit breakers and concurrency limits are complementary controls. A circuit breaker may block new calls during an outage while the retry budget governs attempts for calls that actually proceed.
Some tasks can degrade safely. A school assistant may answer a stable mathematical definition from already verified public material while clearly stating that the current admissions deadline could not be checked. It should not guess the deadline or send an unapproved notification simply because the official service remains unavailable.
Monitoring should compare user outcomes and request amplification. A recovery that reduces server errors but causes a flood of duplicate posts is not reliable. Measure verified tasks, denied or unknown effects, provider throttles and extra attempts with explicit denominators.
Return to contents or continue to Retry-After must not override task cancellation.
12. Retry-After must not override task cancellation
Imagine a 429 response telling the client to wait two minutes, but the user cancels the task after thirty seconds. When the timer eventually fires, the agent must not perform the old operation. A scheduled retry is not a new independent grant to act; it inherits the original task identity and remains subject to current cancellation and authorization.
Persist the retry plan safely if the job can survive restarts, including original operation ID, source revision, next permitted attempt time and remaining budget. On resumption, revalidate the state before any external side effect. The model’s old summary saying ‘try again later’ is not sufficient authority.
If the action was already accepted before cancellation, the service should report that distinction honestly. Cancellation may stop new attempts but cannot unsend an email or unpublish text already viewed. Reconciliation and corrective work are different from choosing to retry a request.
A robust user experience reports Pending, Deferred, Cancelled, Verified Complete or Unknown according to real evidence. It does not promise that a long Retry-After will be ignored or that every cancellation can undo history.
Return to contents or continue to An original 120-task retry-budget laboratory.
13. An original 120-task retry-budget laboratory
Consider a fictional Cedar Agent Desk with 120 logical user tasks during a transient provider problem. Seventy-eight reach independently verified intended outcomes within their budget. Sixteen are correctly deferred after throttling or Retry-After beyond the permitted immediate window. Twelve have exhausted the declared retry allowance without a verified result. Eight are denied because of persistent invalid input or permission. Six have uncertain external effects requiring reconciliation.
The categories reconcile: 78 + 16 + 12 + 8 + 6 = 120. Verified outcomes represent 65%; deferred tasks 13.33%; exhausted tasks 10%; invalid or denied tasks 6.67%; unknown effects 5%. These fractions are invented teaching numbers, not real cloud provider incident rates or eduKate agent performance.
Do not interpret the forty-two not-yet-verified tasks as equivalent errors. An intentional deferral may protect an overloaded service, while an authorization denial is correct security behavior. An unknown external result can already be completed and must not be retried as though absent. The next step differs for each class.
One logical task may have several transport attempts under the SDK. The ledger here counts tasks, not all HTTP calls. An operational report can additionally show total requests, delay and quota consumption, but it should not claim that a high call count proves more student questions were answered.
Return to contents or continue to An explicit attempt-count example.
14. An explicit attempt-count example
Suppose thirty of the fictional tasks call one SDK with a configured maximum of three attempts and all thirty use the full allowance. Under the simplified model this would be ninety transport attempts for thirty logical tasks. If a separate outer layer then retried each entire three-attempt SDK operation twice more, the count could rise to 270. That is why nested budgets should be coordinated rather than silently multiplied.
Actual counts vary because successful requests stop early, nonretryable errors fail fast, circuit breakers block some calls and providers differ. The ninety and 270 are upper-bound illustrations under a deliberately artificial assumption. A trustworthy service derives actual attempt metrics from client telemetry and correlates them with parent task IDs.
Time and cost budgets also matter. A request that is cheap in tokens but expensive in provider API calls can overload a service. Conversely, several low-impact independent reads may be valid if within the user’s deadline and the upstream quota. The controller needs a clear shared budget rather than a generic model preference for thoroughness.
Teach the calculation before tuning production retries. A small class can compare one user intention with its network attempts and see why the denominators differ. This practical distinction applies to storage uploads, email sending and official document retrieval.
| Task outcome | Tasks | Share | Follow-up |
|---|---|---|---|
| Verified within budget | 78 | 65% | Accepted user outcome |
| Deferred under provider limit | 16 | 13.33% | Wait or reschedule |
| Attempt budget exhausted | 12 | 10% | Stop repeated pressure |
| Invalid or unauthorized refused | 8 | 6.67% | Correct input or permission |
| External effect unknown | 6 | 5% | Reconcile original operation |
| All fictional tasks | 120 | 100% | Logical task denominator |
Return to contents or continue to Changed-context forty-task school-publisher case.
15. Changed-context forty-task school-publisher case
Transfer the method to forty fictional school publishing tasks. Twenty-six are verified correctly saved, six are deferred by provider rate limits, four are correctly refused because approval is missing, two reach a retry limit without confirmation, and two have uncertain publication outcomes after timeout. The total is 26 + 6 + 4 + 2 + 2 = 40.
Verified share is 65%, deferrals 15%, refusals 10%, exhausted 5% and unknown 5%. These figures are not a real website success rate; they are selected to demonstrate categories. A missing approval is not solved by waiting and retrying, while a genuine provider rate limit may be safely respected under the task deadline.
Now change the recipient or article version while the job waits. A new approval may be required even if the original retry timer has not expired. The application should not submit materially different content under an older grant. The feature’s original operation ID connects retries to the correct resource and source revision.
Finally, suppose one unknown publication is discovered already live under its original WordPress post ID. Verified increases to twenty-seven, unknown decreases to one, and the forty-task population remains unchanged. No new create request was needed. That is successful reconciliation rather than an additional model achievement.
Return to contents or continue to Repair a retry storm without weakening safety.
16. Repair a retry storm without weakening safety
Failure one: a controller retries every HTTP response, including invalid inputs and access denials. Repair error classification and current authorization checks. Failure two: an SDK retries three times while three outer layers each retry three times. Repair attempt-budget coordination and avoid unnecessary nesting. Failure three: synchronized backoff schedules create recurring overload. Apply appropriate jitter and rate limits.
Failure four: Retry-After asks the client to wait longer than the user’s remaining deadline, but the agent ignores the deadline. Repair propagation of the parent task’s available time. Failure five: a timeout after a possible write causes duplicate emails or posts. Preserve idempotency identity and reconcile the original target before any repetition.
Failure six: a cancelled job wakes from a delayed retry and sends a message anyway. Repair the execution boundary to recheck cancellation and approval immediately before an external effect. Failure seven: a broad administrator credential is used to bypass a 403 denial. Repair least privilege and make a protected refusal the accepted result.
Test each repair with fictional resources and an isolated provider simulator. Observe real request counts, timer bounds, cancellation and target state. A model-generated explanation that retry behavior improved cannot certify that no duplicate side effect occurred.
Return to contents or continue to A useful retry runbook for education systems.
17. A useful retry runbook for education systems
Begin with the user’s real request: read a source, download a worksheet, save a draft or send an approved notification. Record whether the operation is safely repeatable and what outcome the service must verify. Establish maximum attempts, parent deadline, provider Retry-After handling, jitter policy and any resource-specific quota constraints.
Use the official SDK’s retry settings where suitable, then ensure outer agent orchestration does not multiply them. Monitor attempts, throttled responses, unknown effects and verified tasks under distinct units. Keep stable identities and target revisions so a restart can resume responsibly.
When the retry budget ends, return a useful honest state. A parent may receive the already verified parts of a Maths explanation with a note that the current official document could not be retrieved. An editor may find that a draft was saved but publication remains unverified. Do not invent a successful source check or public link just to close the conversation.
The enduring lesson is that retries are a tool to improve legitimate completion, not an entitlement to consume unlimited network capacity or ignore permission. A reliable agent respects the provider, the user’s deadline and the original operation’s real outcome. More capable reasoning does not remove those boundaries.
Return to contents.
18. Carry a remaining time allowance through parallel agents
An AI task may launch several child workers to retrieve official sources, evaluate a draft and check a publication target. Those children can run concurrently, but they still belong to one parent user request. Each should receive a meaningful remaining deadline and a bounded service budget. Ten child workers must not each assume they own the full original sixty seconds when the parent’s result needs a coherent finish.
Parallelism complicates retry allocation. One child may return immediately while another receives a 429 and asks for two minutes. The parent may choose to report a partial safe result or postpone the dependant action, but it cannot declare all work complete simply because some other child succeeded. Track which checks remain necessary and which can legitimately be omitted under the task contract.
Use cancellation propagation. If the user withdraws a parent task, children waiting in jittered backoff should not awaken and issue new external effects. Their operation tokens and current authorization must remain tied to the parent. A worker that ignores a cancelled parent because its timer was scheduled earlier violates the execution contract even if its HTTP request later succeeds.
Protect source consistency too. One worker may retrieve a newer official school notice while another reads a cached old version. The parent should reconcile source identities and effective dates rather than combine both into a confident answer. Shared task deadlines support coordination, but only independent evidence confirms which facts govern the user’s decision.
Return to contents to choose a related check.
19. Compare budgets by total workload, not only call delay
Consider an invented request budget of sixty seconds and at most five total outbound attempts. The agent makes one source call taking ten seconds, encounters a throttle requesting twenty seconds of waiting, then needs an additional source confirmation estimated at fifteen seconds. The simple total is 10 + 20 + 15 = 45 seconds, leaving fifteen seconds for the remaining task under these assumptions.
If another provider requests a Retry-After of thirty seconds, its next attempt would exceed that remaining fifteen seconds. A robust controller does not silently reset the clock because it entered a new tool. It can defer, explain the current limitation or choose an authorized alternative that genuinely fits the remaining deadline.
Do not turn this arithmetic into a promise of exact production duration. Actual network latency, queue delays, user review and source availability vary. The calculation is a teaching method for reasoning about resource constraints. A proper implementation measures elapsed time using an appropriate clock and maintains deadlines across worker restarts.
Track both successful and refused outcomes. A permission denial may finish its own control decision quickly but leave the user’s proposed external action intentionally unfinished. Waiting longer does not make it legitimate. A useful budget makes clear when a technical retry is possible and when a different human decision is required.
Return to contents to choose a related check.
20. Bound retries after a task changes version
Suppose a publishing agent prepared article revision 4 and scheduled a retry after a temporary WordPress timeout. While it waited, the editor corrected a numerical statement and approved revision 5. The original retry may no longer describe the correct intended content. Before submission, check the current task version and grant instead of blindly replaying a stale body.
A stable logical operation identity can help reconcile revision 4 if it may already have been saved. That earlier operation remains a historical fact even though revision 5 is now the desired target. The controller should find the original post record and update the intended owner only under valid authorization, avoiding an unnecessary second URL.
Retry eligibility can expire before the transport-level retry counter. A task may have one unused attempt remaining, yet the user has cancelled or the signing credential has expired. Budget is a ceiling, not a promise to execute every remaining attempt. Current authority and source state can stop an operation earlier.
Expose useful statuses: source revision changed, approval renewal required, original write outcome unknown or safely deferred. A generated message saying ‘retrying now’ should reflect an actual permitted scheduled action. Transparency about state is more useful than pretending the controller can always finish by making additional calls.
Return to contents to choose a related check.
21. A robust simulation includes overload and duplicate effects
Build a fictional provider that returns success to ordinary reads, 429 with different Retry-After forms, a temporary 503, and a timeout after committing one write. Run the same agent through each condition under an explicit parent deadline. The test harness should record actual attempts and target state independently from the model’s descriptions.
Verify that a delay-seconds header and an HTTP-date header produce appropriate bounded scheduling, with cancellation preventing a later call. Verify that unrelated 400 and permission-denied errors do not cause endless identical retries. A test where a mock always returns Success cannot establish that the retry policy works during the very failures it was designed to manage.
Simulate an SDK with internal retries and an outer orchestrator that is tempted to retry again. The harness should reveal total network attempts, not merely logical tool calls. Fail the regression test if an agreed maximum is exceeded or if one uncertain write produces duplicate external effects.
Test recovery too. A transient source read may legitimately succeed on its second bounded attempt. The final answer can then cite the verified source. The engineering goal is not to make every failure permanent, but to maximize correct useful completion without amplifying outages or bypassing user authority.
Return to contents to choose a related check.
22. A small-team policy for honest termination
Start with one table naming operation type, retryable conditions, idempotency method, maximum attempts, backoff configuration, total deadline and terminal evidence. Keep reads, uploads, publication and private messaging separate because they have different consequences. Document which underlying SDK already retries so the parent does not multiply attempts inadvertently.
Use safe defaults on unknown errors. The model should not decide that a novel error code means temporary failure simply because its text resembles an outage. Preserve the provider’s actual response, classify it under the documented contract and hold consequential effects when completion or permission cannot be established.
When the budget ends, a human-facing status should say what was verified and what remains. A parent may still get a useful explanation of algebra while the current official timetable is unavailable. An editor may receive the saved draft link while publication remains pending. These are honest partial outcomes rather than failures to be hidden.
Monitor confirmed results per user task, total provider attempts, throttling, expired authorization, cancellations and uncertain effects. Investigate patterns, then adjust budgets under accountable change control. A high successful-call count with repeated wrong-recipient messages is not improvement, and a correct protective refusal is not a defect to be retried away.
Return to contents to choose a related check.
- 18. Carry a remaining time allowance through parallel agents
- 19. Compare budgets by total workload, not only call delay
- 20. Bound retries after a task changes version
- 21. A robust simulation includes overload and duplicate effects
- 22. A small-team policy for honest termination
Frequently asked questions
What does Retry-After specify?
An HTTP-date or seconds to wait before a follow-up request under the applicable HTTP response semantics.
Why add jitter to backoff?
To spread synchronized retry attempts and reduce renewed spikes against a recovering dependency.
Does three max attempts mean three retries?
Not in the common AWS SDK setting; it includes the initial attempt, allowing up to two retries.
Can a timed-out write always be retried?
No. It may have committed; reconcile by stable operation identity or provider-supported idempotency first.
Should an agent ignore an HTTP 403 when the user insists?
No. Authorization must be corrected legitimately, not bypassed through wider credentials or repeated attempts.
What if Retry-After exceeds the task deadline?
Hold or defer appropriately under current permission, rather than exceed the agreed task budget.
Primary technical sources
Technical sources checked 25 October 2026. The Cedar service, attempt counts, deadlines and recovery outcomes are invented teaching cases. Provider retry defaults can vary by SDK and version.
- RFC 9110 — Retry-After: Date and delay-seconds syntax and response semantics.
- RFC 6585 — HTTP 429: Too Many Requests and optional retry guidance.
- AWS SDK Retry Behavior: Standard and adaptive modes, retry quota and max attempts.
- AWS Builders Library — Timeouts, Retries and Jitter: Transient failures, overload and retry amplification.
- Google Cloud Storage Retry Strategy: Idempotency and bounded exponential backoff with jitter.
- Google Cloud IAM Retry Strategy: Truncated backoff and overall deadline.
- Google AI Troubleshooting: Provider-specific transient and non-retryable error handling.
Connected specialist guides
Continue with Super Intelligence curriculum; Circuit Breakers; Connection Pools; Dead-Letter Queues; Batch Writes; Agent Cancellation; Gold Standard of Education. The retry budget must respect both provider capacity and the original user’s authorised task.