This is the key exercise of the workshop. You take the agent from Exercise 1 and the Temporal primitives from Exercise 2 and snap them together usingDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/temporalio/edu-ai-workshop-openai-agents-sdk/llms.txt
Use this file to discover all available pages before exploring further.
temporalio.contrib.openai_agents. The result is a production-ready AI agent where every LLM call runs as a Temporal activity—automatically retried on failure, fully observable in the UI, and persistent across crashes.
Timebox: 15 minutes — Work through
solutions/03_durable_agent/solution.ipynb together during the workshop. Afterwards, practice in exercises/03_durable_agent/exercise.ipynb.What You’ll Learn
OpenAIAgentsPlugin
Register Temporal’s official plugin to make the Agents SDK route every model call through a Temporal activity automatically.
Automatic Retries
Watch Temporal retry a failing LLM or tool activity without any explicit retry code in your agent.
State Persistence
Crash the worker mid-execution and restart it—the workflow resumes from the exact activity that was in-progress.
Trace Correlation
Correlate the Temporal workflow ID with the OpenAI trace ID to debug agent decisions alongside infrastructure events.
Goal
BuildWeatherAgentWorkflow, a Temporal workflow that internally creates an OpenAI agent and runs it under OpenAIAgentsPlugin so that each LLM inference call becomes a durable Temporal activity. Demonstrate a failure-and-recovery cycle using the make_api_call_bug function.
Architecture
The Key Insight
Solution Walkthrough
Install dependencies and import everything
The critical new imports are
OpenAIAgentsPlugin and ModelActivityParameters from temporalio.contrib.openai_agents.Define the weather activity
This is a standard Temporal activity, exactly as in Exercise 2. Notice
make_api_call_bug is provided to let you simulate a transient failure and watch Temporal retry it.Define the workflow
The workflow creates the
Agent inside @workflow.run and wraps the get_weather activity as a tool using openai_agents.workflow.activity_as_tool(). This is the bridge between the Agents SDK tool-calling protocol and Temporal activities.sandboxed=False is required when running inside a Jupyter notebook. Temporal’s default workflow sandbox uses a deterministic Python runtime that restricts certain imports. In production .py files you can use the default (sandboxed) runner.Start the worker with OpenAIAgentsPlugin
Registering
OpenAIAgentsPlugin on the client is what activates the durable-LLM-call mechanism. ModelActivityParameters lets you configure timeouts, retry policies, and other activity-level settings for every model inference call.Simulating Failure and Recovery
The real magic of durable execution becomes tangible when you simulate a failure. The notebook includes a dedicated section for this:Introduce a bug in the activity
In the activity cell, swap Re-run the activity cell, then re-run the worker and starter cells.
make_api_call(state) for make_api_call_bug(state) by changing:Watch automatic retries in the Temporal UI
Open the workflow in the Temporal UI. You will see the
get_weather activity being retried with exponential backoff. The workflow stays in Running state—it has not failed; it is waiting for the activity to succeed.Fix the bug and restart the worker
Revert the activity call back to
make_api_call(state), then cancel and restart the worker:Temporal UI Correlation
When the workflow completes you will see two IDs you can correlate:| ID | Where to Find It | Purpose |
|---|---|---|
| Temporal Workflow ID | Temporal UI → Workflow list | Identifies this specific workflow execution end-to-end |
| OpenAI Trace ID | Temporal UI → Activity inputs/outputs | Correlates with traces in the OpenAI platform dashboard |
Stretch Goal
Add explicit retry options to ModelActivityParameters
Add explicit retry options to ModelActivityParameters
By default, Temporal retries activities indefinitely with exponential backoff. You can customise this behaviour by passing Change
retry_policy to ModelActivityParameters:maximum_attempts to 3, trigger make_api_call_bug, and watch the workflow fail definitively after the third attempt. Then explore how the workflow transitions to a Failed terminal state versus the indefinite Running state you saw before.