Designing an AI companion
you can actually trust.

The most important product decision was not to press relationship and tool use into one universal chat.

Presence is the personal room. The companion answers with a stance of its own, carries one of twelve ambient moods and gives individual messages a matching expression. Earlier conversations stay findable without dominating the entry surface.

Focused areas take the deep work. Research, transcription, calendar, notes or media each have a clearly bounded context and exactly the tools they need. The encapsulation protects both sides: presence never becomes a command line, and a workspace never has to pretend to be a private conversation.

The first layer of trust still sits in the interface: the model actually used and where that choice came from are visible, proactive content carries a recognisable origin, research and meeting results declare sources, partial failures and incomplete runs, and anything with outside effect is prepared or confirmed rather than done in passing.

One formative example was a calendar answer in which the model invented an appointment. The consequence was not another warning banner but a harder product rule: calendar answers may only be built from the calendar data actually loaded. If an entry is missing, an honest “not found” is the correct answer.

In operation a second, more important layer appeared: the system must not do certain things at all when scope, consent or run state are missing. Providers are optional connections; a stored API key is not consent for background access. Visible automation has its own pause, target, budget and delivery limits. Run states are traceable as run, attempt, event, reservation and receipt, so a retry cannot repeat the same outside effect.

The new automation control plane is switched on in stages. Today only a persisting pilot runs, without visible delivery; broader autonomy stays closed until its operational and recovery gates are proven. That restraint is part of the design, not missing ambition.

Nyx and Nadir share frontend, backend and product patterns, but they are not two skins on one account. Nyx runs as a private, self-hosted owner edition. Nadir ships as a macOS app with a bundled Python sidecar; the local service binds to the machine it runs on, and data, settings and the chosen vault stay with that installation.

A static edition profile decides which backend modules, routes and surfaces exist at all. Build and bundle checks keep private Nyx content out of Nadir on top of that. And Nadir brings its own companion identities, Helios and Selene, instead of copying Nyx. That turned a private single-purpose product into a reusable core — without rebuilding the private edition into a multi-tenant system.

Nadir should stay useful without a tracker account or a permanently connected AI provider. Local data is the primary path; external services are additions.

Bookmarks stores links, text and images durably first and enriches them afterwards. A network or model failure never costs the entry, image originals stay on the machine, and search combines FTS5 with local E5 embeddings and sqlite-vec instead of introducing a second external service. Pinakothek keeps a local media library searchable, ratable and annotatable with no provider at all. Horologion keeps calendar sources in the area responsible for them, so private iCal URLs are not passed on to the surface or to models.

The pattern across all of them: usable locally first, optionally smarter after.

A personal companion needs more than a long prompt, so the memory layers are separated:

• conversation context for the current exchange
• structured memories in SQLite, scoped per companion and edition
• human-readable content in the vault
• hybrid search for exact terms and semantic proximity
• promotion, decay and controlled reprojection instead of endless accumulation
• a deletion closure that also covers derived indexes and projections

Xenia added another layer: a source-backed chronicle of the relationship. It points at evidenced moments from presence instead of inventing an emotional history. Candidates stay editable drafts, and the relationship is never gamified through message counts, streaks or productivity.

The suite is grouped into chat, work, life and system. Not every area needs explaining — what matters is the recurring principle: area-specific settings live where their effect is visible, and shared components, states and design tokens hold the surface together without forcing every feature into the same layout.

Orakel

Sourced, agentic deep research

Tribunal

Opposing positions and a reasoned verdict

Echo

Local meeting capture and faithful summaries

Pergamon

Knowledge vault and retrieval

Mosaik

Notes and tasks

Horologion

Calendar, tasks and day context

Pinakothek

Local media library

Xenia

Source-backed chronicle of the relationship

The alpha forced the biggest change in process. A plausible UI was no longer enough: updates had to preserve local data, migrations could not be destructive, macOS permissions became part of the experience, and a green web build was not a released app. So I set clear gates:

1. Check the actual state and the real code paths
2. Specify behaviour and non-goals
3. Build in small, reversible slices
4. Review independently against code and spec
5. Run tests on one exact source state
6. Sign off commit, deployment, activation and real-world effect separately

Alpha feedback fed straight back in: persisted names were stabilised, an empty first start got a real way in, optional API errors were no longer allowed to hide content that had already loaded, and native document permissions became their own product state rather than an error.