# Pi Durable EXPLAINED: Build Always-On Agents with Local Models

## Executive summary

Pi Durable is a specialized building block designed for creating reliable, always-on agent applications. Unlike the standard Pi coding agent, Pi Durable ensures that long-running tasks can survive crashes and interruptions by utilizing persistent state management, checkpoints, and dedicated storage (e.g., SQLite). It functions as a replacement for the core Pi harness, allowing developers to build custom agents powered by local models (like Qwen3.5-0.8B) that operate reliably in background environments (daemons).

## Key takeaways

- Pi Durable is a Building Block, Not an Application: Pi Durable is not a CLI or a complete application like the Pi coding agent. It is a harness class designed to power custom, always-on agents that are meant to run in the background (e.g., via a daemon or system service).
- Crash Recovery and Persistence: The core function of Pi Durable is to provide reliable checkpoints for every operation. If an agent process crashes, the system can restart it and resume the task exactly where it left off, even if the interruption occurred during a sensitive tool call.
- Architecture and Components: Pi Durable fits into the Pi ecosystem by replacing the Pi harness. It relies on the Pi AI package for model integration and requires a persistent storage backend (SQLite is recommended for production, though JSONL and memory are supported).

## Technical details

- Pi Durable vs. Pi Coding Agent: The standard Pi coding agent stores sessions in JSONL files, which are vulnerable to incomplete tool calls upon crash. Pi Durable, conversely, stores tasks with multiple checkpoints in a persistent storage system (like SQLite), ensuring the agent can resume state reliably without manual intervention.
- Harness Initialization Steps: To initialize a Durable Harness instance, the process involves six key steps: 1) Importing/configuring models (e.g., using a llama provider); 2) Importing/opening the registry (to encapsulate tools and extensions, such as the coding agent tools); 3) Setting up storage (SQLite is recommended); 4) Opening the harness; 5) Creating or retrieving a conversation (which acts like a session); and 6) Submitting the query/task.
- API Interaction and State Management: When submitting a query, the process must await a response, which allows the application to handle the task asynchronously. The submission returns a submission ID, which can be used to check the task status. For interactive chat applications, events can be streamed.

## Practical implications

- Build engineers can create robust, always-on AI agents that function reliably in non-interactive environments (e.g., via Slack, Telegram, or email gateways).
- The architecture allows for decoupling the agent logic from the user interface, making the agent resilient to process interruptions.
- The use of SQLite storage enables the persistence of agent state and conversation history across restarts, which is critical for long-running background jobs.

## Topics

Agent Architecture, Crash Recovery, Persistent State Management, Harness Design, Local LLM Integration (llama.cpp), Tutorial companion code (fresh chat and restart recovery), Pi Durable introduction, Pi source code, Qwen3.5-0.8B

Source: https://www.youtube.com/watch?v=ti3vVYwzW4A