The short version: Pydantic AI's v2.14.0 release on July 20 stopped treating durable execution as a special kind of agent and started treating it as a capability — the same abstraction V2 built the whole framework around. Durability now attaches to an ordinary Agent in one line, the wrapper-agent classes are deprecated, and the backend — Temporal, DBOS, or Prefect — became something you swap without rewriting your agent.
If you shipped a crash-proof agent on an earlier release, this is a small, mechanical migration you should schedule now. If you haven't added durability yet, the friction just dropped.
What actually shipped#
The changelog line is short and it's the whole story:
AddTemporalDurability,DBOSDurabilityandPrefectDurabilitycapabilities to replace the deprecated wrapper agents.
Before v2.14, you made an agent durable by wrapping it — you built a normal Agent, then handed it to a backend-specific wrapper object (TemporalAgent, DBOSAgent, PrefectAgent) that added the checkpoint-and-resume behavior. That worked, but it meant the type of object your whole app was built around changed depending on which durable backend you chose. Durability lived in a parallel hierarchy next to everything else.
Now it's a capability you pass in:
from pydantic_ai import Agent
from pydantic_ai.durable_exec.temporal import TemporalDurability
agent = Agent(
"openai:gpt-5.6",
instructions="You're an expert in geography.",
name="geography", # required — names the durable unit
capabilities=[TemporalDurability()],
)Swap the backend and the agent is otherwise untouched:
from pydantic_ai.durable_exec.dbos import DBOSDurability
# ...capabilities=[DBOSDurability()]
from pydantic_ai.durable_exec.prefect import PrefectDurability
# ...capabilities=[PrefectDurability()]That's the tell that this is the right design: the only thing that changes between Temporal, DBOS, and Prefect is the capability you list and the infrastructure you run behind it. The agent's instructions, tools, and output type stay put.
Why "it's a capability now" is the actual news#
It's tempting to read this as a rename. It isn't. When durability is a wrapper class, the backend is a load-bearing decision you make early, because it determines the object type at the center of your app. Migrating from one backend to another later means rebuilding around a different wrapper. When durability is a capability, the backend is a late, cheap decision: you can prototype on DBOS because it's a library over Postgres, then move to Temporal when you're operating one at scale, by changing one line.
It also means durability composes. Capabilities were introduced in V2 as the general mechanism for attaching behavior to an agent — instrumentation, model resolution, and the hooks v2.13 added (get_model, resolve_model_id, for_agent). Durability now sits in that same list instead of in a wrapper that has to re-expose everything the plain agent could do. If you already understand capabilities from the V2 write-up, you already understand how to make an agent crash-proof.
The choice is now purely operational#
Because the agent code is identical across all three, picking a backend is a question about infrastructure, not features. The short version — the full comparison is here:
- Temporal is the cluster. Battle-tested at scale, rich tooling, and the native integration — but you operate a distributed system (services plus task queues) beside your app. Right when you already run it or need its maturity.
- DBOS is the library. You import it, hand it a Postgres connection string, and each step checkpoint is a single Postgres write — no separate process, no cluster. Right when your ops budget for "make it durable" is roughly zero new moving parts. It's the same library-not-a-cluster argument DBOS makes generally, now one capability away.
- Prefect is the control plane. Python-native workflow orchestration with a UI, caching, and event-driven automations — durability plus a place to watch your runs. Right when you want the orchestration visible.
Restate remains in the durable-execution family as a reference integration too, so the pattern extends beyond these three.
What a founder does this week#
If you have durable agents in production on an older release: find your TemporalAgent/DBOSAgent/PrefectAgent wrappers and plan the swap to capabilities=[…Durability()]. Deprecated isn't deleted, so nothing breaks the moment you upgrade — but deprecation is a countdown, and this migration is about as low-risk as they come because your agent logic doesn't move.
If you don't have durability yet and you're running any agent that does real work — anything that calls slow tools, waits on a human, or must survive a deploy — the reason to skip it just got weaker. It's one line and a piece of infra you may already run. The durability primer covers why an agent that can't resume from its last completed step is an agent you can't trust with a long task.
The broader pattern holds: standardize on the abstraction, not the vendor. v2.14 makes durability a capability precisely so the backend stops being a decision you're married to.
