Long-running agent workflows should save progress so crashes do not force users to restart from the beginning.
2
PydanticAI's Temporal integration adds durable execution around existing agent code, including LLM calls and tool calls.
3
A deep research system can be composed from smaller agents, with parallel searches, Logfire tracing, and evals for comparing model behavior.
Summary
Samuel Colvin demonstrates how stateless agent programs lose expensive work when a process, endpoint, or Kubernetes workload fails. He starts with a 20 Questions example and shows how Temporal records activity inputs and outputs, retries failed activities, and replays completed work without repeating the underlying LLM calls. The agent code remains ordinary Python, including parallel execution with task groups. He then applies the same approach to a deep research workflow made from planning, search, and analysis agents. PydanticAI wraps the agents for Temporal execution, while Pydantic Logfire exposes the workflow, individual searches, prompts, and costs. Colvin also uses Pydantic Evals to compare models, while showing how a misleading evaluation can make Gemini look better because the test did not check whether its answers were correct. The talk is a practical demonstration of where durable execution fits and where the implementation still has rough edges.
Short agent calls do not need durable execution, but long workflows do
Colvin says a simple question-and-answer call usually works without durable execution. The problem begins when an agent has spent substantial time or compute on a long task. If an endpoint fails or Kubernetes kills the process, a stateless program has to start again. His 20 Questions demo makes the cost visible: the agents may need up to around 50 steps to identify the object, and losing the run means repeating every step. He connects this directly to deep research, where web searches and retrieval calls become the intermediate steps of a much longer agent task.
Temporal separates deterministic workflow code from external activities
Temporal requires workflows to be deterministic, while activities handle nondeterministic operations such as I/O. The system records each activity, including its inputs and outputs. When the workflow is replayed, Temporal supplies the recorded results instead of making the same external calls again. PydanticAI's Temporal agent wrapper turns the I/O involved in LLM calls and tool calls into activities. Colvin says this lets the surrounding workflow remain ordinary procedural Python, with the durable behavior added around the agents.
Retries and replay let an agent survive process failure
In the 20 Questions demo, Colvin deliberately makes a tool fail intermittently. Temporal retries the failed activity and keeps the workflow moving. He then kills the running process and resumes the existing workflow by its ID. The workflow jumps ahead to the point it had reached without adding resume logic to the agent itself. Logfire shows that previously completed LLM calls return in milliseconds because Temporal replays their stored results. Only the unfinished activity needs to run again.
Observability exposes the actual cost and behavior of an agent run
Logfire shows the workflow at several levels. Colvin can inspect the top-level workflow, the Claude calls inside it, and the activity that runs another agent. In the replayed run, the traces make clear which calls were served from Temporal's recorded results and which call continued to the model. This matters because an agent can appear to resume successfully while still having confusing model behavior. In the demo, the questioner identifies that the object is related to food, then gets stuck considering whether it is a salad bowl.
An evaluation can reward a faster model for the wrong reason
Colvin compares GPT-4.1, Gemini, and Claude Sonnet 4.5 with Pydantic Evals. The displayed results include pass or fail assertions, average cost, and the number of questions needed. Gemini appears cheaper, faster, and more successful in the initial results. After checking the cases, Colvin discovers that Gemini was often producing an invented answer that was wrong, because the evaluation did not verify correctness. The example shows why cost and speed metrics need assertions that test the actual outcome.
Deep research is built from several smaller agents
Colvin's deep research example has a planning agent, a set of search agents, and a final analysis agent. The planner returns structured data containing an executive summary, up to five web search steps, and analysis instructions. Search agents run in parallel, using a faster model, and the analysis agent combines their results into a report. He describes agents as smaller development units that can be composed into a larger task. The workflow does not need a graph for this level of complexity because its steps are straightforward.
Durable execution can be added without rewriting the workflow
The durable deep research version wraps the agents in Temporal agents and adds the required plugins and workflow setup. The body of the workflow still uses Python task groups for parallel searches, and Colvin says async gathering would work too. If a process dies after the searches finish, Temporal replays the plan and search activities from their recorded outputs. Those results return immediately, while an analysis activity that had not completed must run again. The code keeps the same imperative shape while Temporal handles persistence and recovery.
The final analysis remains the expensive part after a restart
When Colvin restarts the durable deep research workflow, the plan takes milliseconds and the completed searches take almost no time because their results already exist in Temporal. The analysis step starts again because it was the activity that had not finished. This makes the recovery behavior concrete: completed work is preserved at activity boundaries, while incomplete work is retried from its beginning. The resulting report compares Python agent frameworks and includes an executive summary and links, although Colvin notes that a usable deep research interface would still require UI work.
"I discovered subsequently having checked the results that actually the reason Gemini is way faster and answers much more quickly is it just invents an answer that's wrong and I wasn't checking it."11:56
Who should watch
You are building agents that run long enough for a crash to waste meaningful compute or user time.
Your current recovery plan is to rerun an entire agent workflow after a worker or Kubernetes process dies.
You need traces and evaluations that show which model calls ran, what they cost, and whether a fast answer was actually correct.
