Understanding Pi Durable with Mario & Armin of Earendil

Pi creator Mario Zechner and Earendil co-founder Armin Ronacher join Fragmented host Kaushik Gopal to explain Pi Durable, an experimental library for agents that must resume after their process stops. Its central design stores work as explicit tasks, so recovery can account for unfinished model requests, tool calls, and application work rather than only restoring a conversation.

Based on the video's English auto-generated captions, which contain transcription errors. This is a summary of the creators' design explanations and experience, not an independent reliability or security evaluation.

Why a separate durable harness?

• Long-running agents need to recover without a person typing "continue." A harness is the software that coordinates model requests, tools, and agent state. Pi's original design suits interactive coding sessions where a developer can intervene. Pi Durable targets agents that must keep working across process interruptions, including cloud environments that provide only temporary compute. A new process reloads saved state and resumes unfinished work; the original process does not have to survive. The separate design also lets the team experiment without disrupting Pi 1.0's established extension APIs. 09:08–13:04(opens in a new tab), 22:07–23:50(opens in a new tab)
• Recovery uses explicit task phases. A model request, a tool call, or application work such as indexing messages can be represented as a task. The harness records what it intends to do, performs the operation, then records the result. If it restarts with an intent but no result, it knows which work is unresolved, though it may not know whether the external operation already happened. In the speakers' comparison, replay-based workflows revisit earlier checkpoints, reusing saved results to reconstruct where execution stopped. Pi Durable instead records the task's current phase explicitly. Their preference is for explicit transitions that are easier to reason about when changing code, not a claim that Temporal cannot run agents. 13:04–19:29(opens in a new tab)
• An interrupted tool call is not always safe to repeat. A file read can run again without changing the file, even if its contents have changed since the first attempt. A tool can be marked replay-safe on that basis. An arbitrary shell command is different: repeating a deployment or destructive command could cause another external change. For an interrupted shell call, the harness tells the model what happened and asks it to inspect the environment before deciding what to do. Resuming an agent therefore does not guarantee that every external operation happens exactly once or that recovery decisions are infallible. 20:18–23:50(opens in a new tab)
• Parent-child task ownership connects recovery across subagents. When a main agent waits on a tool that starts another conversation, the harness can track that conversation's work as part of the same ownership tree. After a crash, it can identify unfinished child work as well as the parent's waiting task. Applications can also use the scheduler for their own tasks, keeping saved application data connected to execution progress. This supplies building blocks for subagents; it does not include a ready-made subagent communication system. 23:50–26:33(opens in a new tab), 30:35–32:28(opens in a new tab)

Shared sessions need more than crash recovery

• Watches and an inbox support multiple clients. A watch streams changes in the agent's state so connected clients can update their displays without receiving the entire state each time. Client inputs enter an inbox, which the harness reads at safe points in execution. Pi Durable provides these mechanisms, not a complete multiplayer server and client. The original Pi could support remote interfaces too, but was not designed around them. 33:23–35:29(opens in a new tab)
• Plugin upgrades and plugin trust are separate problems. The speakers describe Chord, an experimental networked plugin system, validating a new plugin set against versioned interfaces and state schemas while the old set remains active. Affected in-flight calls finish before replacement. That does not solve the trust problem: a server-supplied plugin running in a local Node.js terminal client could access local files or credentials. A local Node.js client does not inherit the browser's sandbox; it needs its own code isolation. They explicitly say the plugin work is not yet battle-tested. 35:29–40:49(opens in a new tab)

Extensibility still needs constraints

• Codemode made MCP a more useful fit for Pi. Codemode lets the model express tool use through JavaScript, including workflows that call other kinds of models, such as classifiers. Once that runtime existed, integrating Model Context Protocol (MCP) services became easier. MCP also supplies established service connections and authentication. The speakers still want stricter return types: text meant only for the language model is harder for a program to transform reliably. Their position is selective support, not an endorsement of every MCP design choice. 04:27–08:06(opens in a new tab)
• Hot reload enables modification, not proof of improvement. Pi Durable's extensions bundle prompt contributions, tools, and hooks that can be replaced while the harness runs. But an agent that rewrites its harness still needs a measurable goal and constraints on what must remain intact. Mario recalls asking an agent to speed up Pi startup: it removed functionality and left a fast shell. Armin argues that unconstrained rewrites can also destroy the structure needed to debug the system or connect a user interface. 40:49–46:10(opens in a new tab)
• Narrow optimization is easier to validate than a general harness rewrite. Mario contrasts open-ended self-improvement with optimizing an inference kernel, the GPU code used to run a model, where existing input-output tests and performance measurements provide a clearer check. The question is whether the evaluator measures the intended improvement while preserving required behavior. The speakers remain interested in self-improvement experiments but do not establish that they generalize beyond their optimization target. 44:26–49:41(opens in a new tab)

Full video: https://www.youtube.com/watch?v=7mBQknCnovM(opens in a new tab)

Publisher's show notes: https://fragmentedpodcast.com/episodes/312/(opens in a new tab)