Pi Durable lets AI agents resume work, but tools still need replay rules

Earendil released Pi Durable with Pi 1.0 on October 1, 2026, describing it as an experimental framework for long-running agent applications. The package is designed to reopen unfinished work after a process dies, a container is redeployed or a machine loses its process.

The useful distinction is between a saved conversation and a recoverable workflow. A transcript can show what a model said, but it cannot by itself prove whether a payment, deployment, email or ticket update reached an outside system. Pi Durable adds checkpoints, task ownership and application documents to that problem. It still leaves the application responsible for replay safety and reconciliation.

Why conversation history is not enough

An agent application normally holds at least three kinds of state. The transcript records user messages, model responses and tool results. The task state records which stage is running, waiting or retrying. The application state holds business objects such as a plan, ticket, file location or order. A process can save one of these and lose the others.

Consider an agent that creates a cloud resource and then writes its identifier to a document. If the process stops between those operations, the transcript may contain the request while the application lacks a reliable status. The reverse can also happen: the cloud resource exists, but the conversation has no committed result. On restart, reading the transcript does not tell the application whether to retry, query the provider or ask for human review.

The official README defines a durable task as a state machine that saves a checkpoint at each step and describes conversations, model turns, tool calls and application documents as committed work. That grouping is intended to keep the framework's own record consistent. It is not a rollback mechanism for every system the tools can reach.

How Pi Durable resumes an interrupted run

Pi Durable treats model requests, tool calls and custom work as tasks. Before moving to the next step, the harness commits a checkpoint. A new process opens the same storage and resumes pending work from the last committed position. A model request interrupted during generation is sent again, while its partial response remains in the transcript as aborted.

Tool calls follow a stricter rule. The README says a tool's intent is committed before execution and that an interrupted call runs again only when the tool is declared replay: "safe"; otherwise the model receives an interrupted result. That default makes the developer confront the cost of repeating the operation.

A read-only query is often easier to replay than an email, payment, deployment or account change. Even a read operation can have side effects if it consumes a one-time token or triggers billing, so the label requires an application-level decision. Safe replay normally means that repeating the request produces the same externally useful result, or that the target service can identify and discard a duplicate.

Useful controls include an idempotency key, a durable operation identifier, a query for the outside system's current status and a compensation path for actions that cannot be undone. If the provider completed the action but the process died before storing its response, the application should discover that fact before issuing another request. Handing the ambiguity back to a model is not a transaction guarantee.

Storage choices determine what survives

Pi Durable supports storage backends with different failure boundaries. Memory storage is suitable for a demonstration or a test and disappears with the process. The documented SQLite backend uses one database file, while JSONL writes append-only files to a directory. Both can preserve state across a process restart if the next process opens the same location.

The storage table says SQLite commits survive process crashes with its stated write-ahead logging settings, while the JSONL backend can use an fsync option before each commit marker. The same section warns that the newest data may be lost after a power or host failure under the SQLite settings. A team should therefore test the failure mode it actually needs rather than treating the word durable as a universal durability level.

The README also states that one process owns a storage at a time and does not provide cross-process locking. That matters in a container platform where two replicas can see the same file or database. A deployment needs an ownership model, a lease or a single scheduler, depending on the backend and environment. A persistent file mounted into two containers is not automatically a safe shared work queue.

Application documents add another boundary. Typed JSON documents can sit beside the transcript and change in the same atomic commit inside the harness. They can keep a task list or plan aligned with the conversation, but they do not make a separate customer relationship management database, payment service or cloud control plane part of that commit.

Pi Durable compared with a basic retry loop

A basic agent workflow can save messages, put jobs in a queue and retry a failed request. That may be enough when input can be fetched again, work takes seconds and repeated execution is harmless. The team still needs to record the job state and decide how to inspect an uncertain result, but a full durable harness may add more moving parts than value.

Pi Durable becomes more relevant when a run spans human approval, a long external wait, several model turns or a deployment boundary. Its task model gives the application a place to resume a partial run instead of reconstructing the next step from prose. Its documents can keep an agent's working state close to the transcript. Neither feature removes the need for a queue, monitoring, access control or an incident procedure.

The comparison is about responsibility, not a claim that ordinary agent frameworks cannot recover. Teams can implement checkpoints and replay rules in an existing service. Pi Durable packages those ideas around a conversation, task scheduler and document model. The right question is whether the package's conventions reduce the specific recovery work that the application already has to maintain.

How this plays out outside Taiwan

Pi Durable is a software package rather than a regional service. The official installation command downloads @earendil-works/pi-durable and related packages through npm, and the README describes adapters that can run in Node, Bun or Cloudflare Durable Objects. The package itself does not publish a country-specific subscription price, capacity promise or data-residency region. The cost of a real deployment comes from the model provider, compute, storage, network traffic, monitoring and any tool service the application calls. Those prices and regional terms must be checked with each provider on the day of deployment.

