How to Build Durable AI Agents with Temporal

Temporal is a workflow engine: you write a workflow as ordinary code, and if the server running it crashes, another one picks it up where it stopped. Temporal calls this durable execution. Agents fit that model well, and Cursor runs its cloud agents on it.

An agent built on an SDK like the OpenAI Agents SDK can run on Temporal with a small code change. A complete agent like Claude Code is hard to run on it, and writing your own agent loop on Temporal is a substantial project.

The Short Version

How Temporal Makes an Agent Durable

Temporal splits your code in two. A workflow is the code that decides what happens next, and it has to make the same decisions every time it runs. An activity is anything that touches the outside world, like a model call or a tool. Temporal records the result of every activity that finishes.

When a server crashes, another one runs the workflow code again from the top. Each activity that already finished hands back its recorded result instead of running again, so the code arrives at the point where it stopped and keeps going. For an agent, the loop is the workflow, and each model call and tool call is an activity. Because the model's answers are recorded, it doesn't matter that the model might answer differently the second time: the workflow reuses the answer it already got.

Activities retry automatically, with no limit on attempts by default, so a tool that sends an email can send it twice unless it checks first. An activity's result is recorded only when it finishes, so streaming tokens to a user needs a separate path. Workflow Streams, Temporal's feature for that, is still in preview.

Temporal's Integrations

Temporal has integrations for the OpenAI Agents SDK, Pydantic AI, the Vercel AI SDK, LangGraph, LangChain's Deep Agents, Google's ADK, Strands, Spring AI, and Mastra. The OpenAI Agents SDK integration for Python is generally available, Pydantic maintains its own, and most of the rest are in preview.

Each integration runs the framework's agent loop inside a workflow and its model calls inside activities. How much one activity covers depends on the integration: the OpenAI Agents SDK integration makes each model call its own activity, while with LangGraph you choose which nodes run as activities. With the OpenAI Agents SDK, you write ordinary SDK code in a workflow and add Temporal's plugin when you connect:

@workflow.defnclass HelloWorldAgent:    @workflow.run    async def run(self, prompt: str) -> str:        agent = Agent(name="Assistant", instructions="You only respond in haikus.")        result = await Runner.run(agent, input=prompt)        return result.final_output

In most integrations, a tool that calls an API has to be declared as an activity. Some tools can't run at all: Temporal's docs say the OpenAI SDK's local shell and computer-use tools aren't supported "because they assume a single long-lived local process," the same property that makes Claude Code hard to run on Temporal. Temporal saves the result of every finished activity, so after a crash only the activities still running start over.

Running Claude Code or Codex on Temporal

Claude Code, Codex, and OpenCode are complete agents, with their own loop, tools, session files, and approval prompts, all inside one process. Temporal has no official integration for any of them, and a Temporal engineer explained why: they run inside a single process and don't save their progress in small enough steps for Temporal to recover them.

Temporal's own team ran the Pi coding agent on Temporal, which took a fork of Pi, shared storage for its session files, and its own records of which tools had started. "Everything here was a retrofit through a small fork of Pi," they wrote.

A draft Claude Code integration in Temporal's own repository runs each Claude Code turn as a single activity. Temporal can't record what happens inside Claude Code's more complex features, so the integration disables "subagents, background Bash, external MCP servers, plugins, skills and settings." Model calls stay inside the Claude Code process, so the model work in a turn lost to a crash can be billed again.

An outside contributor's draft goes further, running each model step and each tool call as its own activity. It held up through hundreds of test runs with the worker killed at random, but it adds 78,000 lines of code and depends on how closed-source Claude Code pauses a tool call.

The simplest pattern runs a whole agent run as one long activity. When it crashes, Temporal retries the activity and the run starts over, unless you've saved Claude Code's session somewhere shared. By default its session files sit on the local disk and don't survive "a move to a different node." Even with the session saved, you still have to restore the files it was working on and work out whether an interrupted tool ran. Vercel took a different route with similar trade-offs, covered in How Vercel's durable-harness Works.

Writing Your Own Loop

The other path is writing the agent loop yourself as a workflow: call the model in an activity, run the tools it asks for as activities, and repeat. Temporal's AI Cookbook has working examples. You get full control, and Temporal saves every step. You also take on everything a ready-made agent would otherwise handle:

• Context. Temporal knows nothing about models, so building prompts and summarizing long conversations is yours.
• Long conversations. A workflow's history is capped at 51,200 events or 50 MB, so a long chat has to start a fresh run and carry its state over.
• Streaming. Sending the answer to the user as it's written needs Workflow Streams or your own messaging system, like Redis.
• Approvals. Temporal can deliver a message to a waiting workflow, but the approval UI, permissions, and timeouts are yours.
• Code changes. After a crash, Temporal reruns your workflow code to get back to where it was, so deploying changed code can break runs that are still going. You need versioning and tests against old runs.
• Retries. By default Temporal retries a failed call forever, which its own reference architecture says "is not appropriate for LLM API calls." Mark errors that won't fix themselves, like a bad request, as final.
• Long model calls. A call that runs for a while needs heartbeats so Temporal knows the worker is alive, and "each heartbeat is a Temporal Action" you pay for.

