A safe retry policy begins by separating read-only calls from reversible and irreversible effects, because the same transport failure can permit an automatic retry in one tool and require human review in another.
Classify the effect before choosing a retry policy
List every tool by the change it can make. A search or read can usually repeat without altering state. A draft creation can repeat only if duplicate drafts are detectable. A payment, message, deletion, deployment, or account change needs a stable operation identifier and a downstream system that honors it. The model's intention does not make the effect idempotent; the receiving service and stored operation record determine whether repetition is safe.
Record the request schema, normalized arguments, actor, target resource, operation key, first attempt, later attempts, downstream response identifier, and final disposition. If the caller times out after sending a request, mark the effect as uncertain until the downstream record is checked. Retrying an uncertain irreversible action without reconciliation can turn a recoverable timeout into a duplicate customer-visible event.
Bound retries by error class and total work
Temporal documents automatic Activity retries with increasing delays and distinguishes those retries from whole-workflow retries. That distinction matters for agents. Retry the smallest operation whose preconditions and effect are known, and avoid restarting a complete workflow when earlier steps already changed external state. Assign permanent errors, such as invalid arguments or denied permission, to a non-retryable class so more attempts do not consume time or hide a required correction.
Every policy needs a maximum attempt count, maximum elapsed time, backoff rule, per-attempt timeout, and terminal state. The final state should preserve the last error and all prior attempt identifiers. A human-review queue should receive exhausted operations, uncertain effects, and requests whose arguments changed between attempts. The reviewer needs a proposed next action, not a raw stack trace alone.
Verify behavior with injected failures
Run the same accepted tool case through a timeout before dispatch, a timeout after dispatch, a transient provider error, a permanent validation error, a worker restart, and a duplicate trigger. Check both the returned status and the downstream system. A passing test demonstrates that the runtime either produced one intended effect, produced no effect with a clear recovery path, or stopped for review when the effect could not be established.
Reality Contact, LLC installs and records the retry controls for Agent Runtime Reliability. The buyer defines which actions can repeat, which require confirmation, and who resolves uncertain effects. The evidence covers only the named tool versions and failure cases, so production owners remain responsible for credentials, downstream policy, and any action outside the accepted scope.
Where the service stops
Reality Contact, LLC implements and verifies bounded runtime changes but does not certify security or availability, approve credentials, authorize consequential actions, or operate the service indefinitely. The buyer approves boundaries and scenarios, controls every production credential and release, and moves workflows only after reviewing the evidence. This is software implementation and technical verification; it does not replace the buyer's security, privacy, legal, compliance, or production-readiness review. We do not promise continuous availability, error-free execution, complete incident causation, safe behavior outside the accepted scenarios, or recovery from every possible failure.
Sources: Temporal documentation for retry policies; AWS Well-Architected guidance for failure management.