Failure boundaries
Temporal guidance places nondeterministic and failure-prone work, including API and LLM requests, in Activities rather than deterministic Workflow code.
Activity retry behavior
Temporal automatically retries a failed Activity under its default policy. The policy is declarative: application code selects settings instead of implementing the retry loop.
Activity idempotency
Temporal advises Activity authors to make repeated invocation safe, because an attempt can run again when it does not successfully report its result back to the service.
In this context, idempotence means repeated Activity Task Executions do not alter system state beyond the first execution.
Retry policy scope and defaults
Temporal’s documented Activity defaults begin with a one-second delay, double later waits, limit an individual wait to one hundred times that starting delay, leave attempts unbounded, and define no excluded error classes.
Temporal documentation distinguishes this from workflow behavior: Activities have retry settings by default, whereas a Workflow Execution does not receive that same default policy.
Temporal also allows a custom Retry Policy to be supplied in the options used to start an Activity Execution or Workflow Execution.
For ordinary workflow failures, prefer a local recovery path around the affected work instead of restarting the entire business process. Whole-workflow retry can be appropriate for selected stateless or file-processing cases, but it should be an intentional design choice.
Runner and durable retry boundaries
The OpenAI Agents SDK Runner is an in-process agent-loop abstraction. Its documented entry points support asynchronous execution, synchronous execution, and event streaming.
During a run, the Runner can call a model, process handoffs, invoke requested tools, feed tool results back into the loop, and stop when a suitable final result is reached. Its turn cap can end the run when the configured number of turns is exceeded.
Runner max_turns is an iteration guard, not a durable retry policy for an Activity. Likewise, a model or tool failure policy should not be assumed from a Temporal Activity policy unless the integration code deliberately maps one to the other.
The current supplied SDK material references a Temporal integration in navigation, but it does not describe that integration’s persistence model, retry mapping, checkpointing, or guarantees.
Payment example
Temporal uses payment processing to illustrate idempotency: repeating a request for one purchase should not create an extra customer charge.
For an Activity, the supported design objective is safe re-execution. These excerpts do not establish a particular idempotency-key format, provider-status query, checkpoint schema, or compensation rule.
Source-pack limits
The supplied excerpts do not identify deployed package versions or provide release-specific change details, so APIs and documented defaults should be checked against the versions in use.
The excerpts also do not specify how the intended Agents SDK and Temporal integration is wired. Confirm which calls occur inside a single Runner invocation, which calls receive their own Activities, how cancellation propagates, and where resumed state is stored.
The supplied excerpts likewise do not establish a mandatory pre-production scenario review or prescribe checkpoint, key, retry-class, timeout-owner, and reconciliation-authority fields.