Durable execution is the technique that lets an AI agent finish its task even if the process crashes, restarts or hits an API rate limit halfway through. Temporal[1] is the open-source platform that has done most to popularise this model, and since 2026 it ships official integrations with the OpenAI and Vercel agent SDKs. In this guide you will see why long-running agents fail mid-way, what durable execution is, how Temporal splits work into workflows and activities, an agent that survives restarts, and how it differs from a plain message queue. The same explanation is available in Spanish.

Key takeaways

  • Durable execution guarantees, in the words of Temporal’s documentation, that a function "executes to completion, whether that takes minutes, hours, days, weeks, or even years", recovering from failures on its own.
  • Temporal is free software under the MIT licence; its main repository has over 21,700 stars on GitHub and is on version v1.31.2, released on 8 July 2026.
  • The model splits work into two pieces: workflows (the orchestration logic, deterministic and replayable) and activities (any external call: to the model, a tool or an API), which Temporal retries on its own when they fail.
  • The official OpenAI Agents SDK integration (temporalio.contrib.openai_agents) reached general availability on 23 March 2026, after a public preview in July 2025; you install it with pip install "temporalio[openai-agents]" and it needs Python 3.10 or higher.
  • It turns each agent into a crash-proof process without rewriting your code: you wrap the agent logic in a workflow and model calls run as retriable activities.

Why do long-running agents fail mid-way?

An AI agent is not a single model call: it is a loop. The model reasons, decides to invoke a tool, reads the result, reasons again and repeats the cycle until it finishes. Every turn touches the outside world, and that is where the trouble lies: tools call APIs that sometimes fail, and models hit rate limits that force retries. The longer the agent runs, the more expensive it is to start the task from scratch.

Picture an agent that processes a refund: it looks up the order, checks the warranty, issues the refund and notifies the customer. If the process crashes after issuing the refund but before notifying, what happens on restart? Without protection, you either lose the work done or repeat it and refund twice. Temporal’s documentation puts it plainly: models "can encounter rate limits, requiring retries", and the longer the agent lasts, the more it hurts to restart it.

The usual answer (save state in a database, stand up queues, hand-write state machines) works, but it fills your code with plumbing that has nothing to do with the agent logic. That is exactly the heavy lifting durable execution takes off your plate. The problem gets worse once the agent is deployed to production, where a container restart cannot turn into a lost task.

What is durable execution?

Durable execution is a programming model in which, once it starts, your application’s main function runs to completion no matter what happens underneath. If the process crashes, the machine reboots or the network drops, the system reconstructs the exact state it was in and carries on from there, without repeating work already done.

The trick is in how that memory is achieved. Temporal records every step your program takes in a durable event history. When something fails and the process comes back up, Temporal replays that history to rebuild the in-memory state and resumes execution right where it left off. That is why deterministic steps (your logic) are kept apart from non-deterministic ones (external calls): the former can be replayed with no side effects, the latter are recorded exactly once.

The Temporal team describes it with a line that sums up its pitch: "With Temporal, you get to code the happy path, and Temporal does the error handling for you." In practice, this means you stop writing try/except blocks with manual retries, timers and idempotency checks: the system provides them out of the box.

Temporal: workflows and activities

Everything in Temporal revolves around two abstractions. A workflow is the function that holds your orchestration logic; it must be deterministic, because Temporal replays it to recover state. An activity is any operation that touches the outside world and is therefore non-deterministic: a language-model call, an API request, a database write. Temporal runs activities exactly once, stores their result and retries them under the policy you define if they fail.

Applied to an agent, the split is natural: the agent logic (the reasoning loop) lives in the workflow, and each model or tool call becomes a retriable activity. In Python, a workflow is marked with the @workflow.defn decorator and an activity with @activity.defn. This minimal example defines a weather tool as a durable activity:

from dataclasses import dataclass
from datetime import timedelta
from temporalio import activity, workflow
from temporalio.contrib import openai_agents
from agents import Agent, Runner

@dataclass
class Weather:
    city: str
    temp_range: str
    conditions: str

@activity.defn
async def get_weather(city: str) -> Weather:
    """Get the weather for a city (here, a fixed value)."""
    return Weather(city=city, temp_range="14-20C", conditions="Sunny")

@workflow.defn
class WeatherAgent:
    @workflow.run
    async def run(self, question: str) -> str:
        agent = Agent(
            name="Weather Assistant",
            instructions="You are a helpful, concise weather agent.",
            tools=[
                openai_agents.workflow.activity_as_tool(
                    get_weather,
                    start_to_close_timeout=timedelta(seconds=10),
                )
            ],
        )
        result = await Runner.run(starting_agent=agent, input=question)
        return result.final_output

