Mario Zechner and Armin Ronacher talk through Pi Durable, a new release of the Pi agent harness that lets an agent survive a process crash and pick up exactly where it left off. Mario explains the design in detail: instead of event sourcing, everything in the harness is an "effect sandwich" (record intent → run the effect, ideally idempotently → persist the result), paired with a small versioned document store for application state that can be rewound alongside the conversation. The rest of the conversation covers where coding models have genuinely gotten better (anything with an oracle: tests, fuzzing, emulators, reverse engineering) versus where they haven't (architecture, because the act of designing software was never written down to train on), plus Earendil's plans to build non-coding-agent products and the unsolved security problems of extensible web UIs for agents.
- Pi Durable's core promise: if the process dies, you restart it and the agent continues from exactly where it stopped, with no lost tool results or streamed output and no need to type "continue" — essential for long-running agents like Slack bots that live for years.
- It also removes Pi's old limitation of loading the entire conversation tree into memory, which breaks down once an agent accumulates years of history.
- The architecture deliberately avoids event sourcing. Every operation is a task shaped as an "effect sandwich": persist the intent and inputs, execute the effect (using idempotency keys when the external system supports them, as with GitHub Actions), then persist the result. Tasks can spawn and await other tasks, and that nesting is the whole mechanism.
- Application state lives in a small custom document store where documents are versioned against positions in the transcript, so rewinding the conversation can either restore the old version of a to-do list or drawing, or keep the latest — you choose per document. They rejected JSON Patch as too generic and use a JavaScript proxy to record mutations.
- Both agree models have improved dramatically wherever an oracle exists — test suites, fuzzing, emulator ports, reverse engineering — but not at architecture. Mario's explanation: cyber, front-end and reimplementation tasks all have abundant training data, while the process of designing and architecting software is almost never written down anywhere.
- Mario describes a model reverse-engineering the native memory structures inside a JVM to read bytecode out of process memory, bypassing protections he believed no human reverser would have broken; Armin similarly had a model crack a Chinese CarPlay dongle's firmware protection unaided.
- Pi Durable is roughly 12,000 lines and deploys to Vercel, Cloudflare Durable Objects, E2B, a laptop or a phone. Mario has already built "PIM", a phone-first Pi that runs everything locally except the LLM and can use remote machines as execution environments.
- Earendil's stated direction is products that are not coding agents, plus infrastructure others can build agents on; the hardest open problems they name are multiplayer/shared sessions, secure extensible web plugin UIs (XSS and cookie exfiltration, iframes ruining UX), and onboarding non-engineers who don't yet have the instinct to just ask the model.
The clearest, most compact statement of what Pi Durable actually does and why long-running agents need it.
Agent starts up in a process, agent calls tools, process dies. What you want is restart the process, agent continues exactly from where it left off. That is durability.
A concrete, falsifiable explanation for the one capability gap both builders keep running into, framed as a data problem rather than a model problem.
What I don't have training data for is the process of building, of designing and architecting something. That is the only part in programming that is actually not usually encoded somewhere in textual form so an LLM can learn from it. And that's why we are stuck here.
If you have an oracle that can tell the LLM if what it did is correct or not, then you basically won.
It will definitely solve the problem, but it's almost impossible that it will fix a problem without adding code.
Everybody gives you a chat box and a sidebar and then good luck motherfucker, figure it out.