Vertesia's founder wrote that Temporal "does not know what a model is. It has no notion of tokens, of context windows, of streaming completions. We had to model all of that ourselves." Mistral, which built its Workflows product on Temporal, had to add "streaming, payload handling, multi-tenancy, and observability that the core engine does not provide out of the box."

Cursor runs its own agent loop on Temporal. Cursor's Jeremy Stribling said that before it, they had "basically built a bad version of Temporal."

Temporal is building its own option, the Temporal Agent Harness, still "earlier than public preview." Its pitch is that full harnesses are hard to control and SDKs leave too much to build: "One is too small. The other is too large."

Agents Built to Survive Crashes

Temporal can only recover the steps it records. When an SDK's agent loop runs inside a workflow, Temporal records its model calls and the tools declared as activities. Claude Code runs its whole loop inside its own process, so Temporal sees only when a turn or run starts and ends. Recovering from a crash means repeating that work, or turning features off as the draft integration does.

The other approach is an agent designed to save its own progress as it goes. Earendil, the team behind Pi, said they tried a workflow engine for their own agent first and found it didn't make the agent durable by itself, so they built durability into Pi Durable instead. Even Temporal's Pi post agreed that "Pi Durable got the programming model right."

Temporal's experiment with Codex shows the same thing. It runs each Codex turn as one activity, yet a crash loses only about one step, because Codex writes each step to its own session log as it happens, as the experiment's README notes. That recovery comes from Codex's log, not from Temporal. A harness that saves its own progress still needs something to store it, make sure only one server runs each agent, and restart work after a crash.

Omnara, the open-source agent platform we build, is both: an agent that saves every step and the service that runs it, with an API. Each finished step is saved to Postgres as it happens. Each agent is claimed by one worker at a time, and if that worker dies, another continues from the saved history. Omnara doesn't replay workflow code to get back to where it was.

It includes the pieces you'd build yourself on Temporal: approvals that wait for someone to answer, custom tools the agent waits on even if your worker restarts, streams that resume, subagents, users and roles, schedules, and webhooks. We wrote about the design in The Log Is the Agent.

If you already have an agent loop and only need it to survive restarts, a workflow engine is much less to adopt. With Omnara you configure an agent instead of writing its loop, so if you need your own code to run between steps, Temporal fits better. Omnara also restarts a model call that was cut off and has no option to rerun a tool marked safe. A tool call that was cut off comes back to the agent as interrupted, with its outcome unknown.

Which One to Pick

Temporal is a strong choice when you own the agent loop and want a proven engine under it, especially if you already run other workflows on it.

• Your agent uses the OpenAI Agents SDK, Pydantic AI, LangGraph, or the AI SDK: use Temporal's integration. It's the smallest change.
• You want full control and have a team to run it: write your own loop on Temporal, and plan for context, history limits, streaming, and versioning from the start.
• You want Claude Code or Codex to survive crashes: there's no released integration yet. The draft one turns off subagents, skills, and plugins, so check what you'd lose first.
• You'd rather configure an agent than write its loop: use Omnara for approvals, users, schedules, and webhooks without building them on an engine.

For the full production checklist, see How to Deploy an AI Agent to Production.

FAQ

Does Temporal support the OpenAI Agents SDK?

Yes. The Python integration is generally available: you write ordinary SDK code in a workflow, add Temporal's plugin, and each model call becomes an activity. Tools that call APIs need to be declared as activities.

Can I run Claude Code on Temporal?

Not with an official integration. A draft integration runs each Claude Code turn as one activity and disables subagents, skills, plugins, and settings. Running a whole agent run as one activity also works, but a crash repeats the run unless you save Claude Code's session somewhere shared, and even then you have to restore its files.

What are the alternatives to Temporal for AI agents?

Inngest, Restate, DBOS, and Vercel's Workflow SDK work on the same idea: you run your agent's steps through their APIs, and they save finished steps and retry interrupted ones after a crash. They differ in how you write those steps, where they run, and what they cost. LangGraph has its own checkpointer. If you'd rather not write the agent loop at all, Pi Durable and Omnara are agents built to survive crashes on their own. Pi Durable still needs somewhere to run and keep its progress, while Omnara comes with that, along with approvals, users, and schedules, hosted or on your own servers.

How much does Temporal cost for agents?

Temporal Cloud charges per action, starting at $50 per million, plus fees for stored history and your plan, and you pay for your own workers and model calls. A turn with a handful of model and tool calls is a fraction of a cent in actions, but streaming answers to users and the check-ins Temporal needs from long-running activities add up. Self-hosting is free, but Temporal's production checklist warns it "takes significant engineering and ongoing effort."