Pi Durable: Agents That Survive Crashes — Mario Zechner & Armin Ronacher

Mario Zechner and Armin Ronacher discuss Pi Durable with 0xSero: infrastructure intended to let agents resume after process crashes without a person typing “continue.” The design combines recoverable tasks with persisted application state, while addressing the limits of keeping years of conversation history in memory. 19:58–21:41(opens in a new tab) This is the builders' explanation of their design, not an independent reliability test.

Based on the saved English caption track, recorded by the capture tool as caption. The original audio and implementation were not independently checked.

How crash recovery works

• Persist the work around the operation that can fail. Zechner describes an “effect sandwich”: save the intent and evaluated inputs, execute an operation such as an LLM request or tool call, then save its result. A crash before execution leaves enough information to attempt the operation; a persisted result records completed work. In Pi Durable, these units are tasks, and one task can spawn another and wait for it. He explicitly says this is not an event-sourcing design, but does not establish that other durability systems cannot provide equivalent recovery. 22:28–26:54(opens in a new tab)
• A saved intent does not make every external action safe to repeat. If a process dies after sending a request but before saving the reply, it may not know whether the external system acted. Zechner explains idempotency through an operation ID saved before execution: if the receiving system recognizes that ID on a retry, it can return or wait for the existing operation instead of starting another. This depends on support from that system. File deletion and charging a credit card illustrate why irreversible or duplicate effects need deliberate handling; persistence alone does not resolve them. 23:17–26:05(opens in a new tab)
• Application state needs its own history semantics. Their document store holds JSON-like objects alongside the conversation. A to-do list or drawing can follow the version associated with an earlier conversation position, while another kind of document can expose its latest value regardless of that position. The distinction lets an application decide what “go back” means for its state, rather than restoring only chat text. 26:54–28:42(opens in a new tab) Changes are recorded through JavaScript proxies—objects that intercept assignments such as setting a field—and a custom patch format. They acknowledge performance costs and pitfalls rather than presenting this as a general solution for every application. 28:42–31:15(opens in a new tab)
• The goal is reusable recovery without human supervision. They acknowledge that existing agent products already solve durability in their own ways, and that developers can build it themselves. Their reason for extracting Pi Durable is the repeated design work needed to make agents recover reliably across projects, especially when no person is watching. This is infrastructure for more predictable orchestration, not a claim that the LLM itself becomes predictable. 32:03–34:39(opens in a new tab)

Engineering lessons beyond persistence

• Delegate within a designed boundary. Zechner says he hand-designed Pi's terminal-UI foundation, then had agents build components against its API with rendering tests. He is comfortable leaving those implementations unread until issues such as performance require attention. His concern is that an agent may fix one slow case without identifying the architectural cause. This is a selective delegation practice, not a blanket rejection of agent-written code. 05:09–07:49(opens in a new tab)
• Executable feedback makes iteration easier than judging architecture. The speakers point to test suites and fuzzing—trying many inputs to uncover failures—as useful feedback for agent implementation and repair. Their architecture discussion is more qualified: models can help reason about designs, but autonomous implementation may head elsewhere, and identifying which design conversations led to a good outcome is difficult. Their explanation about missing or hard-to-label training examples is a hypothesis, not verified knowledge of model-training pipelines. 13:08–18:13(opens in a new tab)
• Shared agent interfaces create a browser-side trust problem. Ronacher distinguishes protecting a server from protecting people who join an extensible web session. An agent-generated interface could contain cross-site scripting (XSS): code that runs in a user's browser context and could steal cookies or other data. They discuss iframe isolation and its user-experience costs; a server container alone does not address the browser problem they describe. This is an unresolved design discussion, not a demonstrated secure multiplayer implementation. 48:36–51:12(opens in a new tab)

Direction, not a release promise: Zechner describes an internal phone-based prototype used to exercise Pi Durable, with remote machines available as execution environments. Their intended evolution is from one person and one agent toward multiple agents, machines, and people collaborating. The prototype is not presented as a planned public release, and the plugin and shared-interface design remains exploratory. 45:57–48:36(opens in a new tab)