A type is a promise about the shape of a value. It is not a witness to what happened while an agent was waiting on the world.
That distinction is the real news in a cluster of PydanticAI changes merged on July 27. The framework’s public documentation describes agents with typed dependencies, typed output, function tools, and durable execution integrations. Those are useful constraints: they can reject malformed tool arguments, validate a final structured response, and make a workflow’s interfaces easier to inspect. But the project’s new cancellation backstop deals with a different failure entirely. An agent run could be cancelled from outside, yet an activity or hook it was awaiting could catch that cancellation and return normally. Without another check, the surrounding run could continue—or look successful.
The contract a schema cannot supply
In pull request #6496, PydanticAI describes the troublesome shape: an awaited Temporal activity, event-stream handler, or capability hook catches CancelledError. In asynchronous Python, that can leave the parent task with cancellation still pending while the awaited work appears to have completed. The newly merged implementation re-checks that state at run-step boundaries and around hook phases.
The placement matters. The code does the re-check after a completed step’s messages have been written to history, then prevents the run from advancing or firing downstream success hooks. In plain language: work that genuinely finished is not silently erased, but a cancellation is not converted into a clean completion merely because a lower layer swallowed the exception.
That is a more demanding reliability claim than “the output validated.” The question is not only whether an agent asked a tool for a well-formed action. It is whether the orchestration layer can still tell an operator that a request was interrupted, which cleanup belongs in a try/finally wrapper, and what history is safe to resume.
The project is careful about its own remedy
PydanticAI’s follow-up #6768 is unusually useful reporting material because it narrows the claim rather than inflating it. The helper looks at Python’s pending-cancellation count on Python 3.11 and later. The maintainers call that a policy signal, not proof of why the task was cancelled: code that uses an older self-cancellation idiom and suppresses the exception without balancing the state can be read as a cancelled run. On Python 3.10, the project documents that this particular detection is a no-op. In a Trio-backed context, it now avoids assuming an asyncio task exists.
That caveat is the lesson. Good agent infrastructure does not turn an implementation heuristic into a universal safety theorem. It names the rule, the false-positive edge, the runtime boundary, and the cleanup behavior that changes because of it.
A test for the awkward path
The next change, #6767, adds a Temporal-oriented integration test for the awkward case. Its streaming model activity catches a cancellation and yields a completion-like response anyway. The test is written to require that the workflow end cancelled and that its captured history replay deterministically. That is not a production certificate; it is a public statement of the edge the framework now intends to keep from regressing.
For builders, the transferable practice is to separate three contracts that are often collapsed into one “reliability” claim: validate what crosses an interface; record what has completed; and preserve the control signal that says no more work should follow. A schema is strong at the first job. The cancellation series shows why it cannot do the other two alone.
PydanticAI’s durable-execution docs already frame the project around long-running and fault-tolerant workflows. The next signal worth watching is not a headline about type safety. It is whether future public releases and runtime tests carry this same distinction across more providers and cancellation paths: a system can know the shape of an action and still need to prove that it stopped acting.