A Durable Agent Workspace—With Limits

PI-Desktop is best judged against the question that opened this series: can a local coding agent remain useful over time without becoming opaque or unbounded? This final synthesis connects its project/session model, host authority, tool boundaries, contracts, recovery mechanisms, providers, and extensions, then turns that model into a conditional adoption judgment. The answer is substantial but not absolute: PI-Desktop has a coherent design for durable, inspectable local work, while its preview status and unfinished trust boundaries matter to anyone choosing it for serious use.

One design: capability with an accountable boundary

PI-Desktop's pieces make sense when read as a chain of accountability. A project gives the work a place. A session gives it identity and continuity. The pi Agent supplies model reasoning and turn orchestration. Host-core decides whether a proposed local operation may happen, where it may happen, and how its result is recorded. The transcript preserves the user's history, while checkpoints keep the model's future requests within finite context. The work panel makes selected results easier to inspect without becoming a second, competing source of truth.

That chain is more meaningful than a collection of familiar features. Many tools can let a model read a file or run a command. PI-Desktop's distinctive choice is to attach each capability to a session and then make the boundary around that session explicit. If the developer switches from repository A to repository B while work continues in A, the session identity keeps the Agent's tool root in A. If an edit succeeds, the review evidence belongs to the message and session that created it. If the model requests more authority, a host policy and a user decision stand between the request and the operation.

The same logic separates intent from execution. Agent mode is free execution under the selected permission posture. Plan and Goal are contract states of the same Agent: Plan makes an ordered path reviewable, while Goal makes an outcome, acceptance criteria, and boundaries reviewable. The host writes the submitted Markdown to an immutable artifact and only then creates an approval record. Approval changes the durable session to Agent and queues execution with an explicit permission mode. Rejection, expiry, stale identity, persistence failure, and restart do not quietly become approval.

This is why the product's most important control is not a stop button or a permission dialog in isolation. It is the fact that the host owns the transition that would grant execution. The renderer can display a pending proposal, and the sidecar can describe what it wants to do, but neither can replace the artifact or make a mismatched response authoritative. Once execution begins, ordinary tools still pass through path, permission, timeout, audit, and review rules. The approval boundary is a gate into execution, not a promise that every action afterward is automatically wise.

Continuity follows the same pattern. The transcript is durable user data; the model context is a bounded reconstruction of that data; panel tabs and embedded resources are transient interface state. The distinction lets PI-Desktop preserve a complete visible history while compacting what the next provider request receives. It can retain the last saved portion of a streaming reply without claiming that an interrupted tool completed. It can hold a queued prompt for a controller without starting it autonomously after a restart. It can return a Subagent's conclusion without replaying all the intermediate work into the parent's context.

The result is a particular kind of local agency. The Agent can work for a long time, but it does not own the definition of “long time.” Context boundaries, process recovery, queue admission, and approval transitions determine what continues. The user can reduce interruption with an automatic permission mode, but that choice remains a meaningful increase in authority. The product can preserve history across a restart, but it deliberately refuses to replay uncertain execution. Capability and continuity are both useful because they are bounded by conditions that the system can name.

That design also reveals a cost. Every boundary creates coordination work. The renderer, Main process, sidecar, and host must agree on typed contracts. Storage must keep a payload and its index consistent. A review record must not overwrite a newer file. An approval must match the right session and turn. A context checkpoint must be small enough before it is installed. This is more elaborate than putting a model loop and a shell in one process. The complexity is not accidental overhead; it is the price of making the product's control claim testable.

Replace the model, not the workflow

PI-Desktop's provider strategy extends the same separation to model choice. The workflow—project, session, tools, review, approval, and persistence—should not have to be rebuilt whenever the model changes. Native pi-ai adapters cover major vendors. An OpenAI-compatible path covers gateways, local servers, corporate proxies, and vendors that do not have a dedicated adapter. Custom provider definitions cover endpoints that need their own URL, headers, or protocol profile.

The practical benefit is optionality. A developer can use a hosted model for a difficult reasoning task, a local gateway for sensitive or offline work, or a compatible service for a specialized cost or latency trade-off. A session binds to a provider/model pair, and changing that choice applies to later turns rather than silently changing the request already in flight.