For a US team, the first practical question is what the agent stores in its SQLite file, JSONL directory or remote database. Customer names, support transcripts, employee records and identifiers can move into the transcript through prompts, tool output or logs even when the developer intended to save only a task status. US Federal Trade Commission business guidance recommends identifying the personal information held, limiting access, protecting it in transit and at rest, and disposing of it securely when it is no longer needed. That guidance does not approve Pi Durable or decide whether a particular deployment complies with a US law. A US operator still has to identify the states, sectors, contracts and breach duties that apply to its data, then configure retention and access controls accordingly.

A UK deployment has a more direct operational checklist. The UK Information Commissioner's Office describes security as an appropriate technical and organizational measures obligation under the UK General Data Protection Regulation. The ICO's data-security guidance points organizations toward policies, access controls, monitoring, resilience and breach preparation. For Pi Durable, that means deciding whether a transcript and its application documents are personal-data stores, restricting who can reopen a conversation, documenting the model and tool subprocessors, and testing deletion rather than assuming that deleting a visible conversation also removes backups, logs or provider-side copies. If an agent sends personal data to a model API or a third-party tool, the controller and processor arrangements need review outside the package documentation.

Singapore operators should map the same data path against the Personal Data Protection Act. Singapore's Personal Data Protection Commission says the Protection Obligation requires reasonable security arrangements for personal data in an organization's possession or control, including protection against unauthorized access, use, disclosure, modification and disposal. A durable agent makes the mapping concrete: the persistent store, the execution environment, model requests, tool results, crash dumps and support exports are separate places to inspect. A Singapore team should ask its storage and model vendors where those records are processed, how long they remain, how access is logged and how a compromised tool is disabled. The PDPC guidance is the authority to consult for the organization's facts; Pi Durable's checkpoint feature is not a substitute for that assessment.

Australian teams face a similar distinction between recovery and security. The Office of the Australian Information Commissioner says Australian Privacy Principle 11 requires reasonable steps to protect personal information from misuse, interference, loss and unauthorized access, modification or disclosure, and to destroy or de-identify it when no longer needed. A durable transcript can increase the number of copies and the retention period, especially when an agent forks a conversation or preserves tool output for a later retry. The design review should therefore ask what must be retained for recovery, what can be redacted before persistence, who can trigger resume, and how a deletion request reaches every copy. The OAIC's current guidance should be checked against the organization's sector and cross-border arrangements before launch.

Across these markets, the availability decision is less about whether npm can download the package and more about whether the selected model and tools can be used under the organization's data and contractual constraints. A team can run the harness locally or in a cloud environment, but it still needs to verify the model's supported countries, service limits, training-use terms, retention controls and incident process. Those details are not established by Pi Durable's open-source license or by the presence of a SQLite adapter. A useful pilot records the country, provider account, storage location, subprocessors, data classes, replay policy and deletion test alongside the recovery test.

What to test before adopting it

Start with one workflow that currently causes expensive rework after an interruption. Record the transcript entries, task stages, business documents and outside operations that must survive. Then classify every tool as read-only, idempotent, deduplicated, human-confirmed or unsafe to replay.

Stop the process at several precise points: during model generation, before a tool starts, after an outside write completes but before its result is committed, after a document commit and while storage is unavailable. On restart, check whether the agent repeats an operation, loses a result, creates conflicting documents or waits for an owner that no longer exists.

Test deployment changes as well. The stored conversation refers to extension and tool names, not a frozen copy of the whole program. A renamed tool, changed input schema or new document version can leave an old task without a compatible implementation. Keep a migration policy, pin versions for the pilot and define who can stop or manually repair a run.

The official materials call Pi Durable experimental and warn that its API can change between releases. That makes a small isolated trial more appropriate than an assumption that the framework is a production standard. The trial should measure recovery time, duplicate operations, storage growth, operator work and the effort required to upgrade or roll back.

Bottom line: restore state, then verify the outside world

Pi Durable addresses a real gap in agent applications: a saved conversation is not the same thing as a saved workflow. Its checkpoints, task ownership and typed documents give a restarted process more context than a transcript alone. The package is most promising for work that waits, spans multiple stages or has a high cost of reconstruction.

Its boundary is just as important. The framework cannot know whether a payment went through, whether a deployment finished or whether a model provider stored a prompt outside the application's chosen region. Before adoption, teams should design replay keys, status checks, human escalation and deletion controls for the systems beyond the harness. A recovery test is successful only when the resumed agent can identify the actual external state and take the next safe action.

Frequently asked questions

Is Pi Durable the Pi coding agent?
No. Earendil describes Pi Durable as a framework for building agent applications. It is a separate package and does not replace the Pi coding agent.

Will every interrupted tool run again?
No. Only a tool explicitly marked safe to replay runs automatically after an interruption. Other calls produce an interrupted result for the model or application to handle.

Where does Pi Durable store work?
The documented choices include memory, SQLite and JSONL. Memory ends with the process; SQLite and JSONL can support recovery when the next process opens the same persistent location and the deployment satisfies the backend's ownership and failure limits.

Does Pi Durable provide exactly-once behavior for outside services?
No. A request identifier can prevent duplicate submission within the harness, but payment, email, deployment and database behavior still needs idempotency or result reconciliation in the target service.

Is it ready as a general production standard?
Not on the published evidence. The official README labels it experimental and warns that the API can change. Each team needs to test its own storage, model provider, tools, deployment and recovery requirements.