On this page
There is a familiar transaction at the start of using a new AI assistant: explain your work again. Describe the people involved, find the relevant documents, repeat the history of a decision, and correct the assumptions that the assistant cannot know. Changing tools means making that introduction again. What seems like a prompt-writing problem is often a context ownership problem.
Zortex changes which work must be repeated. A personal model stays with the person rather than being rebuilt as an incomplete profile inside every assistant. Email, files, calendars and messages are evidence about work, but they are not interchangeable. A useful model has to preserve which person, project, document or event a claim came from, and what remains uncertain.
The next stage of human collaboration will involve more than one AI tool. People will use different assistants for research, writing, coding, planning and review. We think a person should be able to bring relevant context to those tools without letting each tool become the sole owner of the history.
The person is the continuity
Today, a project can be spread across an inbox, a calendar, shared files and chat. One person remembers that a meeting changed the deadline; another remembers which document contains the final scope. If the connection between those facts is lost, an assistant may produce a plausible but stale answer.
Our design starts with a private world model: linked people, projects, documents and decisions, supported by the source records that gave rise to them. Missing sources, unclear identities and stale copies require a model that preserves citations, exposes contested links and accepts corrections.
A person should not have to adopt one particular AI interface to benefit from that work. The context layer and the conversational interface have different jobs. The context layer assembles and maintains a coherent view; the selected assistant helps with a specific question or task. Switching the latter should not require abandoning the former.
Privacy is an operating boundary
Local-first determines where the working record lives. Zortex's desktop architecture keeps the vault and derived context on the user's computer. Connector code, an event log and the permissioned gateway implement distinct parts of that path. The Version 2 page covers early-access availability; individual services retain their own provider and platform requirements.
We do not use a user's personal content to train AI models. That does not mean information can never leave the machine. When someone deliberately asks a third-party AI to analyze selected material, that selected context may be sent to the chosen provider. Its processing is governed by that provider's terms as well as our own permissions. The useful promise is control over what is disclosed, not a fiction that external analysis involves no disclosure at all.
The distinction also matters when a person connects an app. Authorizing access is not the same event as asking for an answer. A good connector needs to say what access it requests, retain the source identity, identify a failed authorization honestly, and make removal possible. For some sources, a browser can perform steps an API does not support; that convenience adds its own authentication and reliability risks.
A working boundary, not one large permission
Our intended path can be summarized without assuming that every provider has the same connector.
Authorized source apps
|
v
Private local world model
|
v
Permission and relevance selection
|
v
One chosen AI, for one requested task
Conceptual illustration of design principles, not a certification of a live integration.
A request to summarize this week's meetings does not need the entire archive of someone's private correspondence. A coding request may need a project description and recent technical decisions, but not unrelated family messages. Relevance and permission must work together: retrieving less is not merely a cost optimization, and authorizing a source is not permission to transmit every record to every AI.
This is also a collaboration issue. Personal context often contains information about other people. Possessing a message does not create an unlimited right to publish it, or to let an agent act on another person's behalf. Access controls, provenance and reversible operations are part of making shared work possible, not obstacles to it.
Better handoffs require visible reasons
Imagine a project moving from a research assistant to a coding assistant. The important handoff is not a long transcript of the first conversation. It is the relevant question, the source documents, the current decision, the reasoning that led to it, and the gaps still open. Those are the pieces another tool can test.
Our engineering direction separates authorization, source retrieval and the context handed to an AI. The next step is to test that separation on specific connected sources, not merely to write it into an architecture diagram. We need to show which records were read, which ones crossed into an external assistant, and how a person can correct the handoff.
For a team, the same principle has a harder condition: no private personal vault should become a backdoor into a colleague's information. Shared context will need explicit sharing rules and careful treatment of ownership. We have architectural proposals for that work; we are not presenting team-wide memory as a released capability.
Evidence changes the model
This design fails if connecting sources creates a larger, less understandable privacy risk than manually providing context. It fails if the world model answers confidently from obsolete evidence. It fails if correcting a mistaken relationship requires finding and fixing it in five places. And it fails if users cannot tell which information crossed the boundary into an external AI.
The company builds for continuity across tools. Connector checks, readable retrieval traces and grant enforcement make it possible to see which records informed an answer and which assistant received them.
Source basis: ZortexHQ/INDRA's June 2026 architecture and status notes, including the explicit distinction between design-stage specifications and production implementation; the core product description in the Zortex website and waitlist. This post states the design goal, not the completion of an unreleased architecture.