The key piece is activity_as_tool: it takes a Temporal activity and presents it to the agent as just another OpenAI Agents SDK tool. The model decides when to invoke it, but underneath it runs with Temporal’s durability and retry guarantees. You do not write the model call yourself: the OpenAIAgentsPlugin automatically registers an activity that wraps every model invocation.

An agent that survives restarts

For that agent to run durably you need a worker, the process that hosts workflows and activities and connects to the Temporal server. This is where the OpenAI plugin kicks in:

import asyncio
from datetime import timedelta

from temporalio.client import Client
from temporalio.worker import Worker
from temporalio.contrib.openai_agents import (
    OpenAIAgentsPlugin,
    ModelActivityParameters,
)
from weather_agent import WeatherAgent, get_weather

async def main():
    client = await Client.connect(
        "localhost:7233",
        plugins=[
            OpenAIAgentsPlugin(
                model_params=ModelActivityParameters(
                    start_to_close_timeout=timedelta(seconds=30)
                )
            )
        ],
    )
    worker = Worker(
        client,
        task_queue="weather-agent-queue",
        workflows=[WeatherAgent],
        activities=[get_weather],
    )
    await worker.run()

asyncio.run(main())

Now the acid test: if you kill this process while the agent is waiting for the model’s response and start it again, the workflow does not begin from scratch. Temporal replays its history, recovers the state and continues from the last committed step, without repeating the call that had already completed. That is the whole argument for durable execution: ordinary code that survives restarts with no extra plumbing.

The same pattern enables long-running human-in-the-loop agents: a workflow can sit waiting for an approval for days without consuming resources, because its state lives in the history and not in the process memory. If you want a base with no dependency on OpenAI, the Vercel AI SDK integration follows the same idea in TypeScript: you use temporalProvider.languageModel() instead of openai() and every generateText() is wrapped in an activity transparently. And if you prefer to build the agent by hand, the approach pairs well with the Anthropic SDK or with graphs such as LangGraph.

Temporal versus simple queues

It is tempting to think a message queue (RabbitMQ, SQS, Redis) solves the same thing, and for single-step tasks it often does. The difference shows up when the agent chains decisions. A queue gives you per-message retries, but it knows nothing about the flow: it does not know you already issued the refund and only the notification is left. You have to rebuild that state by hand, with tables, idempotency flags and state machines that grow out of control.

Temporal flips the framing: the whole flow is the code, and the state is saved for you. You do not manage queues or write state machines; you write a function and the system makes it durable. In exchange, you introduce a Temporal server into your architecture and accept the constraint that workflows must be deterministic. For a single-step agent, a queue is simpler. For an agent that reasons, calls tools and may run for hours or days, Temporal removes exactly the complexity a queue leaves on your desk. At its Replay 2026 conference, Temporal doubled down on this bet by announcing Serverless Workers and integrations with Google ADK on top of the OpenAI Agents SDK.

Frequently asked questions

Do I need a Temporal server to use durable execution?

Yes. Temporal is a client-server system: your worker connects to a server that stores the event history and coordinates retries. You can self-host it with Docker for development (temporal server start-dev) or use Temporal Cloud, the managed service. Without that server there is no history to replay, so durability does not exist; it is the trade-off for not having to write state persistence yourself.

Does Temporal only work with OpenAI or with any model?

It works with any. The OpenAI Agents SDK integration is the most polished and reached general availability on 23 March 2026, but the OpenAI Agents SDK supports models from many providers. There is also the Vercel AI SDK integration for TypeScript and, ultimately, you can always wrap any model call (Anthropic, Gemini, a self-hosted model) in a Temporal activity by hand, without relying on any integration.

What is the difference between a workflow and an activity?

A workflow holds the orchestration logic and must be deterministic, because Temporal replays it to recover state after a failure. An activity is any non-deterministic operation or one with side effects (calling the model, an API or the database) and runs exactly once, with automatic retries. The rule of thumb: if it touches the outside world, it goes in an activity; if it only coordinates, it goes in the workflow.

Conclusion

Durable execution with Temporal turns a fragile agent into a crash-proof one without you having to write state persistence, retries or state machines. The idea is simple: your logic lives in a deterministic, replayable workflow, and every model or tool call runs as a retriable activity. With the temporalio.contrib.openai_agents integration now generally available and Temporal on version v1.31.2, the pattern is production-ready. The next step is to install it with pip install "temporalio[openai-agents]", spin up a development server and wrap your first agent in a workflow to watch it survive a restart.

Sources: [1] Official Temporal documentation[2], [2] OpenAI Agents SDK integration on GitHub[3], [3] General availability announcement on the Temporal blog[4], [4] temporalio package on PyPI[5].

Visitas: 0

Sources

  1. Temporal
  2. Official Temporal documentation
  3. OpenAI Agents SDK integration on GitHub
  4. General availability announcement on the Temporal blog
  5. temporalio package on PyPI

Route: AI Agents in Production: Evaluation and Reliability