On this page
Imagine a person who has spent six months teaching an AI assistant how their work fits together. The assistant knows which project changed direction in March, why one client must never be confused with another, and where the final decision was recorded. The person then changes assistants. Perhaps the new one is better at research, costs less, or can run on their own machine.
The new assistant knows none of this. The old one still holds the history.
That is a peculiar kind of ownership. The person supplied the facts and paid the cost of explanation. Yet the useful representation of those facts belongs, in practice, to the place where the conversations happened. The account can be exported, perhaps, but a transcript is not the same thing as a usable account of a working life.
We use sovereign AI to describe a different arrangement. A person should hold the durable model of their own life and work, while assistants come and go. Sovereignty here has a practical meaning. It concerns where the model lives, what can enter it, who may correct it, which parts can leave, and what remains when a service is no longer wanted.
Rebuilding context costs work
Work does not arrive in one application. The reason for a decision may be in an email, the decision in a document, the deadline on a calendar, and the resulting obligation in a message. A search box can find each record separately. It usually cannot tell why the records belong together.
An assistant with no history asks for a project brief. The person writes one, leaving out names, qualifications, objections, and old promises because a short prompt cannot contain a year of work. Next week another assistant asks the same question. Over time, the user maintains several slightly different descriptions of the same reality.
This has an obvious efficiency cost. The less visible cost is that the descriptions drift. One version calls an idea approved; another remembers it as an experiment. An old draft becomes the presumed plan. The assistant confidently elaborates whichever description it received, while the person has to locate the missing qualification.
Putting everything into one provider's memory can reduce repetition. It also moves the cost of switching providers. The better that memory becomes, the more reluctant its owner may be to lose access to it. We do not need to assume bad intentions by a platform to see the problem. A useful memory kept in a proprietary place produces dependence even when the platform behaves responsibly.
A local record alone is not a solution either. A folder of exported conversations can be entirely in someone's possession and almost impossible to use. What matters is that the representation preserves relations and sources in a form another tool can read.
A map that can be corrected
A personal world model is an attempt to connect the things that persist across applications: people, projects, documents, conversations, tasks, and the events that changed them. It needs to distinguish the source of a statement from an inference made about it. Otherwise the model turns the assistant's guess into another apparently authoritative fact.
Suppose a calendar entry says "review contract" and an email says the review was delayed. A reasonable system may connect the two records. It must not silently turn that connection into "the contract was approved." A link may be useful before its meaning is certain; the uncertainty is part of what the owner needs to see.
The same requirement applies to names. Two correspondents can share a name. A project can be renamed. Someone can change employers while remaining the same person. If the model makes those links permanent and uninspectable, convenience becomes a source of error. The owner must be able to contest a link, remove a source, and understand why a result appeared.
A world model also has a clock. A note that correctly represented an agreement in July may mislead in October. The source should remain attributable, while the current interpretation can change. No amount of additional context compensates for a system that cannot admit its earlier model was wrong.
These are reasons to treat provenance, correction, and removal as product features rather than maintenance details. When an assistant answers a question about a relationship or commitment, the user should be able to return to the underlying records. An unsupported inference should be easier to discard than an original document.
The sources stay with their owner; only selected context is released to a chosen assistant.
An assistant is a guest, not the archive
A person may want one AI to summarize a research folder and another to help write code. Neither needs unrestricted access to every message, household record, and professional contact to do its job. An invitation to answer a question is not permission to take possession of the entire model.
This is why access controls have to operate on the context delivered to an assistant, not merely on the login screen. The system needs an answer to a small question: What does this assistant need to see for this request? It should be possible to release a selected result without copying the full archive into a prompt.
The boundary is especially important because assistants have different operating arrangements. A tool running on the same computer may handle data there; another may send selected content to a remote model. After that content reaches an independent provider, the original vault cannot recall it. The provider's retention rules and the user's agreement with that provider matter.
Zortex is being built around this separation. The desktop application synchronizes supported sources into a device-local vault and index. Connected assistant integrations can receive permitted search results and selected content through MCP. The application also documents a remote token broker used for Google authorization and refresh, and optional integrations that may process released content in the cloud. Local-first is a meaningful design choice, but it is not an assertion that every byte stays on the computer in every configuration. These distinctions are stated in our application privacy policy.
The first job of a private context layer is therefore to make the handoff legible. Which source contributed this result? What was selected? Which assistant received it? What work did the user ask that assistant to perform? The harder these questions are to answer, the more the user is being asked to trust an invisible intermediary.
A permission prompt cannot carry the whole burden. People approve prompts quickly; many have no way to judge the consequences of an access scope. The product must still minimize unnecessary disclosure, present limits accurately, and decline work that exceeds the grant. An explicit click is a beginning, not a substitute for engineering.
What it means to leave
Ownership becomes clearest when a relationship ends. A system that calls the data yours but cannot explain how to stop collection, retrieve your records, or erase its local copies has not made the claim operational.
There are several different exits. Revoking a Google grant stops future authorized access through that grant. Disconnecting a source stops use through the corresponding connection. Neither action necessarily destroys synchronized local records. Uninstalling an application may leave its data directory or an archive behind. Deleting local files cannot erase material previously delivered to an outside model provider. Treating all of these actions as the same "disconnect" button would make the interface simpler and the promise less true.
Our published Google-data policy describes those boundaries and the manual deletion procedure. It also states what is encrypted by the application: OAuth secret cells are protected with AES-256-GCM, but that statement does not extend to every index, record, and metadata field. Platform storage protection matters, and supported configurations differ. Precision is part of ownership. Users cannot make a decision with a promise that leaves out the relevant exception.
The stronger long-term test is portability. Can the person preserve sources and relationships in a comprehensible form? Can they bring a different assistant to that model without being required to reconstruct themselves? Can they remove wrong relationships and prevent stale context from resurfacing? Can they inspect what each connection can do? Those are practical tests of ownership, beyond holding the files locally.
There is no complete model of a person. A system built from email and documents will miss conversations that were never written down and motivations that were never recorded. A model made from somebody else's records may describe them unfairly. Adding sources increases coverage and can increase the amount of wrong or intimate material available for inference. Sovereignty must include the option to leave gaps.
This may make a personal model less omniscient than a provider would prefer. That is an acceptable trade. A record should be useful enough to help its owner and limited enough to remain under that owner's direction.
One day the best assistant for a task will be a different assistant. The owner should have to decide which tool deserves the task, not whether six months of their working history can afford to move with them.
