A retry is useful only when another attempt can plausibly succeed and the caller can tolerate the delay. Agent-context integrations should distinguish permanent request errors from temporary dependency failures, cap exponential backoff with jitter, and preserve a useful fallback—especially on a live call.
Classify before retrying
| Status or failure | Default action |
|---|---|
400 bad_request | Fix malformed input; unchanged retry will repeat the error. |
401 unauthorized | Repair credential/configuration; do not rotate or hammer automatically. |
404 not_found on caller lookup | Treat as an empty caller state. |
422 validation_error | Fix request shape. |
429 rate_limited | Honor the reset/retry window and add jitter. |
500 or 503 | Retry with a small capped budget when the operation is safe. |
| Timeout/network failure | Treat state as uncertain; consider idempotency before retrying a write. |
The status is only the first signal. HTTP method, operation semantics, platform deadline, and duplicate-delivery behavior matter too.
Keep voice recall bounded
The caller can hear your retry budget. Race optional context against an application deadline derived from your end-to-end measurements. If the budget expires, continue with the neutral first-contact path and preserve the trace for later diagnosis.
Do not translate “designed for sub-300ms voice recall” into three automatic 300ms attempts. It is a design phrase, not an integration timeout or measured guarantee.
Use capped exponential backoff with jitter
const delays = [150, 350, 800];
for (let attempt = 0; attempt <= delays.length; attempt++) {
const response = await callNorthsun();
if (response.ok) return response;
if (![429, 500, 503].includes(response.status)) throw await toError(response);
if (attempt === delays.length) throw await toError(response);
await sleep(delays[attempt] + Math.random() * 100);
}
The numbers are illustrative application settings, not Northsun (formerly Mnemix) performance recommendations. Choose them from the full request deadline and server-provided rate information.
Prevent synchronized recovery
Without jitter, hundreds of agents retry at the same interval and create a second outage wave. Cap both per-request attempts and global concurrency. Honor a circuit breaker when a dependency is broadly unavailable, and use one probe path to test recovery instead of letting every caller probe simultaneously.
Reads and writes have different uncertainty
Repeating a read may cost time but normally does not create duplicate state. Repeating calls/end after a lost response can. Deduplicate by stable platform call ID in your application, inspect later state when possible, and avoid unbounded retries when an earlier write may have succeeded.
Record the final status, UTC time, safe correlation identifiers, attempt count, and whether the agent used a fallback. Do not log API keys or unnecessary caller/transcript data.
Continue with Errors and retries, Troubleshooting, and Production readiness.