Pi Agent Desktop

The deciding trait is how much you get asked. Three modes let you keep the agent thinking, answering or acting, every tool call can be confirmed, and a project has to be trusted before anything happens in it. That is a lot of small gates, and for work on a repository you cannot afford to break they are exactly the right amount of friction.

For rapid exploration they are simply in the way. Pick it when the repository matters more than the pace. Pick a plain session when you would rather approve nothing and read the diff instead.

Persistent memory is the feature that ages badly. Facts written months ago about a codebase that has since changed stay retrievable and stay authoritative, and the documentation describes how the store is indexed without describing how anything gets removed from it or marked wrong. A confidently stale recollection is worse than none, because nobody thinks to check it.

What it does right is scope the store per project. A wrong belief about one repository does not follow you into the next.

1. Default full-text tokenisers split on whitespace and therefore fail almost completely on languages that do not use it, which makes this a retrieval decision with a real effect on recall rather than a configuration detail. 2. Choosing a trigram index accepts a larger store and slower writes in exchange for substring matching that works without a language-specific segmenter.

2. The trade is stated implicitly and never measured: no figures are published for recall, latency or index size against the alternative. The reasoning is sound and the result is unreported.

The dependency is total and one-directional. What this adds is presentation over an agent it does not control, which means a change in that agent's interface arrives here as breakage and a new feature there arrives here as work. The upstream project has no obligation to either, and no relationship exists that would create one.

Moat: none; the upstream authors could ship their own desktop client in a weekend. Likely path: exactly that, or steady personal maintenance. Position: use it, and keep the underlying agent installed independently.

Packaging decides adoption more often than features do. Signed installers for every platform my fleet runs means my desktop team ships this the way they ship everything else, instead of writing a build guide that half the engineers will get wrong. That is genuinely the difference between a pilot and a memo.

Everything after installation is unmanaged. No directory login, no central configuration, no audit trail and nothing that runs unattended, so I get sixty independent copies with sixty sets of settings. Approved with conditions: packaged centrally, and no shared project databases.

Two scopes for tool servers is the configuration I want and rarely see. The ones I run everywhere are declared once, and a repository that needs something specific declares it beside the code, so I am not maintaining one enormous global file that half my projects ignore.

Cloning a session into a worktree is the other good detail: I can take a conversation that went somewhere interesting and branch it without losing the original. Permissive licence, so a fork stays legal, though inference always ends up on somebody else's hardware.