Agent work can outlive one invocation
AWS announced an integration between Lambda durable functions and Pydantic AI on September 10, 2026. It addresses a basic reliability problem in multi-step agents: a single run may call a model several times, invoke external tools and wait for other systems. If the underlying function times out or fails near the end, restarting the entire sequence can repeat expensive work and recreate side effects that already occurred.
The integration turns supported operations inside a Pydantic AI run into durable steps. Lambda records the progress of those steps. When execution resumes, the handler begins again, but operations whose results were already checkpointed return their stored results instead of running a second time. That can prevent a completed model request from consuming more tokens merely because a later operation failed. It can also avoid repeating a completed tool call whose effect was successfully recorded.
This is a useful improvement over treating an agent loop as one indivisible function invocation. Long-running work can cross temporary failures without requiring developers to build a separate checkpoint table and recovery controller around every agent. AWS says durable executions can remain active for as long as one year. Wait operations suspend the function without billing for idle compute, which supports workflows that pause for human approval or an external dependency. Those are service capabilities, not evidence that every agent will become cheaper or more reliable in practice.
The checkpoint boundary is explicit
Pydantic documents a broader checkpoint surface than the short AWS announcement conveys. Model requests, streamed model-request segments, message compaction, function-tool calls, Model Context Protocol calls and dynamic-toolset resolution can each become named durable steps. The step names incorporate the agent name and toolset identifiers so replay can associate stored results with the operation that originally produced them.
That coverage matters because modern agents perform more than one model call followed by one answer. A research agent may discover tools dynamically, query several sources, compact its conversation and call a separate service before producing a result. Recording those boundaries lets the runtime resume at a finer level than the whole agent invocation. The system can reuse a completed model response while proceeding to a tool call that had not finished.
Durability is not activated simply by attaching a capability to an agent. The run must enter through Pydantic's durable handler or its run_durable interface. Pydantic warns that an ordinary synchronous or custom asynchronous run can continue functioning without checkpoints and without warning. The AWS reference also requires Python 3.11 or newer. These conditions make deployment configuration part of the reliability model. A team cannot infer durability merely from the package being installed.
Replay is not exactly-once execution
The most important limitation appears in Pydantic's constraints rather than the announcement headline. Durable steps use at-least-once behavior and are checkpointed after their work runs. If a tool changes an external system and the invocation fails before Lambda records the completed step, replay can run the tool again. A payment, notification or database write could therefore occur twice unless the tool has its own protection.
Developers still need idempotency, meaning that repeating an operation produces no additional harmful effect. A payment tool might use a stable transaction key that the payment service rejects after the first successful charge. A database operation might use an atomic conditional update. A message producer could store a deduplication identifier. These safeguards belong at the external system boundary because the agent runtime cannot retroactively make an unrelated service transactional.
Pydantic offers per-tool controls for retry semantics, but its documentation stresses that one setting alone does not guarantee a tool runs only once. The durable SDK has a retry policy, while Pydantic AI and model-provider clients can also retry. Leaving several layers active can multiply attempts and interfere with provider instructions such as Retry-After. Operators must decide which layer owns retries and test failure timing, particularly for tools with irreversible effects.
Asynchronous agents meet a synchronous durability API
The integration also bridges two different execution models. Pydantic agents are asynchronous, while Lambda's durable step interface requires synchronous calls created on the thread that invoked the function. Pydantic runs the asynchronous agent body on a background event loop and services its durable steps on the Lambda handler thread. This allows an agent to await model and tool work while preserving one ordered sequence of checkpoints.
That bridge introduces operational constraints. Durable steps cannot be nested, and concurrent attempts to enter the bridge are rejected. Detached background tasks are not checkpointed and can outlive the invocation that created them. Pydantic also warns that cleanup from an abandoned agent run can overlap a later warm invocation if it exceeds the configured cancellation period. Mutable global state shared between the handler and agent work can therefore produce difficult timing errors. The durable runtime reduces one class of restart failure, but it does not remove ordinary concurrency discipline.
A reliability primitive rather than a correctness layer
For suitable workloads, the integration provides a concrete infrastructure benefit. Document review, research, multi-stage extraction and approval workflows may involve costly calls separated by long waits. Checkpointing completed operations can narrow the amount of work repeated after an interruption and make progress visible as a sequence of named steps. Teams can focus their custom recovery logic on business effects rather than reconstructing the entire agent conversation.
Durability does not evaluate whether a model response is accurate, whether a tool was authorized or whether the agent selected the right action. It also does not guarantee a lower bill. Checkpoint storage, active compute, retries and provider calls still have costs, and neither AWS nor Pydantic published an independent benchmark for total latency, savings or failure recovery at scale with the release. The actual result depends on interruption rates, step duration, provider pricing and how much completed work would otherwise be repeated.
The sound deployment boundary is therefore precise. Use the integration to preserve recorded progress and resume supported Pydantic AI operations on Lambda. Treat every external side effect as potentially repeatable until the receiving system proves otherwise. Keep model evaluation, tool authorization, observability and incident recovery as separate controls. Within those limits, the release turns resumability from application-specific scaffolding into a reusable part of the agent runtime, which is meaningful progress for developers building longer-lived AI workflows.